OfficeDev / office-js

A repo and NPM package for Office.js, corresponding to a copy of what gets published to the official "evergreen" Office.js CDN, at https://appsforoffice.microsoft.com/lib/1/hosted/office.js.
https://learn.microsoft.com/javascript/api/overview
Other
668 stars 95 forks source link

Broken warning when linking to custom protocol #4011

Open joerivv opened 7 months ago

joerivv commented 7 months ago

When a button links to an external (standalone) tool via a custom-defined protocol (so instead of https://, something like pxl-risk-finder://), Excel comes up with this message:

Screenshot 2024-01-15 at 14 46 38

There are two Cancel buttons, and the "Always remember" checkbox does not work. If the add-in also features a taskpane (side panel), and if this taskpane has been opened at least once, the warning appears in the taskpane instead:

Screenshot 2024-01-15 at 14 44 36

Note that if you close the taskpane and then follow a link to a custom protocol (by clicking a CommandButton in the ribbon, say), the warning appears in a now invisible taskpane (!).

In the taskpane the "Always remember" checkbox works as expected. However, if you accidentally click “Cancel” after you check “Always remember”, there seems to be no way to get the question again (not even restarting your computer or reinstalling the Add-in works). At that point, links to external tools are permanently broken.

Your Environment

Expected behavior

A predictable way to warn users about links to custom protocols, with working controls. Most importantly: a way to define trusted protocols (or disable the warning altogether) in the manifest or through the JavaScript API.

Current behavior

Inconsistent warnings, broken controls (see above), no way to undo a decision after ticking "Always remember", and no way for developers to predefine which protocols can be trusted.

Steps to reproduce

Without a taskpane:

  1. Create a new Excel add-in
  2. Add a CommandButton that follows a link to a custom protocol (protocol does not have to exist, window.location = 'test://'; will do)
  3. Run the add-in and click the CommandButton
  4. Check "Always remember" and click "Cancel"
  5. Click the CommandButton again. You will get the warning again.

With a taskpane:

  1. Modify the add-in by adding an empty taskpane and a way to make it visible (a CommandButton that calls Office.addin.showAsTaskpane() should do it)
  2. Open the taskpane and try to follow the custom-protocol link.
  3. Tick the checkbox "Always remember" and then click "Cancel"
  4. It is now not possible to undo your choice.

Context

For rollouts in large organizations, it's not ideal that end users have to go through these steps for every protocol. Especially in our case, where the protocols are known to be safe and present, it'd be ideal if this warning could be repressed by us (the developers) or else at least by an admin.

Wenjun-Gong commented 7 months ago

@SiruiSun-MSFT would you please help to take a look?

joerivv commented 7 months ago

@SiruiSun-MSFT Did you have a chance to look at this issue?

SiruiSun-MSFT commented 7 months ago

Hi @joerivv, Sorry for the late response. Since our team is not the owner of this feature, we have already internal connected with partner team. If there is some update, will reply here for your information. Thanks for your patience!

joerivv commented 6 months ago

@SiruiSun-MSFT Has there been a response from the partner team yet? Or is there perhaps someone we can contact directly? I am asking because while the issue may seem a silly edge case, this roadblock is actually the only thing stopping us from deploying and marketing our add-in, proving to us and showcasing to our clients the future viability of OfficeJS development. Any update much appreciated! Thanks!

SiruiSun-MSFT commented 6 months ago

Unfortunately, we have not received an effective reply from the partner team yet. We have already sent another email to seek for help. If there is any updates, we will reply here ASAP.

zhenhuangMSFT commented 6 months ago

Hey @joerivv, our partner team has taken over and is looking into this issue. Thanks for your patience!

zhenhuangMSFT commented 4 months ago

Hi @joerivv, this should have been fixed. Could you help verify? Thanks!