Office-js: Outlook for Mac crashes when setting html containing an hr in a table

[jacobx1]

When calling body.setAsync while composing a message in Outlook for Mac where the html contains a table with a horizontal rule in one of the cells, the app will crash.

Typical scenario is getting the body contents, modifying, then putting back. The original message has the offending content which causes the crash.

Expected Behavior

Expected to not crash but, instead, either handle or return an error.

Current Behavior

Crashes when setting such html

Steps to Reproduce, or Live Example

Call body.setAsync with the following html content: <table><tr><td><hr></td></tr></table>

Removing the <hr> will not cause a crash, and, an <hr> outside of a table does not cause a crash.

Reproduced in 16.28 - originally found in 16.27 before updating.

Context

This is causing users on the Mac platform to lose trust in using our add-in to augment their messages.

Your Environment

• Platform [PC desktop, Mac, iOS, Office Online]: Mac
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: 16.28 (19081202)
• Operating System: OSX 10.14.4 (Mojave)
• Browser (if using Office Online): N/A

Useful logs

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

Repro data

<table><tr><td><hr></td></tr></table>

Crash stack

I have submitted through crash reporter. Not sure how to reference.

[lliu113]

Thanks for reporting this @jacobx1! Looping in @macOutlookExtensibility to follow-up.

[AnjanaValsan]

Hello @jacobx1 , thanks for reporting! we can repro this bug and currently we do not have a workaround for this apart from suggesting you to keep

---

outside of the table. We are working with another team to get this resolved. I do not have an ETA at the moment. We will update the post here as soon as its fixed

[jacobx1]

@AnjanaValsan My current workaround is to strip <hr /> in tables by using the selector table hr. I am only doing this on the Mac client. I decided the formatting loss is better than having the client crash.

I'm looking forward to a fix so I can remove this workaround 😄

[exextoc]

We have fixed the bug and the fix should be available in latest builds.