Task pane sometimes doesn't render on an existing workbook where startupBehavior was set to 'load'

[wh1t3cAt1k]

Your Environment

PC Desktop
Excel 2211 (Build 15831.20208 Click-to-Run)
Current Channel
Windows 11
Shared runtime add-in
The workbook has start-up behaviour "load" recorded

Expected behavior

No rendering issues

Current behavior

The task pane is empty.

Steps to reproduce

Use a sideloaded sample add-in, insert from a local fileshare in Excel Desktop for Windows: https://github.com/VelixoSolutions/VelixoNX-blank-taskpane-demo

Click on the Ribbon button. This will record the startupBehavior.load, as you can see from the add-in code.

Save & close this workbook.

Open the workbook again and click the add-in button.

Sometimes (not every time!) the task pane will be empty.

See video (it shows example on our add-in Velixo, but manifestation is the same on the test add-in: https://youtu.be/NCUoexey6YA

Interesting things:

• It's as if the WebView rendering surface itself is gone. You cannot even right-click to inspect the element.
• If you resize the task pane, the WebView suddenly appears (see video link above)

Crucial component here is: shared runtime, and startupbehavior.load recorded in the workbook. Only on Excel for Windows desktop.

Context

We had support requests from customers.

[Dengshan2018]

This issue was fixed.

[wh1t3cAt1k]

@Dengshan2018 what is the Excel for Windows or Office.js build that contains the fix? We can still replicate that on our side on the Current Channel.

[Dengshan2018]

@wh1t3cAt1k , what Office version? We might port back the fix to earlier version.

[wh1t3cAt1k]

@Dengshan2018 it is mentioned in the ticket environment: Excel 2211 (Build 15831.20208 Click-to-Run), or did you mean another metric?

[wh1t3cAt1k]

@nkkinariwala @Dengshan2018 just wanted to follow up on the above.

[wh1t3cAt1k]

@Wenjun-Gong @nkkinariwala @Dengshan2018 🙏

[Dengshan2018]

@wh1t3cAt1k, The fix is in CC preview (16.0.16026.20170)

[wh1t3cAt1k]

@Dengshan2018 thank you for the clarification. Could you please indicate when it would hit the Current Channel (non-preview) approximately?

[randomevents]

@Dengshan2018 at the very least this needs to be ported back to the Semi Annual Enterprise Channel (2208 15601.20456). Is there a workaround?

[Dengshan2018]

@randomevents the issue might be only easily repro in dev environment. The issue can be worked around by resizing the taskpane.

[Dengshan2018]

@wh1t3cAt1k and @randomevents , Production CC is deploying 16.0.16026.20200.

[randomevents]

@Dengshan2018 That's a known and horrible workaround that pushes the bug unto the users. Is there a possible programmatic workaround. While a fix in 16.0.16026.20200 is great news for me, it's not great news for the Semi Annual Enterprise Channel.

[Dengshan2018]

@randomevents, the issue is repro only if shared runtime is used. https://learn.microsoft.com/en-us/office/dev/add-ins/develop/configure-your-add-in-to-use-a-shared-runtime

[randomevents]

@Dengshan2018 , yes, everyone is aware that it's because of the shared runtime, i.e. the preferred method of creating the add-ins. Can you tell us something useful instead of just repeating yourself?

[wh1t3cAt1k]

@randomevents I think we should stay diplomatic...

@Dengshan2018 I'd venture to guess that by now the shared runtime is pretty much the default, so I would vote it makes sense to backport the fix to semi-annual channel as well.

[Dengshan2018]

@wh1t3cAt1k just rephrase: the issue might repro in certain environment with shared runtime. Didn't hear any escalation from add-in users yet. 16.0.16026.20200 is 100% in Production CC. Resizing taskpane is the workaround or updating to latest version. Semi-annual preview with the fix could be out in a month. There is no plan to backport to semi-annual so far. You can escalate the issue through customer channel if your customers are heavily impacted by the bug. The severity of the bug might be re-adjusted.

[wh1t3cAt1k]

@Dengshan2018 @Wenjun-Gong Just to be clear, I am not related to the other commenter (randomevents).

On my side, I appreciate your effort in getting this fixed and understand it might not be convenient to backport this fix to the semi-annual channel for some reason. Actually, on a combination of Shared Runtime and startupBehavior.load, the issue replicates very frequently, however I tend to agree that the severity isn't that big.

However, offering a general philosophical thought: maybe it's a good idea to treat escalations from partners with at least the same priority as escalations from customers, and maybe higher. This is because most frequently, customers will not complain to Microsoft about the behaviour, they will reach out directly to the vendor support: "Your stupid add-in is not working!", which may reflect in product reviews.

My team has verified that the issue is gone.

I think it's safe to close, just please think on the above point as part of your general product strategy...