WOPI sessions do not "remember" add-ins that have been loaded

[AndyHore]

Provide required information needed to triage your issue

From a WOPI (Word, or Excel) session, load an add-in from the App Store. End that WOPI session and start a new one and it will NOT automatically load the add-in that was loaded. If you Uses Desktop or office.com using the same credentials to load an add-in, that add-in is automatically loaded for future sessions, just not for a WOPI session.

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC/Mac, WOPI
• Host [Excel, Word, PowerPoint, etc.]: Word and Excel
• Office version number: latest
• Operating System: Windows/MaxOS
• Browser (if using Office on the web): Chrome/Edge, Firefox, Safari

Expected behavior

Previously loaded add-ins are loaded every time a WOPI edit session is started.

Current behavior

They are not loaded and have to be manually loaded each time.

Steps to reproduce

1. ---

2. ---

3. ---

Link to live example(s)

1. ---

2. ---

3. ---

Provide additional details

1. ---

2. ---

3. ---

Context

Usability and extra steps every time a WOPI session is launched means end user frustration and non-acceptance of our product.

Useful logs

• [ ] Console errors
• [ ] Screenshots
• [ ] Test file (if only happens on a particular file)

Thank you for taking the time to report an issue. Our triage team will respond to you in less than 72 hours. Normally, response time is <10 hours Monday through Friday. We do not triage on weekends.

[nickamckenna]

Please fix this! It is a very common problem in our WOPI / Add-In implementations!!!

[jpmarr]

We have also observed this issue and general inconsistency of behaviour when loading documents in a WOPI session that have Add-Ins present.

[timpull]

Yes please fix this, it is a serious deficiency in the WOPI concept. In our case it is preventing us from incorporating Word into our application workflow (because our add-in is an essential component of the UX) and causing us to look elsewhere for integrated editing

[jpmarr]

Further information:

Having had our Add-In published on the Marketplace, we intended to get it to users by inserting the Add-In into a document programmatically within our WOPI backend. We have added the code to do this and confirmed that the resulting document file loads with the Add-In present in Word for Web using OneDrive.

Within Word for Web in our WOPI environment however, I have observed two different behaviours:

1. The Add-In does not show in any way when the document is loaded - despite the reference to it being present in the document.
2. The Add-In task pane shows up and requests the user trusts the Add-In from the store. When the 'Trust' button is clicked, the Task Pane disappears and the Add-In's command button appears on the Ribbon (along with the Getting Started callout). However, when the button is clicked to open the Task Pane, Word simply shows an error popup (with no specific diagnostic information present). No outbound network call is made to our Add-In backend so the error is within Word. Working through the minified code, I have observed that the Add-In manifest is retrieved when the Trust button is clicked but in the code triggered by the command button click which should show the Task Pane, I observe an attempt to locate some data about the Add-In from an internal collection using the asset id from the manifest. This collection is empty at this point, a null value is therefore returned and this is what throws up the error modal. Video

I am not yet able to confirm completely what environmental difference dictates when I see behaviour 1 vs behaviour 2 but I suspect it is related to cookies/state saved after using Word for Web on OneDrive with the Add-In successfully using the same MS account that I login to our WOPI Word editor with.

[keyur32]

Hi everyone,

Thanks for the report and feedback.

Good news is, we have a new mechanism for 3rd party providers who are in the Cloud Storage Partner Program to embed their own add-ins within their host.

Please see this documentation for instructions: https://wopi.readthedocs.io/en/latest/scenarios/hostinstalladdins.html, and contact the CSPP team to get onboarded. This capability will allow you to embed add-ins on load (note: add-in must be hosted in the store, just like today), with auto-show-taskpane. It also will still work for you host, even if the signed in user has the store disabled within their organization, and the ability to by pass the trust prompt.

One additional note is, after on boarding, that if you are using OfficeOpenXML to set an add-in to be embedded, then you show set the storeType attribute to be "wopicatalog" (not "omex").

[mmoloney9966]

I have heard some rumors that in addition to the changes in the hostinstalladdins.html page, our WOPI host will also need to implement the supportsFrameTrustedPostMessage and App_IsFrameTrusted, the whole "PostMessage to interact with the office for the web iframe application" implementation.

Any truth to that or just this "AppID" payload for the form field value post ?

I've added the form field value post and not allowing webaddins to "persist" but am testing in our lower environments. I've heard this only works in production?

[keyur32]

Hi, please see this: https://wopi.readthedocs.io/en/latest/faq/host_install_addins.html#addins-faq for information on how to do that. You will need your domains to allow listed first by contacting the CSPP team, I believe.

[mmoloney9966]

Light bulb may have gone off about the "auto-show-taskpane" note. Does this mean we have to apply the information documented in https://docs.microsoft.com/en-us/office/dev/add-ins/develop/automatically-open-a-task-pane-with-a-document ?

Which indicates a change in our manifest and we actually have to modify the document to set a property before streaming it to the Office Online (WOPI) edit session?

[mmoloney9966]

I've implemented the OpenXML tagging of the document we are trying to edit via a WOPI/OfficeOnline session. I can open that modified docx in local desktop Word, in our WebDAV integration for Word, and in the Office365.com Word. However, when I send that same file content to OfficeOnline using our WOPI integration, we just get a popup message saying "there was a problem and we can't open this document". Clicking to "Open in Reading View" also fails with same message. Will this "Open XML" tagging for auto opening a task pane work with the WOPI integration?

[mmoloney9966]

Keyur,

Not sure if this will help or not but any insight you could offer would be greatly appreciated. Attached is a Word docx modified using OpenXML to enable the auto-open-taskpane. Attached the fiddler trace (renamed with .log extension to allow uplaod; but it doesn't show anything compared to a successful WOPI edit of an unmodified docx) but did attach a console log of the failed WOPI open of this modified docx.

The console log shows an exception that does not occur on a "successful" WOPI edit of a non-modified docx.

WordEditorDS.js:2444 Uncaught (in promise) TypeError: Cannot read property 'ic' of null at f.M_e (WordEditorDS.js:2444) at f.get value [as value] (WordEditorDS.js:2825) at cm.OYf (WordEditorDS.js:4687) at ue.LIh (WordEditorDS.js:1950) at WordEditorDS.box4.dll1.js:7299 at new Promise () at TG.oNl (WordEditorDS.box4.dll1.js:7299) at new TG (WordEditorDS.box4.dll1.js:7299) at l.Fna (WordEditorDS.box4.dll1.js:7307) at l.createInstance (WordEditorDS.js:686) WOPI console.log Test Document.Unmodified.docx Test Document.ModifiedWithOpenXML.docx WOPI.OpenXML.saz.log

Any advice would be greatly appreciated as this has become an urgent issue for one of our largest customers.

[keyur32]

Apologies for missing this issue. I believe this should go through CSPP support (as there are specific requirements to running add-ins in a WOPI host) to get the help you need here if you are still hitting this issue and need detailed help. If that is not feasible, please reopen this issue and we can have someone take a look.