Excel add-in with shared runtime - unhandled exception on displayDialogAsync

Question

I am working on an office taskpane add-in which uses popup windows (displayDialogAsync).

I expected displayDialogAsync to work the same whether using separate runtimes or a shared runtime, but under shared runtime a race condition seems to occur, often resulting in an unhandled exception

The addin displays dialog popups without a problem when using separate runtimes ( in the Manifest).

As soon as I switch to a shared runtime (), the following error is usually displayed on the popup dialog:

Uncaught runtime errors: ERROR Cannot read properties of undefined (reading 'register') TypeError: Cannot read properties of undefined (reading 'register') at t.register (https://appsforoffice.microsoft.com/lib/1/hosted/excel-win32-16.01.js:25:336996) at https://appsforoffice.microsoft.com/lib/1/hosted/excel-win32-16.01.js:25:1356347

The dialog still works properly if I close the error message by clicking on (X), but obviously this is not an acceptable user experience.

The error isn't always displayed, and sometimes it is displayed for a fraction of a second so that it's barely visible. It feels like a race condition.

Is there a way to prevent this? Could it be an issue with the appsforoffice library?

Thanks!

Answer 1

I was finally able to reproduce the error and to find a workaround in the process.
The key to reproduce is to enable the webpack dev server overlay option, this is the only way to get the error to display, as it never appears in the debug console because it runs in the popup window, which has a different runtime.
So this gets me to the workaround: one simply has to explicitly disable overlay in webpack.config.json and the error never appears. Btw I have no idea why/how all of a sudden overlay got enabled by default (there was nothing enabling it in the config), but that's a different story. So with overlay enabled and a shared runtime with long lifetime, one has to repeatedly open and close a dialog box. Sometimes there will be no error, sometimes the error will display for a fraction of a second and sometimes it will stay on like this:
Of course this makes me also realize that this would not be a problem in production as the error would never be displayed but I didn't know that before.