insertFileFromBase64 causes accumulation of styles

[Anya1304]

We're working on an add-in for Word that involves opening multiple documents.

However, we've encountered an issue: when we use context.document.insertFileFromBase64 to open several documents, the styles from these base64 documents are being "merged." In other words, if there were no custom styles when the add-in was initially launched, opening subsequent documents results in the accumulation of styles, leading to potentially hundreds of redundant styles.

What we expect is that when a document is opened using context.document.insertFileFromBase64, only the styles specific to that particular document should be applied. It seems that the JavaScript API doesn't support this behavior.

To address this, our current workaround idea involves saving the document and styles state in the global state during Office.OnReady, and then restoring this state just before using context.document.insertFileFromBase64.
Something like that:

export const insertDocument = async (
  fileDataBase64: string,
  document: DocumentAndStyles, //global state of initial document and styles
) => {
  return Word.run(async (context) => {
    let currentStyles = context.document.getStyles();
    currentStyles.load({ builtIn: true });

    await context.sync().then(() => {
      //delete all styles
      currentStyles.items.forEach((style) => {
        if (!style.builtIn) {
          style.delete();
        }
      });
      //set initial document
      context.document.set(document.document as Word.Document);
      //set initial styles
      context.document.importStylesFromJson(JSON.stringify(document.styles));
      //insert new file, import new styles
      context.document.insertFileFromBase64(fileDataBase64, "Replace", {
        importTheme: true,
        importStyles: true,
        importParagraphSpacing: true,
        importPageColor: true,
        importChangeTrackingMode: false,
      });

      return context.sync();
    });
  });
};

This approach has poor performance due to the time required to restore the state (we need to remove all styles and restore the initial styles).
Are there any alternative solutions or workarounds?

[shanshanzheng-dev]

Hi @JHJ-MS Could you please help take a look this issue? Thanks.

[jipyua]

hi @Anya1304, thanks for reaching out. I am afraid we need to confirm more details with you. When you say "What we expect is that when a document is opened using context.document.insertFileFromBase64, only the styles specific to that particular document should be applied.", can you explain more about "styles specific to that particular document" mean? We know that a document has both built-in styles such as "Heading 1", "Heading 2"... and customized styles. do you only want to import the built in styles?

In case if you don't want the styles from the base64 document at all, does set "importStyles: false" will meet your needs?

[Anya1304]

Hi @jipyua,

Sorry for the confusion earlier. When I mentioned "styles specific to this particular document", I meant that only styles unique to a particular document should appear in the Styles Gallery when that document is opened.

We need to import custom styles , so { importStyles : true } is essential for us.

Let me clarify the problem again:
The issue arises when I open multiple documents consecutively. Instead of only displaying the styles relevant to the currently opened document, the "Styles gallery" accumulates all the styles from each document I've opened (both built-in and custom). This means that if I've opened 100 documents, I will end up seeing a lot of styles, including those from previous documents, cluttering the gallery.

We've looked into resolving this by removing the custom styles and hiding the built-in ones before opening a new document. This approach has poor performance and after switching through several documents, an error is thrown. The more styles documents have, the faster the error appears. (as shown in video and screenshot below)

I created a snippet in the ScriptLab that contains this logic. Hope this helps to solve the problem!

snippet.txt
https://github.com/OfficeDev/office-js/assets/55894856/1e83bb1a-66a3-45dd-937d-aa4e7ef1fdd8

[jipyua]

hi @Anya1304 thanks for the clarification, it's more clear now! By running the provided code snippet, I didn't see the execption in the video and the base64 files can be imported correctly. From the provided code, you are deleting all accumulated non-builtin styles (which are custom styles) everytime insert a base64 file, does it mean you just want to import the builtin styles from the base64 document? So far the document.insertFileFromBase64() API doesn't provide the functionality to differentiate the two. We track Office Add-in feature requests on our Microsoft 365 Developer Platform Ideas Forum. Please add your request there. Feature requests will be considered when we go through our planning process. Please let us know if you have other feedbacks or suggestions. Thanks.

if (!style.builtIn) {
style.delete();
}

[Anya1304]

Hi @jipyua. We need to import both custom and built-in styles and display only the styles relevant to the currently open document in the Styles Gallery.

The code snippet provided above does exactly what we want! It removes the custom styles, removes the built-in styles from the Styles Gallery, and imports a new document with the new styles, so the only styles from the new base64 will appear in the Styles Gallery

But the error does not occur immediately. It may take several switches between documents to see the error. I can't create the files to speed up the error, but this error ALWAYS occurs.

I've made another snippet with multiple documents. If you switch between them a few times, you will definitely see the error.

To reproduce it, just switch between the documents until the error occurs (may take about 8-15 switches to see the error)

snippet.txt

error.mp4

[jipyua]

@Anya1304 thanks for providing more details, seesm I can reproduce this error. This has been logged in our internal system and we will take a look at this and do some investigation. I see you opened another case 4463, will you please close this one and let's use 4417 to track the issue?