4

I know this is not a question, but I was sent here by Rick Kirkham from here, and apparently asking on SO is the way to file bugs for Microsoft products :-p

When I use insertOoxml with the 'replace' parameter, Word will insert extra content at the end. For example, when using the following code in Script Lab, with a new, empty word document:

$("#run").click(run);

function run() {
    Word.run(function (context) {
        var ooxml = context.document.body.getOoxml();
        return context.sync().then(function () {
            console.log(ooxml.value.length);
            context.document.body.insertOoxml(ooxml.value, Word.InsertLocation.replace);
            return context.sync();
        });
    });
}

Every time you trigger this code, the word document will acquire an additional paragraph at the end of the body. It gets crazier when the document ends in a content control: take a new document, insert a new rich text content control. Triggering run will duplicate the content control and insert it inside itself (so you have two content controls, where one is contained by the other). Clicking run a couple of times will create a lot of nested content controls and slow down Word to a crawl. Inserting a plain text content control and triggering 'run' twice will crash word (appears to be a null pointer dereference).

This is not a problem related to Script Lab, but using Script Lab is the easiest way to reproduce it.

Word version: 1703, build 7967.2139, 2016 MSO (16.0.7927.1020) 32-bit.

Expected behavior: Word does not crash and does not introduce extra content.

Okay so let's make this a question: how do I use a full-document insertOoxml(ooxml, 'replace') without breaking my documents?

Thiez
  • 177
  • 1
  • 9
  • Thanks for moving the issue here. Regardless of whether it turns out to be a bug or there's a simple workaround, others who encounter the same symptoms will see this (and whatever eventual outcome it has). We have an existing bug in which the "replace" option (with insertOoxml) doesn't actually replace. The product team has raised the priority on it as a result of your issue. With regard to the crashing, does that happen outside of Script Lab? – Rick Kirkham May 09 '17 at 17:51
  • I'm not sure why Michael Zlatkovsky edited my post to add the 'scriptlab' tag, as I explicitly mentioned that the problem is not related. But yes, the problem also happens outside of Script Lab. I discovered the problem while developing a proprietary office-js plugin that I obviously can't post the source code of. Script Lab is used here only to create a minimal example that exhibits the crashing behavior. The `insertOoxml` operation tends to make Word crash a lot in general (also when using it on content controls), when the inserted ooxml is not to Words liking. – Thiez May 09 '17 at 22:01
  • 1
    A workaround that at least gets rid of the weird nested content control problem (and associated crashes) seems to be first inserting a new paragraph at the end of the document, with some non-empty content (I picked a zero-width space, but any non-empty string will do), then performing the `getOoxml()`, perhaps some ooxml changes, and then `insertOoxml(ooxml, 'replace')`, and the you keep deleting paragraphs from the end of the document until you've deleted the one you inserted, which can be recognized by its text content (`insertOoxml`-induced paragraph cloning does not copy the text content). – Thiez May 09 '17 at 22:28

1 Answers1

4

I verified with the newer build that Word does not crash, but an extra empty paragraph is indeed added. This bug was resolved yesterday and the fix will be available in the next month. Thanks!

yihua
  • 76
  • 1
  • Do I understand it also works correctly when the document ends with a plain text content control? :) – Thiez May 12 '17 at 19:47