Google kills showModalDialog API in Chrome 37 and does evil to Exchange

Google, that well-known purveyor of the “don’t be evil” slogan, certainly cast the evil eye on Outlook Web App (OWA) and the Exchange Administration Center (EAC) when it changed version 37 of the Chrome browser (both 32-bit and 64-bit) to deprecate the showModalDialog method, which creates a modal dialog box that retains input focus while open. The method has been around since the early days of IE and is disliked by some developers because of the way that it grabs input focus so that the user cannot switch windows while the dialog is open.

Google believe that showModalDialog is a “bad API” that, according to their measurements, is not used extensively. Bad API or not, it looks like OWA and EAC use it quite a bit, so I guess those pages weren’t included in the 0.006% of measured page views as calculated by Google. That's unsurprising because many of the OWA/EAC page views would have been inside corporate firewalls.

The net effect is that quite a few of the pop-out dialogs used in OWA and EAC have stopped working, much to the surprise and consternation of companies that have standardized on Chrome or allow users to choose their preferred browser.

For example, I used Chrome version 37.0.2062.120 (64-bit) to connect to my Office 365 E3 tenant. I then opened EAC and went to the Mail Flow/Connectors section and opted to create a new outbound connector. I then opted to route mail through a smart host, but the dialog that should then appear for input of details for the smart host did not appear.

This is pretty typical of the behaviour in EAC where most of the interface works until you get down to the detail of editing or inputting data. Confusingly and frustratingly, some features work fine whereas other parts that seem pretty similar do not. I assume this is due to a detail of code implementation.

On-premises customers have reported many problems using OWA with Chrome when connected to Exchange 2010 or Exchange 2013 servers. Here the problems are more fundamental. While an administrator can always resort to PowerShell to get work done, the bug has a larger impact on users who find that they can’t attach files to messages or browse the address book to add recipients to messages.

Some fixes have been suggested, including making sure that the latest version of Silverlight is installed on all PCs and applying registry changes to put off the day of doom until May 2015. Of course, you can always dump Chrome until the problem is fixed, but that’s not a great solution if you have settled on Chrome as the standard browser. Too many differences exist between Chrome and IE11 for instance for users to move over without the inevitable help desk calls asking where bookmarks have gone to and why their passwords for different web site are no longer available.

The original plan was for Google to remove showModalDialog in Chrome version 36, which was finalized on July 16, 2014. This didn’t happen and the method continued to work for another month until the final version of Chrome 37 was released on August 26. Google’s note announcing the release didn’t specify that showModalDialog had finally been consigned to the great byte wastebasket.  Since then Exchange customers have been running into problems after Chrome automatic updates. It’s not a great situation to be in.

Although Google is obviously responsible for making the change to version 37 of their browser and had good reasons to remove the API, the question for many is how a situation arose where a browser update could have such serious consequences for a major Microsoft product. 

After all, Microsoft has long supported Chrome as one of the browsers capable of delivering the premium user interface for OWA. In that time, OWA has been through at least four major redesigns (Exchange 2007, Exchange 2010, Exchange 2010 SP1, and Exchange 2013), so you’d imagine that the OWA developers are pretty literate when it comes to the ups and downs of living with the Chrome programming model. Indeed, Microsoft even delayed OWA for Android until Google included Chrome as the standard browser in the Android Kitkat release. It certainly seems like someone dropped the ball.

As you’d expect, Microsoft is well aware of the issue and is busy creating fixes for the OWA and EAC code to take account of the new reality. It will take time to design, develop, and test before the new code can appear in Exchange Online and thereafter in a cumulative update, so you might have to make some changes in your deployment plans like switching to a different browser to keep things running smoothly in the meantime.

The impact of accelerated development in the cloud era clearly affects the stability of software. Ecosystems like Exchange are enormously complex because so many moving parts exist, many of which are controlled by no single player. And when everybody's developing at a rate of knots, chances are that things will break.

So Chrome users beware… a seemingly innocuous and well-reasoned change can have unanticipated consequences. Isn’t that always the way with software? I bet we’ll have fun discussing this and other unanticipated recent code “enhancements” at Exchange Connections in Las Vegas this week…

Follow Tony @12Knocksinna