Blog Archives

Beware the Office.js Dialog API falling silent under IE11

Issue Description

I’ve been leveraging the Office.js Dialog API recently and found a scenario where I just couldn’t get it to behave properly. At the moment this appears to be either a bug or limitation of the Dialog API. I found that the calling MessageParent() from the dialog fails to trigger the registered callback method in the host add-in when running in IE11 (on both Win 7 and Win 8.1)

Following are the steps to reproduce the issue with the Dialog API under IE11 where the messageParent() method fails to trigger the corresponding event back in the host add-in.

 

Steps to Reproduce

To reproduce the issue I’ve taken the Dialog API example from dev.office.com and hosted in Azure.

https://github.com/OfficeDev/Office-Add-in-Dialog-API-Simple-Example

Then I updated the manifest to point to the location where I hosted it, and then tried to use it in the different environments (I made no code changes to the example).

For these repo steps I just opened Word Online in IE11 and side loaded the manifest. The issue also exists using Office Desktop on a machine with IE11 installed (but not Edge) as Office will then be trying to use IE11 and you get a similar issue.

On Windows 10 in Chrome or Edge (works as expected)

clip_image002

clip_image004

On IE11 on WIn 7 & Win 8.1 Fails to Communicate back to Parent Add-in

Now if I use the same manifest and try it from Win 8.1 IE11 the pop up dialog fails to send the message back to the parent add-in when you press a button.

clip_image006

If you close the dialog, the dialog close event method does get triggered back in the parent add-in (this is the same behaviour that we observed when developing our add-in).

clip_image007

clip_image008

I am aware of the documented issue of the Dialog API not working in mixed zones under IE (especially with difference in protected mode between the host page and the add-in/dialog URLs).

In the scenario above the host (Word Online) page is in the Internet Zone with Protected Mode off

clip_image009

And the add-in is also running in the Internet Zone with Protected Mode off

clip_image010

Advertisements

How to access properties of Office.js objects that don’t exist in the Typescript definition file

When developing Office Add-ins and using Typescript, I’ve found the Office.js Typescript definition file available at DefinatelyTyped to only support a fraction of the objects and properties that are available within the Office.js library.

To give you an idea of what I mean, here is a list of properties that are available on the Office.context.mailbox.item object (according to the API documentation in the Outlook Dev Center)

clip_image004

 

And here are all the properties of that same object using the Typescript definition file:

image

I was left wondering where the rest of the properties were. They simply don’t exist in the Typescript definition file. So this leaves us in a bit of a bind, because we are using Typescript we can’t just reference a property that doesn’t exist in the Typescript definition file (even though we know the property will exist at run-time). The Typescript compiler will do it’s job well and throw up a compile time error that the property does not exist.

Without going to the effort of taking the Office.js Typescript definition file and extending it yourself to start filling it out you may want to consider the following work around.

We can declare an object in Typescript without a specific type by specifying it’s type as any. If we do this to an object within the Office.js library we can get an un-typed handle to the object. As the object in now un-typed, we can call any property of that object we like (whether it exists or not). Below is the code that will give us access to the subject of the email that is not available in the Typescript definition file.

image

If the property exists at runtime then great, if not then we will get a run-time error. It is definitely a step backwards and is why we use Typescript in the first place!

It would get a bit unwieldy if you used this technique throughout your code, and I’d like to think that as we get updated Office.js Typescript definition files that we can remove this type of code from our project and access the properties in a properly typed way. To isolate your use of this technique to a central location and facilitate removing the code later on, I’d suggest creating a class that takes in the object (e.g. Office.context.mailbox.item) then inside the class it gets the un-typed handle to the item and provides methods or properties that return the missing properties (with the bonus that the values returned can have a type associated with them). Below is an example of a class with static methods that provide typed access to missing properties on a mailbox item.

image

Hopefully the Office team will see the value in publishing current and complete Typescript definition files so we don’t have to write code like this in future.

Fingers crossed.

%d bloggers like this: