Monthly Archives: December 2016
Bug in Outlook add-in commands showing command label instead of the add-in title on first use in a session
It seems there is a bug with the Outlook add-in commands when using the add-in from Outlook Web Access.
When using the add-in command (ribbon button) to open a task pane to show your add-in the label of the command button is shown at the top of the add-in where the add-in title should be. If you close the add-in and use the command button subsequent times in a session, then the add-ins title is correctly displayed.
Refreshing the browser window and again trying to use the add-in with show the command button label again (but just the first time the add-in is used).
I have been able to reproduce this issue with the Command Demo add-in from the Office Dev site:
1. Clone from GitHub https://github.com/jasonjoh/command-demo
2. Run locally using gulp serve-static (as per instructions in the GitHub repo)
3. Deploy the add-in manifest (as per instructions in the GitHub repo)
On first use of the add-in in a session (or after refreshing the browser window) the add-in title uses the label of the command button. In the case below the button label of “Display all properties” is shown.
If you close the add-in and then click on the same command button subsequent times then the correct add-in title of “Add-in Command Demo” is displayed.
This bug only seems to affect OWA, Desktop Outlook 2016 consistently displays the correct add-in title as shown below.
It would also be nice if the header we displayed in Desktop Outlook was consistent with OWA. As you can see from the screenshots above OWA shows the add-in icon in the header whereas Desktop Outlook just has the title without an icon.
I’ve logged this bug on UserVoice, if it’s causing pain for you please vote it up!
The basic premise of how this works is that the URL that you see in the browser window always refers to the same HTML page hosting your SPA e.g. http://myserver/spa-app/index.html
As the user navigates around the application this is done using URL fragments (the bit after the #) e.g. http://myserver/spa-app/index.html#configurationpage or http://myserver/spa-app/index.html#customerspage
This allows the browser to not go back to the server to request a page refresh (because we are always on the same page http://myserver/spa-app/index.html) but the SPA can react to the change of URL by reading the Fragment of the URL and route the user to the correct area of the app. The browser history also keeps track of the Fragment URL so this can provide a nice navigation experience.
That was a very basic explanation and I suggest reading this good primer on Fragment URLs (or hashbangs as they are sometimes referred).
So this leads us to Outlook add-ins and the problem I’ve encountered. Lets illustrate this with an example so that the use case becomes clear.
Imagine we have a simple SPA that shows a To Do list. The main screen of the app (http://myserver/spa-app/index.html) just shows the To Do list. There is also a second screen in the app for creating new To Do items(http://myserver/spa-app/index.html#newitem).
In the Outlook add-in manifest you provide a URL to your page that Outlook will load up in response to the user activating your app. The Microsoft preferred way of triggering this in Outlook is via Commands that appear as buttons in the Outlook Ribbon (in the desktop version of Outlook). If we create such a Ribbon button and specify the URL of the main screen of the app (http://myserver/spa-app/index.html) everything works just fine. Within the app itself, it can navigate off to http://myserver/spa-app/index.html#newitem to show the screen to create a new item. But what if we want to provide Outlook Ribbon buttons that streamline the process and let the user go straight to creating a new to do item rather than first having to open the app, then navigate within the app to create the item? Having the main functions of you app accessible as Ribbon buttons in Outlook is a huge time saver for users.
So what happens when we try to use the new item URL Fragment behind a Ribbon button?
If we specify a URL of http://myserver/spa-app/index.html#newitem in the add-in manifest, the following is the URL that Outlook actually launches the add-in with:
Obviously this is going to wreak havoc with your SPA. The original URL Fragment #newitem looks to be encoded in the resulting URL as “&_serializer_version=1newitem” although how to reliably detect and extract this and then do the correct routing within your SPA is challenging!