none
Document not visually updating when inserting OpenXML into Office Online Word document RRS feed

  • Question

  • I'm using the OfficeJS API to insert some OpenXML into a Word document in Office Online server. I've also setup a custom WOPI host to handle the requests.

    In my task pane addin, when I click a button an image is inserted into the document using the following code:

    Office.context.document.setSelectedDataAsync(getImageOOXML(), {
    coercionType: Office.CoercionType.Ooxml
    },

    When that code runs a PutFile request is made to the WOPI host and the document is saved.

    The problem I'm having is that nothing visually shows in the document. An image should appear where the cursor is but it's not there. If I refresh the page with the Word editor, then the image shows up as expected. 

    I also tried using  an on-premise Sharepoint server that is linked to the same Office Online Server to edit a Word document. I used the exact same addin, and the image appears immediately as expected when the OpenXML is inserted.

    I'm not sure why the document is visually updating with Sharepoint and not with my custom WOPI host. I noticed Sharepoint is using the Cobalt protocol whereas the custom WOPI host is not, but I don't think that should make a difference.

    Has anyone seen anything like this before?

    I have a Fiddler archive that contains the requests when I run setSelectedDataAsync() at this url:

    https://drive.google.com/open?id=0B6b4-hQXwEvtV3VNWThHdVNfMU0

    • Edited by trs79 Monday, October 9, 2017 9:50 PM
    Monday, October 9, 2017 8:41 PM

Answers

  • Hi trs79, 

    Thanks for your patience. After investigation with the Officejs team we have an understanding of this. The current design of InsertOoxml() in Officejs is that it only detects changes in hosts that support Cobalt. This is why the rendering does not change immediately when after the call to this API. After the auto-save functionality (subsequent Putfile) engages the wopi host, the new data will be rendered but if another edit from the UI occurs, this will preempt the InsertOoxml() edit which will be lost. The Officejs team has logged this as a bug and will consider whether to include this as a design change in a future update.

    Just to clarify for this forum, the problem does not impact the [MS-WOPI] Open Specification document or the protocol functionality. The problem is in the Office web app processing for InsertOoxml().

    Tom


    • Proposed as answer by Tarun Chopra - MSFT Thursday, November 16, 2017 6:54 AM
    • Marked as answer by trs79 Thursday, November 16, 2017 4:20 PM
    Wednesday, November 15, 2017 9:31 PM
    Moderator

All replies

  • Hi,

    Thank you for this inquiry. One of our engineers will review this and follow-up soon.

    Regards,

    Edgar

    Tuesday, October 10, 2017 3:15 AM
    Moderator
  • Hi trs79, 

    I'll take a look at the fiddler trace. I suspect that the issue is more likely related to how the Office web app handles the Officejs code than the WOPI protocol. 

    Best regards,
    Tom Jebo 
    Sr Escalation Engineer
    Microsoft Open Specifications Support

    Tuesday, October 10, 2017 5:55 PM
    Moderator
  • Hi Tom,

    Thanks for taking a look at this. The odd thing is it works fine when using Sharepoint 2013 foundation which is using Cobalt, even though the same Officejs and web app code is used.


    • Edited by trs79 Tuesday, October 10, 2017 10:09 PM
    Tuesday, October 10, 2017 9:40 PM
  • Hi Tom,

    Just wondering if you had a chance to look at the Fiddler trace? Thanks!

    Friday, October 13, 2017 2:23 PM
  • Hi trs79, 

    Yes, I've looked at the trace although it did not show anything unusual. I also reproduced the issue on my local test OOS and WOPI host and am currently investigating possible causes for the delay. 

    Thanks for you patience.

    Tom

    Friday, October 13, 2017 2:43 PM
    Moderator
  • Hi Tom,

    I'm glad the issue is reproducible. Please let me know when you find out more information, thanks.


    • Edited by trs79 Tuesday, October 24, 2017 4:52 PM
    Tuesday, October 24, 2017 4:51 PM
  • Hi trs79, 

    I'm still investigating and will update you soon. Thanks for you patience.

    Tom

    Wednesday, October 25, 2017 2:25 AM
    Moderator
  • Hi @Tom and @trs79,

    We are very interested in hosting Office Online Server on our own server but we are confused about licensing. 

    The wopi documtation (https://wopi.readthedocs.io/en/latest/overview.html) seems to be focused on the cloud partnership. But is there some other official website that talks specifically to the licensing for on-prem installations of OOS?

    Specifically:

    • What kind of license do we need to have with MS in order to install Office Online Server on our server?
    • What kind of license do we need to have in order to provide View-Only capabilities to our clients. (These users will not be our employees. Instead they will be employees of our clients, and even other users outside of their organization that they choose to share documents with.)
    • What kinds of license do we need to have in order to provide Edit capabilities to the same users listed in the previous bullet point.
    • From reading the wopi documentation, it would seem that using the cloud partnership version of OOS, MS will prompt the business users for their Office 365 credentials to validate that they have a license. However, is that the same behavior that is expected for on-prem installation of Office Online Server?

    Friday, November 10, 2017 7:40 PM
  • Hello Anthony, questions pertaining to licensing are out of scope for our team. We suggest you to contact Microsoft frontline support directly by phone (1-800-426-9400) as they are well equipped to handle such queries.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications
    Friday, November 10, 2017 9:24 PM
    Moderator
  • Hi trs79, 

    Thanks for your patience. After investigation with the Officejs team we have an understanding of this. The current design of InsertOoxml() in Officejs is that it only detects changes in hosts that support Cobalt. This is why the rendering does not change immediately when after the call to this API. After the auto-save functionality (subsequent Putfile) engages the wopi host, the new data will be rendered but if another edit from the UI occurs, this will preempt the InsertOoxml() edit which will be lost. The Officejs team has logged this as a bug and will consider whether to include this as a design change in a future update.

    Just to clarify for this forum, the problem does not impact the [MS-WOPI] Open Specification document or the protocol functionality. The problem is in the Office web app processing for InsertOoxml().

    Tom


    • Proposed as answer by Tarun Chopra - MSFT Thursday, November 16, 2017 6:54 AM
    • Marked as answer by trs79 Thursday, November 16, 2017 4:20 PM
    Wednesday, November 15, 2017 9:31 PM
    Moderator
  • Hey Tom,

    I am also facing the same issue with my plugin, looks like this issue is not yet addressed, let me know if there is any alternative way to do it.

    Friday, January 3, 2020 12:29 PM
  • Hi ChandanKr, 

    As this issue was diagnosed as a problem in OfficeJS and not affecting the WOPI protocol specification, I recommend that you search/post to the following github issue page to find out more information about resolution on this issue: 

    https://github.com/OfficeDev/office-js/issues

    Best regards, 
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications Support


    Friday, January 3, 2020 4:55 PM
    Moderator