When a document contains Inline Content Controls, Word Online throws an error when we iterate over the context.document.contentControls collection and try to modify the content controls.
Word on all platforms should be able to manipulate both block and inline Content Controls equally.
Whenever we try to update a property or content of an inline Content Control, an exception is thrown:
{
"code": "NotAllowed",
"message": "The action isn鈥檛 supported in Word Online. Check the OfficeExtension.Error.debugInfo for more information.",
"errorLocation": "ContentControl.title",
"statement": "v.title=...;",
"surroundingStatements": [
"var v=context.root._getObjectByReferenceId(\"{105c628f-6a88-4c23-a893-a8b84065fc98}{19}\");",
"// >>>>>",
"v.title=...;",
"// <<<<<"
],
"fullStatements": [
"Please enable config.extendedErrorLogging to see full statements."
]
}
We have customers that create a document on Word for Windows using both inline and block Content Controls. This document is then further manipulated on Word Online by another user. When our add-in tries to manipulate all Content Controls, Word Online fails when it encounters an inline Content Control.
Hi htryggva. This is due to Word Online's feature limitation.
Some properties are not fully supported on Word Online yet, which will makes content control becomes unsupported and results into NotAllowed exception. In your case, the not fully supported property is the "tab".
If you remove the tab and upload this file again, you'll be able to edit this content control.
Hi @xianggaomsft. I don't know what the 'tab' Content Control property is. Can you please clarify?
On another note: I'm aware of this limitation but our customers (users of our add-in) will not understand why or how they have to change their document so that it works on Word Online.
we are tracking this issue internally with 2452020. we need to fix this.
@htryggva this should not block your add-in from bein published as its a limitation on the platform. (and sounds seems an edge case.)
Update: This issue is been investigating and a potential fix is been test. @weshi is tracking it.
@JuaneloJuanelo The same behavior occurs when we insert a Word field into a ContentControl via insertOoxml.
Word.run(function (context) {
var range = context.document.getSelection();
var cc = range.insertContentControl();
cc.insertOoxml(ooxmlfield, Word.InsertLocation.replace);
return context.sync();
});
ooxmlfield:
WordField.txt
Insert via Word Desktop:
Everything ok - Open document in Word Online: CC is read-only (and all actions fail with "NotAllowed")
Insert via Word Online:
Field appears without content and is also readonly.
Is this bug also fixed?
This is tracked in our backlog, but currently this is a limitation that only Rich Text content controls are supported in Word Online.
@JuaneloJuanelo @weshi can we not keep this issue open so you can report any progress here - that way we keep the communication up on this topic and do not need to re-create a new issue to ask for any progress update - thoughts?
Re-open the issue for tracking purpose. Thanks.
@weshi thx. for re-opening. Do you have a tag for 'product parity bug' - If yes I think this would better describe the situation as a product feature request might slip the ranks in the roadmap but a parity bug might attract more attention (so we hope) - thoughts? cc: @JuaneloJuanelo
@MartinSSeifert there isn't a 'product parity bug' tag. Let me also add 'product bug' tag as well for tracking.
Thanks so much for reporting this issue. We consider inline content controls in Word Online to be a new feature, hence this is not an issue with shipped features but it qualifies as a feature request, we track such requests in our UserVoice channel.
Please open or upvote a new User Voice request, this is the place we use to track feature requests.
thanks!
Most helpful comment
@JuaneloJuanelo @weshi can we not keep this issue open so you can report any progress here - that way we keep the communication up on this topic and do not need to re-create a new issue to ask for any progress update - thoughts?