RichApi.Error: GeneralException occurs when updating styles

[Anya1304]

We're working on an add-in for Word that involves opening multiple documents and showing the styles in the Styles Gallery that are specific to the document being inserted (both built-in and custom styles)

We have encountered an issue: when we use context.document.insertFileFromBase64(base64String, "Replace", { importStyles: true }); to open several documents, the styles from these base64 documents are being accumulated in the "Styles Gallery". In other words, if there were no custom styles in the "Styles Gallery" when the add-in was initially launched, opening subsequent documents using context.document.insertFileFromBase64(base64String, "Replace", { importStyles: true }); results in the accumulation of styles, leading to potentially hundreds of redundant styles cluttering Styles Gallery.

SO to address this we need to HIDE all built-in styles from the Styles Gallery and DELETE all custom styles just before inserting new document using context.document.insertFileFromBase64(base64String, "Replace", { importStyles: true });

Your Environment

• Platform: PC desktop
• Host: Word
• Office version number: Version 2404 (Build 17531.20140)
• Operating System: Windows 11

Expected behavior

delete custom styles and hide built-in ones before inserting new document using context.document.insertFileFromBase64(base64String, "Replace", { importStyles: true }); will ensure the Styles Gallery shows styles identical to the specific document being inserted, without errors.

Current behavior

When we delete custom styles and hide built-in ones before switching to a new document, an error occurs after several switches through documents. The more documents have styles, the faster the error occurs.

Steps to reproduce

1. Create several documents with a lot of styles
2. Open first document using context.document.insertFileFromBase64(base64String, "Replace", { importStyles: true });
3. Delete all custom styles and hide built-in styles from the current styles

             if (!style.builtIn) {
               style.delete();
             }
             //remove built-in styles from styles gallery
             else if (!style.visibility) {
               //(bug: the 'visibility' works in opposite way)
               style.set({ visibility: true });
             }  

4. Open the next document using context.document.insertFileFromBase64(base64String, "Replace", { importStyles: true }); and repeat the algorithm. It takes many switches to see the error.

Additional details

I created a snippet containing the logic described above. Using this snippet in ScriptLab, switch through documents as shown in the video. It may take about 8-10 switches for the error to occur.

Context

Solving this issue is essential for us because our application involves switching through many documents.

Useful logs

• [ ] Console errors :

  {
  "stack": "RichApi.Error: GeneralException\n    at new n (https://appsforoffice.microsoft.com/lib/1/hosted/word-win32-16.01.js:25:267311)\n    at i.processRequestExecutorResponseMessage (https://appsforoffice.microsoft.com/lib/1/hosted/word-win32-16.01.js:25:331758)\n    at https://appsforoffice.microsoft.com/lib/1/hosted/word-win32-16.01.js:25:329821",
  "message": "GeneralException",
  "name": "RichApi.Error",
  "code": "GeneralException",
  "traceMessages": [],
  "innerError": null,
  "debugInfo": {
      "code": "GeneralException",
      "message": "GeneralException",
      "errorLocation": "Document.insertFileFromBase64",
      "statement": "var insertFileFromBase64 = root.insertFileFromBase64(...);",
      "surroundingStatements": [
          "...",
          "var v126 = context.root._getObjectByReferenceId(\"02D!000032D3\");",
          "v126.visibility = ...;",
          "var v127 = context.root._getObjectByReferenceId(\"02D!000032D4\");",
          "v127.visibility = ...;",
          "var root = context.root;",
          "// >>>>>",
          "var insertFileFromBase64 = root.insertFileFromBase64(...);",
          "// <<<<<",
          "// Instantiate {insertFileFromBase64}"
      ],
      "fullStatements": [
          "Please enable config.extendedErrorLogging to see full statements."
      ]
  },
  "httpStatusCode": 500
  }

snippet.txt https://github.com/OfficeDev/office-js/assets/55894856/0b348700-325b-40a9-913a-ec8706af6f73

[shanshanzheng-dev]

Hi @Anya1304 We'll be looking into this problem, thanks for reporting! Can't share timelines, but will report back here if we have a suggestion for you.

[jipyua]

hi @Anya1304 as synced in case 4417, these two sounds like duplicate, feel free to close 4417 and we will track the issue by this case. thanks.

[Anya1304]

@jipyua Hi! Any updates on this issue?

[jipyua]

hi @Anya1304 , for this issue, we can now only repro for ship version instead of debug version, it's some kind of blocking our investigation. The current findings are that this should be related with the memory and disked consumed by both the style apis and multiple file operations.

[jipyua]

hi @Anya1304, thanks for your patience. After further investigation, the root cause should be related with style.visibility api instead of insertFileFromBase64. (You can help verify this by comment the style.visibility api call.) We have fixed the style.visibility issue internally and it's now under validation and deployment process which should be available around early August with the latest M365 monthly update. Feel free to close this case or let us know for other feedbacks. thanks.

[Anya1304]

Hi @jipyua. Sounds great! :) Thanks for solving this problem. I will keep an eye out for an update. Thanks again!

[hnyrxs2]

Hi, @jipyua

I think this issue is also existing on html tables? can you please confirm. I am working on an add-in where i create html tables for reports and apply basic table grid style. it works perfectly before and now I encounter the same issues. Does the incoming fix on August covers this scenario? btw below its the gist I ran on ScriptLab and I encountered the same general exception error

async function run() {
  await Word.run(async (context) => {

    const defaultStyle: Word.Interfaces.TableUpdateData = {
      styleBuiltIn: 'TableGrid',
      font: {
        size: 11
      }
    };

    const testData = [
      ["Name", "Age", "Occupation"],
      ["Alice", "30", "Engineer"],
      ["Bob", "24", "Designer"],
      ["Charlie", "28", "Teacher"]
    ];

    const ccContainer = context.document.getSelection().insertContentControl();
    const table = document.createElement('table');
    const tableBody = document.createElement('tbody');
    testData.forEach(function (rowData) {
      const row = document.createElement('tr');
      rowData.forEach(function (cellData) {
        const cell = document.createElement('td');
        cell.appendChild(document.createTextNode(cellData));
        row.appendChild(cell);
      });
      tableBody.appendChild(row);
    });
    table.appendChild(tableBody);
    const htmlTable = ccContainer.insertHtml(table.outerHTML, Word.InsertLocation.start);
    htmlTable.set(defaultStyle);
    await context.sync();
  });
}

[hnyrxs2]

hello any updates on this? can someone confirm that the upcoming fixes would also cover the setting the style for HTML tables? @jipyua @Wenjun-Gong @shanshanzheng-dev

[shanshanzheng-dev]

Hi @hnyrxs2 Sorry for slow response. I see you have opened a new issue. Thanks for reporting. Let us discuss this issue on new issue thread https://github.com/OfficeDev/office-js/issues/4718.

[Anya1304]

Hi @jipyua, sorry to bother you. As far as I can see, the latest update on August 1st does not include this fix. Will this be in the next update?

https://learn.microsoft.com/en-us/officeupdates/current-channel#version-2407-august-01

[lamotik]

@jipyua looks like still an error, could you tell when can we expect fix?

[jipyua]

hi @lamotik , we need to take a further look based on our fix last time, from last fix the issue is mitigated in most cases, we need to further investigate the new edge cases, will share more information when we have some progress. thanks.