Word hangs when attempting to undo a change that insert four or more comments

[greysteil]

Provide required information needed to triage your issue

If an add-in inserts four or more comments (using myRange.insertComment(...)) in a single context.sync() call, attempting to undo that action (by pressing cmd+z or selecting "Undo typing" from the menu) causes Word to hang. This happens in both Word for Mac and on PC desktop (I haven't tested Word online).

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC desktop, Mac
• Host [Excel, Word, PowerPoint, etc.]: Word
• Office version number: 16.86 (24060916) and Version 2405 Build 16.0.17628.20110
• Operating System: Sonoma and Windows 11 (Parallels)
• Browser (if using Office on the web): N/A

Expected behavior

Ideally, pressing undo should undo the change. If that is not possible, the undo button should be disabled. Pressing undo should never cause Word to hang.

Current behavior

See above

Steps to reproduce

1. Insert four comments in the same context.sync()
2. Attempt to undo the above insertion by selecting "undo typing" from the menu (or any other method of calling undo)
3. Observe that Word hangs

Link to live example(s)

N/A

Provide additional details

Note: if only three comments are inserted, Word performs the undo near-instantly

Context

In my Word add-in, I would like to add "apply all" functionality, and have that insert comments and redlines throughout the document. Because of the bug, if I ship this functionality to customer I risk them losing their work if they click "apply all" and then press "undo". Since the consequence for my customers would be so severe I can't ship the feature in this state.

A workaround for the issue is to apply comments in batches of three. This is undesirable because it means uses have to click "undo" multiple times to undo the "apply all" change.

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.

[microsoft-github-policy-service[bot]]

Thank you for letting us know about this issue. We will take a look shortly. Thanks.

[jipyua]

hi @greysteil thanks for let us know this issue. But unfortunatelly with the following code, I can't reproduce the issue you mentioned, undo/redo is working correctly if I inserted a comment on each of more than 6 paragraphs using the following code. Can you help confirm what's the missing information? thanks.

const pars = context.document.body.paragraphs;
pars.load();
await context.sync();
for (var i=0; i<pars.items.length; i++)
{
  pars.items[i].getRange().insertComment("abc");
}
await context.sync();
console.log("comments inserted");

[greysteil]

Oh interesting - I thought this was any time four or more comments were inserted, but it looks like there are some caveats.

@jipyua can you replicate that Word hangs when undoing the following?

Word.run(async (context) => {
  myLoc = context.document.body.paragraphs.getFirst().getRange("Content")
  // myLoc = context.document.body.getRange().search("some text").getFirst()

  for (var i=0; i<4; i++) {
    myLoc.insertComment("abcde");
  }

  await context.sync();
  console.log("comments inserted");
})

That's the simplest snippet that causes the problem for me. A couple of notes:

• The comments have to be 5 characters or longer (hence abcde). Undo works fine if they're shorter. In reality, almost all comments are 5 characters or longer, so this doesn't help our users.
• I have to narrow the paragraph's range by passing "Content" to getRange to get the bug. Undo works fine if I don't specify that. Again, in reality, most production use cases insert comments based on a search(...) result, which gives ranges that don't include the end of paragraph break.

I've included a commented out line of code that replicates the bug in the more common case where the location you're commenting on comes from search(...). It expects the doc you're running on to have the words "some text" in the document body.

[jipyua]

Thanks for sharing the detailed code, I am able to replicate the issue you mentioned earlier and have opened an internal item 9072602 to track this. We will triage the priority based on the impact and severity and share here if we have some progress. thanks.