-
Notifications
You must be signed in to change notification settings - Fork 805
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Office.AutoShowTaskpaneWithDocument with shared runtime? #776
Comments
Hi - The instructions for auto-opening with a Shared Runtime are a bit different than for just a task pane. Did you follow these instructions to set it up? https://learn.microsoft.com/en-us/office/dev/add-ins/develop/run-code-on-document-open |
@slabereemsft thank you for your response. Yes I did, and those instructions work great for Word desktop app on Windows and Mac with shared runtime. However, they do not work for Office 365 Web. The issue appears to be that on Word for web, the startup, although I call Office.addin.setStartupBehavior(Office.StartupBehavior.load) in my Office.onReady, and see it succeed (i.e. I can later call Office.addin.getStartupBehavior and see the value is StartupBehavior.load) it does NOT actually seem to persist. If I refresh the web page, or open the document again, a) No add in code/Office.onReady is not called until I manually interact with the ribbon, and when I do interact with the ribbon, if I start by logging Office.addin.getStartupBehavior I see the value is 'none' again. I believe I understand how this is supposed to work since I was able to make it work on desktop version of Word, but this seems like a bug in the Web version. If you are able to make this behavior work with Word for Web, maybe this would be a useful example to add to https://github.com/OfficeDev/Office-Add-in-samples? Please let me know if you need any further info from me. |
Hi @ijoukov1, I tested this by modifying the auto open task pane sample to use shared runtime as you did. the startup behavior works correctly and I'm not able to reproduce this issue. Can you provide more steps on how you are running the sample (localhost I assume) and how you sideload it in the browser? In my case I set auto open to on, close the browser tab, open a new browser tab and reload the document, and the task pane opens automatically. If I turn it off, then the task pane does not open. Thanks! |
Oh also, which browser are you using? I can test using the same browser and see if I can get it to repro. Thanks! |
@davidchesnut I am using Chrome. I plan to upload a simple reproducible example to help move this forward, just need to get sign off first so may take a bit of time. I want to clarify though, do you still expect there to be a ShowTaskpane action like so on one of the ribbon buttons for this to work, even with shared runtime? |
Hi @ijoukov1, it's recommended to have a way for the user to get to the task pane in case it is closed (like they closed it). You can use the manifest to set up the button, or call code to show it Show or hide the task pane of your Office Add-in |
Question
Hello, we previously had auto-open working by essentially following the example in https://github.com/OfficeDev/Office-Add-in-samples/tree/main/Samples/office-add-in-commands/auto-open-task-pane, and it worked as expected.
However to support some additional functionality like Ribbon commands that execute functions instead of just opening a task pane at a URL, we are converting our add in to use a shared run time. After changing to a shared runtime, the AutoOpen behavior stops working correctly. I am able to get it to open my add in but instead of loading the specified SourceLocation it just seems to be in some sort of error state with a blank add in panel that doesn't even seem to have loaded a browser runtime.
Is auto open supported with shared runtime and ExecuteFunction commands, and if so, are there any special instructions or examples that I could see for how it is different from without a shared runtime?
I should add, even with the shared runtime it Works fine on Office 365 for web, just not on Desktop versions of Word.
The text was updated successfully, but these errors were encountered: