Word Add-In: Office.context.document.settings.get Does Not Return the Same Value Across Different Word Versions

[gkarmelich]

The Office.context.document.settings.get method returns the correct data when using the same Word Version as when it was saved, but returns null when using a different version. An important note is this issue occurs when using the add-in in production that was installed from the Microsoft App Store, NOT when sideloading during development.

Expected Behavior

The expectation is Office.context.document.settings.get returns the same data from the webextenion.xml file across all platforms, Word versions and Operating Systems, as long as the Word Javascript API Version 1.1 is supported and the id attribute in the webextension.xml file matches our application id in the manifest.

Current Behavior

In a published Word add-in, we are using the Office.context.document.settings.get method to retrieve data previously saved by the Office.context.document.settings.set and its corresponding Office.context.document.settings.saveAsync methods from Word Javascript API Version 1.1. When saving data to the Word document (specifically the webextension.xml file) on the same user setup (Word Version, Platform, OS, etc), the correct data can be retrieved without issue. However, when opening the same Word document and launching the same published add-in on another machine (for example, a different Word Version), the Office.context.document.settings.get method returns null.

Since the Office.context.document.settings.get method does not recognize the first webextension.xml file, a second one is created (see sample xml below). The only difference between these files is the value of the store attribute. The values of the id attribute match our application id in the manifest.

Steps to Reproduce, or Live Example

We noticed this issue in many situations (most notably when using a different Word version from the one that was used when the document was created and the data was saved), but for brevity, have described the following steps to hopefully highlight the problem. To add more insight, we only noticed this problem over the last week (our add-in has been published for ~3 years), so it may be attributed to a recent release.

1. Create the following environment:
   • Platform [PC desktop, Mac, iOS, Office on the web]: Mac
   • Host [Excel, Word, PowerPoint, etc.]: Word
   • Office version number: 16.43 (20110804)
   • Operating System: OS X 10.15.6
2. Save arbitrary data to the settings object via Office.context.document.settings.set
3. Create the following environment
   • Platform [PC desktop, Mac, iOS, Office on the web]: Mac
     • Host [Excel, Word, PowerPoint, etc.]: Word
     • Office version number: 16.44 (20121301)
     • Operating System: OS X 10.15.6
4. Try to access the data created in Step 2 via Office.context.document.settings.get

Context

This is absolutely URGENT and a complete blocker for us at the moment, so any assistance and guidance you can offer as soon as possible is greatly appreciated.

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: Mac
• Host [Excel, Word, PowerPoint, etc.]: Word
• Office version number: 16.44 (20121301)
• Operating System: OS X 10.15.6
  • Browser (if using Office on the web): N/A

Useful logs

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

webextension1.xml: sample xml (can no longer be identified as belonging to our application)

<we:reference id="id1234" version="3.0.0.0" store="en-US" storeType="OMEX"/>
<we:alternateReferences>
    <we:reference id="id1234" version="3.0.0.0" store="id1234" storeType="OMEX"/>
</we:alternateReferences>

webextension2.xml: sample xml (can be identified as created by our application)

<we:reference id="id1234" version="3.0.0.0" store="en-001" storeType="OMEX"/>
<we:alternateReferences>
    <we:reference id="id1234" version="3.0.0.0" store="en-001" storeType="OMEX"/>
</we:alternateReferences>

[gkarmelich]

I also posted the same issue to Stack Overflow.

[VivianVenter]

I also posted a similar issue to Stack Overflow

[amelehy]

My team is also experiencing this issue (it is also URGENT as our entire add-in relies on the Settings object being consistently accessible). We've narrowed things down to a mismatch in the value of store in the webextension1.xml and webextension2.xml files. It seems that a recent version of Word thinks that the add-in being loaded is a different add-in if it was installed from the web version of the Office Store (https://store.office.com) vs. being installed from within Word.

When installed from the Office Store in a browser, the relevant store attributes in an associated webextension1.xml file are en-001. In this case I've obfuscated the add-in ID as 12345:

  <we:reference id="12345" store="en-001" storeType="OMEX" version="3.0.0.0"/>
  <we:alternateReferences>
    <we:reference id="12345" store="en-001" storeType="OMEX" version="3.0.0.0"/>
  </we:alternateReferences>

When installed from with Word itself (after clicking on the "Get Add-ins" button):

the relevant store attributes in an associated webextension1.xml file are en-US and the add-in ID (again obfuscated as 12345 here):

  <we:reference id="12345" store="en-US" storeType="OMEX" version="3.0.0.0"/>
  <we:alternateReferences>
    <we:reference id="12345" store="12345" storeType="OMEX" version="3.0.0.0"/>
  </we:alternateReferences>

We've manually adjusted the store value in the webextension1.xml from a document and found that flipping between en-001 and en-US exposes different Settings objects for the same add-in.

So it seems that instead of just looking at the add-in ID for uniqueness of the Settings object within a document, Word is now looking at the store as well?

If this is a bug with a recent release, we desperately need a quick fix. Thank you!

[AbidRahman-MSFT]

Hey everyone, thank you for reporting this bug. We are able to reproduce it and are currently investigating the issue. I will let you know as soon as we have an update.

[amelehy]

Hi @AbidRahman-MSFT, is there any update on this? This is extremely urgent for us.

[AbidRahman-MSFT]

@amelehy Still investigating, will update this thread on when/how we are mitigating the issue.

[amelehy]

Thanks for the update @AbidRahman-MSFT. From what we're seeing the store ID has always been en-001 when installing an add-in from AppSource, and that is still the case today.

The real problem is that when calling Office.context.document.settings.get, Office JS is not recognizing an existing webextensions file with the same add-in ID as the add-in that is making the Office.context.document.settings.get call because the value of store in the webextensions file is different. So it seems Office JS thinks that a different add-in is calling Office.context.document.settings.get which results in none of the Settings data being accessible by the add-in that originally saved it to the Settings object. This happens if a user installs the add-in from AppSource in a browser then later reinstalls it from within Word or vice versa (two different store IDs).

Up until this issue was posted, Office JS seemed to only use the add-in ID in the webextensions file to determine uniqueness. Now it seems it is using both the add-in ID AND the store ID. So the issue sounds like it is with Office JS/Word rather than with AppSource but I could be wrong.

Can you give us a sense if this will be fixed in weeks or in months?

[AbidRahman-MSFT]

@amelehy thanks for the context here. I've shared it with the team. I can give you an estimate as soon as we can drill down on what internal change is causing this issue. Unfortunately, we don't know the source of this issue yet.

[VivianVenter]

Good Day everyone,

Just some context from my side surrounding this. This happens in Excel as well. We have an add-in that we've been using for around 3 years, we store metadata in the settings object such that if you send your excel file to a colleague our add-in can read the metadata and the user can continue using the add-in with the file. A week ago a colleague told me the add-in is causing issues. He sends his file to me for debugging but I couldn't reproduce the issue. I was still on the previous Excel version and my colleague was on the latest version (13530.20376). I decided to update my Excel to the latest one and then I had the same issue as he did, upon debug we found that the settings object is not being retrieved reliably. If we debugged in Excel Online the settings object was retrieved but not in Excel Desktop.

I can also confirm this DOES happen with sideloading as well

Regards, Vivian

[gkarmelich]

Hey @AbidRahman-MSFT 👋, just checking in to see if you have any updates regarding this issue.

[amelehy]

Hi @AbidRahman-MSFT, can we get an update on the status and estimated time to a released fix?

[amelehy]

Hi @AbidRahman-MSFT , checking in on this again.

[AbidRahman-MSFT]

Hey @amelehy, thanks for checking in. We are still working on figuring out the correct fix for this issue as the scope spans several teams. I'm hopeful that we will be able to provide an update on the investigation end of this week or early next week. Thanks.

[amelehy]

Hi @AbidRahman-MSFT any updates here?

[jargil]

Thank you for your bug report, and thank you for your patience. We're looking into this. Will update here as soon as we have something to share.

[amelehy]

Thank you for the update @jargil 🙏 - what are the chances that this is resolved by the end of the month?

[jargil]

@amelehy - I can't comment on timelines at this point. Once I have something concrete to share I'll make sure to provide an update here.

[amelehy]

Hi @jargil, is there any update on when this fix will be released? This is still a major issue for our customers who are starting to become very frustrated with Word itself as this was not the only Word bug introduced recently. Thank you for your help.

[jargil]

We've made a fix that I think will address the bug described here. If you want to try it out please join the Office Insiders program. The fix should rollout to the Mac Beta Channel sometime this or next week with build 16.48 (21031400) or newer.

https://insider.office.com/en-us/join/mac

[amelehy]

This is great news @jargil , thank you very much 🎉

We will check out the release via the Office Insiders program as soon as it's available. How long does it usually take to go from the Office Insiders Beta to the next full production release?

Also, wanted to confirm that this is not just a Mac issue but is an issue on Windows as well. Will this fix only fix things for Mac?

[jargil]

Our fix applies to both Mac and Windows.

Release of this fix is quality driven, assuming everything goes without problems you should expect this to rollout to Production sometime between early and mid April.

[amelehy]

Great @jargil , thank you for the clarification on both accounts 👍

[jargil]

Closing this as this should now be available to test. Please comment if you're still seeing problems using one of the Office builds I mentioned above.

[JulesRM]

Hi all!! @jargil, I am still having issues, even with the Beta channel (checked and Current Channel Preview did not have any updates) on Mac. I am using a property called <we:property name="documentId". Your help will be much appreciated, since we are facing various complaints since the past 5 -6 weeks. It is causing all kinds of havoc, because we cant get information correctly since the documentID property cannot be fetched :-( Please let me know if you need any additional info :) thanks so much!

Original XML from .docx file: webextension1.xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

**New XML File generated by using the window['Office'].context.document.settings.set and settings.get methods: webextension2.xml**

[jargil]

@JulesRM - I'll try to answer, let me know if this is not what you were asking, in which case please clarify by adding repro steps or explaining a bit more about your scenario. Just looking at the two XMLs you shared, those are effectively coming from two different places, the first one (storeType=EXCatalog) is coming from a Centrally Deployed origin, while the second one is coming directly from the Office Store (storeType=OMEX). In terms of their settings/storage, they are effectively two different instances and one cannot access the other.

[gkarmelich]

Hi @jargil, thanks for replying to @JulesRM. I have a related question in regards to your explanation. We have many of our customers who need to sideload the manifest file to run our production application because they do not have access to the Microsoft store due to internal IT regulations.

My understanding is that sideloading the manifest file gives a storeType of EXCatalog, correct? If so that means someone who sideloads cannot interact with documents that are created by users who install from the store and vice versa.

[jargil]

@gkarmelich - EXCatalog refers to what we call Centralized Deployment (https://docs.microsoft.com/en-us/office/dev/add-ins/publish/centralized-deployment). Admins can deploy add-ins to their tenants either by directly side-loading a manifest, or by deploying from the Store to their tenant. You are correct that add-ins deployed directly from the Store and those deployed by the admins do not share settings persisted in the file.

[JulesRM]

@JulesRM - I'll try to answer, let me know if this is not what you were asking, in which case please clarify by adding repro steps or explaining a bit more about your scenario. Just looking at the two XMLs you shared, those are effectively coming from two different places, the first one (storeType=EXCatalog) is coming from a Centrally Deployed origin, while the second one is coming directly from the Office Store (storeType=OMEX). In terms of their settings/storage, they are effectively two different instances and one cannot access the other.

### Thanks so much Jargil! You were right, one of the users had the add-in installed through Centralized Deployment and the rest through the Microsoft Store. That was causing the issue. The user said that was never configured on their Office 365 subscription, but nevertheless when we checked there it was. So we removed it from Centralized Deployment and it started working ok again. Word did not give us this issue previously, though. So something did change in this sense that Word started separating the dataspaces depending on their installation type. We even did a workaround to install a previous Word for Mac version, and that previous version worked ok with different add-in installation types. So the change started in the recent months. Now I have another issue that the SystemJS cannot load in the Word Addin pane only for 2 certain users. Ill post that on a new thread, thanks again!

[ArielTommarello]

Hello everyone, I'm currently working on developing a Word Add-in, but I'm changing the framework to .NET 7. I've managed to make it load my cshtml within the add-in and display it. However, I've hit a roadblock when trying to access the custom XML parts of the document, where I would use that information to validate my user. The problem arises when I attempt to access:

javascript Copy code (function () { "use strict";

var messageBanner;

// The initialize function must be run each time a new page is loaded.
Office.initialize = function (reason) {

It starts to loop through jquery.js and office.js without a resolution. Then, when it returns to the code, it consistently breaks when it reaches all the points where it says Office.context. I've attached an image of the errors that occur. If anyone has successfully implemented this in .NET 7 for the add-in or has a solution for this error, I would appreciate your help!