Open nickdekesel opened 1 year ago
Thank you for letting us know about this issue. We will take a look shortly. Thanks.
Similar to https://github.com/OfficeDev/office-js/issues/3037 ?
Forward this to heidi.
@nickdekesel, thanks for reporting the issue! Let me try to understand your scenario clearly to make sure we are following your right concern: Your office add-in is centralized deployed add-in, not installed from store. And you didn't expect the centralized deployed office add-in to show up in Ribbon since have equivalent COM Add-in exists. For this ask, I logged a backlog item(7375559) to track it. When have updates, we will post here.
If your office add-in is installed from store, then you clicked the office add-in ribbon button will get an upgrade dialog. After upgrading, the add-in button should dismiss from ribbon. Please let me know if this scenario not works for you.
Thanks again for your help to improve our quality!
Hi @gingerjia, yes the first scenario is correct. Our office add-in is a centralized deployed add-in and do not expect it to show up if the COM Add-in exists. For us this only happens on first load of microsoft word; the office add-in ribbon buttons will hide after clicking a ribbon button that opens the taskpane and the ribbon buttons will also not show on new windows.
Hi @gingerjia, is there any update on this issue?
@nickdekesel I am not from MSFT, but can you confirm that you still experience the issue? In #3037, they said this:
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!
Would be curious to hear if it fixed your issue, too.
Hi @wh1t3cAt1k, thanks for the update. Unfortunately our issue has not been resolved with that bug fix.
@wh1t3cAt1k and @nickdekesel , the deployed fix is for not loading add-in taskpane after installing from store if has equivalent add-ins defined.
The issue @nickdekesel reported here is related the office add-in button showing on the ribbon which is tracked by 7375559. And our partner team is working on the different issues based on priority. Please let us know if it's a big impact to your part.
Thanks @wh1t3cAt1k and @nickdekesel !
Hi @gingerjia, thank you for your reply. We do have a couple customers waiting for this which would be very happy if it would be fixed. So if it would be possible to give it a higher priority, that would be awesome.
For the equivalent add-in changes to take effect, the application needs to download and install the new manifest.
In Word, PowerPoint and Excel on Windows and Mac, the centralized deployment automatic install code does not run during core boot. These applications also do not normally parse manifests to show installed add-ins. Instead, they used a cached install state from a previous instance. The reason for using the cached install data and for delaying auto installation is that we want users to be able to start an Office application and get to edit their files as fast as possible.
To enable centralized deployment automatic install, application start creates a delayed task that will run after core boot completes. That delayed task calls into the centralized deployment service to determine if its state has changed. Note, there are caches on the server and clients that can delay how quickly the application can detect deployment changes so while updates should occur soon after deployment changes, they may not be immediate. If the task determines that the state has changed, it then loads the rest of the add-in framework and triggers additional calls to the centralized deployment service to download new manifests and reinstall add-ins. The install code does much of its work on background threads but eventually needs to update the ribbon on the UI thread which it only does during application idle.
Since the automatic install updates from centralized deployment are designed to stay out of the user’s way, it is possible for users to see updates after they started the add-in or a result of starting the add-in. It is not a bug that some users see the behavior you describe but it is bug if that is the only way for users to see updates come in. I can’t tell from the thread which one you are seeing?
Hi @Heidi-mu, I don't really know what Office does consider application idle, but it did not update the ribbon at all on the first opened window. However I was just testing the issue and it seems that it is resolved. I am not seeing the Office add-in ribbon button coming from the manifest anymore on the first window.
Did you by any chance do some changes that could have fixed the issue as part of another issue? I think this issue can be closed.
Hi @Heidi-mu, a lot of our customers are having this issue again. We did some further research to test multiple versions of the Microsoft Office Application. I've also tested this on two VMs to cover Windows 10 and Windows 11, 32bit and 64 bit. There was no difference and the result was the same on both VMs.
Current Channel: Version 2201 (Build 14827.20158) and above - Problem fixed. Version 2112 (Build 14729.20260) and lower - Problem exists.
Monthly Enterprise Channel: Version 2304 (Build 16327.20324) and above - Problem fixed. Version 2303 (Build 16227.20318) and lower - Problem exists.
Semi-Annual Enterprise Channel (Preview): Version 2308 (Build 16731.20234) and above - Problem fixed. Version 2302 (Build 16130.20714) and lower - Problem exists.
Semi-Annual Enterprise Channel: Version 2302 (Build 16130.20810) and lower - Problem exists. No version was tested where the problem was fixed.
My biggest concern here is that I have been unable to find an Office version on the Semi-Annual Enterprise Channel where the functionality works. This would likely also be a reason why we do have as many complaints as we do regarding "double add-ins showing". Enterprise customers would likely be using this release channel.
Is this something that could be looked in to?
@nickdekesel - We're in the process of looking into this issue and will post updates here when we have a better sense of feature timing.
We both have a COM add-in and a Office add-in with a manifest for our application and we would like the Office add-in not to load when we have the COM add-in loaded. We use the EquivalentAddIns section in the manifest for that but this is not respected on the start up of Word. After opening a new window the Office add-in is removed from the ribbon. Also in a window with the ribbon buttons when the taskpane is opened and closed the buttons will disappear.
Your Environment
Expected behavior
We expect that the Office add-in will not load and the buttons not show in the ribbon if we have an equivalent COM add-in loaded.
Current behavior
See summary above. We think it is a bug that the ribbon buttons are showing on first load of Word.
Steps to reproduce