🐛 Equivalent add-ins mechanism not completely disabling the add-in, side panel opens

wh1t3cAt1k commented 1 year ago

@Wenjun-Gong bringing this to your attention as it feels that the feature is not working as designed at all...

Equivalent add-ins mechanism has "holes" in it and the modern add-in ends up being loaded anyway, even though there is no way to launch it manually from the document.

Background event handlers and business logic gets duplicated with both the COM add-in and the modern add-in processing them.

Your Environment

Platform [PC desktop, Mac, iOS, Office on the web]: PC desktop
Host [Excel, Word, PowerPoint, etc.]: Excel
Office version number: 2211 (15831.20190 click-to-run)
Operating System: Windows 11

Expected behavior

We expect the equivalent add-ins mechanism to completely prevent the modern add-in from loading, even in the background.

This last bit is very important to avoid both the legacy and the new add-in from double-doing business logic that works on worksheet changed events and calculation events.

When you try to insert the add-in from AppSource, we expect to see a message like "The add-in was registered in the file, but will not be launched in this session because an equivalent COM/XLL add-in is already running".
When you open a file with modern add-in registered, and an equivalent COM/XLL add-in is running, you do not get the prompt to "allow the addin" at all, it should just silently continue.

It is insufficient to just remove the add-in's button from the ribbon like it seems to happen now - from the video below you will see that inserting it from the store leads to the side panel to pop anyway.

Current behavior

Apparently only the ribbon button gets disabled. So it's not possible to open the side panel manually, but it's possible to get side panel to open and business logic to start executing by either:

Inserting modern add-in from the store,
or opening a file where the modern add-in is recorded in webextensions

Steps to reproduce

https://www.youtube.com/watch?v=teP0s9EGUjg

(the "meat" starts at 6:30 but I urge you to watch the full video for the context)

Context

This might be important:

Shared runtime
Office.addin.setStartupBehavior(Office.StartupBehavior.load);

Unfortunately I had to turn off the COM equivalence part for now because the behaviour is so weird (so now it cannot be used for repro), but it should be quite easy to replicate with a contoso-like add-in.

There is no "clean" workaround because from the modern add-in, we have no API way of detecting if the equivalent add-in is running. We will employ some workbook-level hacks.

ghost commented 1 year ago

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

wh1t3cAt1k commented 1 year ago

neville-jones commented 1 year ago

some parallels with #2621 ?

gmichaud commented 1 year ago

some parallels with #2621 ?

@neville-jones thanks for linking your issue; I saw it when I was researching equivalent addins last week and forgot to mention it to @wh1t3cAt1k. In our case the ribbon button does not appear, however:

The side panel pops out when the addin is installed after the user opens a file
The side panel is often blank/empty and I’ve cases where two side panels open simultaneously (one blank, the other one showing a prompt that there’s a new addin to install)
Even if user accepts installation of a new addin, it doesn’t seem to « stick »; next time they reopen Excel and a file that links to the addin they will be asked again
The user is still able to install the addin from store, and if they do so they get no message whatsoever that there’s an equivalent addin installed. Even though ribbon button will be hidden, event handlers and logic in the modern addin still get invoked

RuizhiSunMS commented 1 year ago

@wh1t3cAt1k, thanks for the reporting and sorry for the late response since our team is encountering health issues. Will handle this issue as soon as our engs are back.

wh1t3cAt1k commented 1 year ago

Thanks @RuizhiSunMS , please let us know when you have an update.

gingerjia commented 1 year ago

@wh1t3cAt1k Thanks for reporting the issues! For loading office add-in side panel when installing it from store issue, we have fixed it and when deployed, will update here. This is tracked by bug 7368635.

For below two requirements, there are feature gaps and are tracked by item 7375597. Our PM will priority it.

When you try to insert the add-in from AppSource, we expect to see a message like "The add-in was registered in the file, but will not be launched in this session because an equivalent COM/XLL add-in is already running".
When you open a file with modern add-in registered, and an equivalent COM/XLL add-in is running, you do not get the prompt to "allow the addin" at all, it should just silently continue.

Thanks!

wh1t3cAt1k commented 1 year ago

Thanks @gingerjia ! Regarding bug 7368635, will it require the users to update Microsoft Office, or is the fix on the Office.js side?

Same question about item 7375597. (I would ask to keep this item open for tracking until both are fixed...)

Also, heartfelt thank you for a quick turnaround and prioritising this issue for us. I really appreciate it ❤️

gingerjia commented 1 year ago

@wh1t3cAt1k, for bug 7368635, yes, it will require the users to update Microsoft Office. We will let you know when the build is available.

For item 7375597, may we know the detail impact to your and PM can prioritize accordingly? Because this is a kind of feature requirement and need to consider the overall design, so the fix may not as quickly as the above bug fixing.

Please feel free to raise your concerns or questions, really appreciated for your help to improve our quality!

wh1t3cAt1k commented 1 year ago

@gingerjia @Wenjun-Gong I would consider 7368635 and 7375597 two inseparable parts of the same user story: as a user who uses an equivalent add-in, I know nothing and don't want to know anything about the modern add-in registered in the document to avoid confusion.

At least this part:

When you open a file with modern add-in registered, and an equivalent COM/XLL add-in is running, you do not get the prompt to "allow the addin" at all, it should just silently continue.

Is very important to us.

Think about this from the user perspective: someone opens a document with our COM add-in installed. Imagine that 7368635 is fixed and they don't see our modern add-in's ribbon button, but still get a message about "allowing the add-in"!

The user:

"What add-in are they talking about"?

Therefore, in my opinion, 7368635 and 7375597 (at least the second part) need to be implemented together, soon if possible, because as it stands, the equivalent add-ins feature feels broken from our and the user's perspective...

Wenjun-Gong commented 1 year ago

Hi @wh1t3cAt1k , thanks for reporting the issues.

Regarding the behavior of "asking for user to install" even the equivalent COM add-in is defined and installed, I can explain a bit. The JS add-in installation is per user and once an user has installed it, the JS add-in would be available on multiple platforms that the add-in supports (Windows, Mac, Web). Today Office would hide the ribbon buttons of the Office JS add-in when the equivalent COM add-in is installed but does not prevent installation as the same user may open the file on other platform like MAC or Web browser where the COM add-in is not available. You can find the details here: https://learn.microsoft.com/en-us/office/dev/add-ins/develop/make-office-add-in-compatible-with-existing-com-add-in#equivalent-behavior-for-users

This dialog to ask for installation should only show up once for one particular user if they choose to install the add-in. And after that, they can use the COM add-on on Windows, and use the JS add-in in Web / Mac. We will have engineers to take further look to see whether there is a way to defer the installation to device / end-point don't have the COM add-in installed. Before we make any improvement on this, I would suggest you ask your end user to choose the button "allow and continue", they should not see that again. If you see any other behavior which blocks your users, please do let us know.

Thanks.

gmichaud commented 1 year ago

This dialog to ask for installation should only show up once for one particular user if they choose to install the add-in.

@wh1t3cAt1k I briefly remember seeing this pop up over and over when we tried the equivalent addins (COM side of things). Can we still replicate this, i can try with a side loaded manifest if needed.

wh1t3cAt1k commented 1 year ago

@gmichaud I never replicated it showing multiple times, you seemed to have it worse than me... At any rate, I think this dialog is very confusing for someone who does not even understand what add-in that is about (since they use the legacy COM one already)

gingerjia commented 1 year ago

@wh1t3cAt1k I'm investigating the root cause about below dialog. I suppose you haven't installed the web add-in before when you open the doc and got the below dialog, right? If not, could you share the details steps and also share the doc that can repro the issue? I checked the some attached file in https://github.com/OfficeDev/office-js/issues/2878 and found the add-in was set backgroundApp state=1, which means the add-in will auto-run after doc open. If you haven't installed the add-in before, then will pop up the above dialog to remind user to install it.

Is it possible to detect there is already an equivalent COM add-in existed and running before clicking [Allow and Continue] to install the web add-in? Sorry we cannot achieve it with current design. Because before user agrees to install the add-in, we cannot download mainfest. Without manifest we cannot know it has an equivalent COM add-in or not.

Please let me know if any further questions or suggestions! Thanks very much!

wh1t3cAt1k commented 1 year ago

@gingerjia cc @Wenjun-Gong @jakobpn

I suppose you haven't installed the web add-in before when you open the doc and got the below dialog, right?

Correct, this is exactly the case, and other cases are outlined in my original message and the video.

Sorry we cannot achieve it with current design. Because before user agrees to install the add-in, we cannot download mainfest.

I do understand that it's not possible with the current design, but I would argue that this design is seriously flawed from the UX standpoint and needs to be fixed.

At some point the UX concerns become so strong that trade-offs must be made. One might argue that downloading the manifest can be a relatively safe operation (it can be done sand-boxed, or server-side with a virus check etc., if security is a concern).

As you mentioned, our scenarios is already covered by items 7368635 and 7375597 in the backlog, and I strongly feel both are needed for proper UX, which would get us at least halfway to the seamless experience people are used to with XLL/COM add-ins.

I am inviting @gmichaud and @4tti to the discussion.

4tti commented 1 year ago

I just came across this thread, @wh1t3cAt1k ... did you meant to invite me? (my profile is 4tti not 4ttt). Anyway, my 2 cents - we are lucky as we don't use 'Equivalent add-ins'. We decided to have the new version considered as a totally new product and independent of the legacy product.

wh1t3cAt1k commented 1 year ago

@gingerjia just want to follow up if there has been any update on the issue?

gingerjia commented 1 year ago

@wh1t3cAt1k, the bug 7368635 has been deployed to PROD at 1/27. That means when user installed an add-in from client store, it won't open the add-in's taskpane automatically if has Equivalent add-ins defined. Please let us know if still hit the problem after updating the new version. Thanks very much!

wh1t3cAt1k commented 1 year ago

Thank you @gingerjia ! I will test and report back.

However another important UX limitation that people were complaining of is the unnecessary message: "this add-in comes from the office store", which then would do nothing because of the equivalent add-ins.

Will this be addressed too?

gingerjia commented 1 year ago

@wh1t3cAt1k for 7375597, we need to evaluate different scenarios and come up with a reasonable design for it. When have progress, we will keep you updated. Thanks for your understanding!

wh1t3cAt1k commented 1 year ago

Hi @gingerjia @JinghuiMS just wondering if there has been any update on item 7375597 and what is the direction the team will be taking. Thanks

JinghuiMS commented 1 year ago

@wh1t3cAt1k Thank you for your continued attention. I will add the person responsible for this issue so that you can get more timely and accurate updates. @yatibawri1 Could you share the progress of workitem#7375597 here? Thanks.

wh1t3cAt1k commented 9 months ago

@JinghuiMS @SiruiSun-MSFT @yatibawri1 @gingerjia we are revisiting this item because right now we are depending on a "poor man's" userland implementation to check whether the legacy add-in is installed.

We run a certain custom function on start-up, and if it returns a value that is only returned from the legacy add-in, we abort the initialization and display a message in the task pane.

However, this solution does not at all work with protected workbooks.

I would appreciate to hear any news or update on your internal work item #7375597 as it is impacting us!

Ideally if the legacy add-in is installed the user should not see any prompt like "This add-in comes from the office store" because it's irrelevant for this add-in.

wh1t3cAt1k commented 4 months ago

@gingerjia in the last several days, we are seeing what seems to be a regression of the bug 7368635 that you mentioned in your comment.

We are receiving support escalations from clients because of that. Screenshot of the issue that started occurring:

The ribbon of the modern add-in doesn't appear, just the side panel.

OfficeDev / office-js