Chrome problem for Exchange due to Google haste and Microsoft inattention

I’ve been pondering how Google managed to do evil to OWA and EAC (and Microsoft Dynamics, SAP, and other enterprise applications) when it removed the showModalDialog method from Chrome Version 37. As reported in KB3001145, the issue affects different elements of OWA and EAC in both the on-premises (Exchange 2010 and 2013) and cloud versions of Exchange. At this point, apart from using a different browser, there is no workaround except a registry hack that puts off the day of doom until May 2015.

After doing some digging to understand the timeline of decision making and communication, it seems clear that this is an example of where two very large companies didn’t work together very well to benefit their mutual customers.

Google has been talking about their intention to remove the method for many months and justified the decision in a July 16 blog post as follows:

“Unfortunately, showModalDialog's unique ability to freeze content is now widely regarded as a mis-feature in terms of user experience, code complexity, and security. From a usability perspective, showModalDialog rudely demands that you interact with it by freezing all of your other tabs—even ones from other sites. showModalDialog also requires complex and hard-to-maintain code scattered throughout the codebase. This complexity complicates the behavior of new web features like Mutation Observers, Object.observe, and Promises. It also makes showModalDialog a source of a disproportionate number of bugs, including serious security vulnerabilities. It is for these reasons that we decided to turn off showModalDialog by default in the next version of Chrome.”

Let’s assume that a post by the Chrome development team constitutes a sufficiently formal notice of their decision to remove the method. Again, this post appeared some two months ago, six weeks ahead of the formal release of Chrome version 37 to the “stable channel” on August 26.

Indeed, a previous blog (April 10) announced that the method would be removed in Chrome version 36. As discussed below, other warning signs had appeared in the April timeframe so we can assume that those who are interested in Chrome development have been aware of Google’s intentions for a full five months. Chrome is not the only browser that doesn’t like showModalDialog – the Opera folks also advised that they are considering removing the method from their browser in March and it looks like Firefox might not be far behind.

Although Google’s logic for the deprecation appears to be based on solid reasoning, I have a real problem with the supporting data that they cite. The headline statistic is that only 0.006% of page views used the method and that number has declined in the recent past. Both data points indicate that no great harm would come if the method was removed.

The data was gathered through Google’s “usage counters.”  However, any reasonable examination of the data will consider it to be incomplete because enterprise applications are excluded. For example, if you used the method in an internal application that functions inside a corporate firewall none of those page views are visible to Google. The same is true of any use of OWA or EAC inside a corporate firewall – or indeed using OWA or EAC against Office 365 as I assume that Microsoft doesn’t advise Google of that data.

Google proceeded along their merry way in a state of perfect conviction that they were doing the right thing, which is their perfect right. But the decision screwed over customers and that’s not a great situation to occur. At least Google has provided a registry-level workaround to restore the deprecated method, albeit one that will expire in May 2015.

It has been pointed out that showModalDialog remains in the HTML5 draft specification. However, HTML5 is waiting final approval from the W3C so I’m not sure if that should have been a factor in Google’s decision. In fact, Ian Hickson of Google is the editor of the HTML5 specification and he noted that the method only exists in the draft because it is implemented in browsers and said “I am more than eager to get rid of it.”

Microsoft is also at fault here. I cannot quite understand how no one in Redmond picked up the implication and consequences of Google’s clearly stated intention to deprecate the showModalDialog method. Surely someone reads the Google groups where the decision has been actively debated in detail since April 2014 or thereabouts? After all, on April 13, the clear statement was “Please assume showModalDialog will be removed from Chrome M36 (and likely from other browsers over the coming months/years). “

A further comment (April 23) should have set the alarm bells ringing in Redmond:

“Our system is an enterprise, firewall protected, rich UI internet application that I doubt shows up in your statistics. The system is used by large enterprise clients in eight countries. showModalDialog has been perfect for workflow, and dialogs.  Three months is far too aggressive for a change of this magnitude. Our only option is to block Chrome users @ M36. Sad :-(“

Google will also point to the fact that they actively discussed the change with the Chrome development community and invited people to provide evidence of the method in use and how its removal would affect applications. For instance, on February 26 they said:

“Yes, we carefully consider usage of all applications.  From all that we can measure, the usage across the board (not just on Facebook or cat pages) is insignificantly low.  You may feel that no real research has gone into this but you are simply wrong.

If you have evidence of users of this please let us know.  We sent out these announcements so that the community can let us know about any potential issues so we can react to them.  We need to know about concrete real-world uses in order to make an informed decision.”

Perhaps Microsoft hoped that Google would listen to the pushback from enterprise customers and “do the right thing.” But that didn’t happen and Chrome 37 duly appeared with the method disabled. As expressed in the first comment quoted above, the fear that making such a change with three months of warning would be too aggressive for enterprises is a valid comment.

I think Google made a bad decision by pushing the change through in a short timeframe. Only six weeks elapsed between the July 16 post saying “we’re going to do it” and the change appearing in the stable version, which customers then began to download (automatically in many cases) and deploy into production.

Google might claim that they did not know that the deprecation would have such an impact on applications like OWA and note that they have been clear all along that they were proceeding along a well-flagged course. However, enterprise IT moves slower than individual consumers and the rush to eliminate a poorly-regarded method (in the eyes of Google) was too rushed. It’s also reasonable to ask if Google Groups is the right way to make large software developers like Microsoft and SAP know about upcoming changes.

We’ve been down this path before in some ways. Microsoft and Apple used to be very far apart when it came to working together to ensure a good customer experience when the iOS mail app connected to Exchange via ActiveSync. That gap eventually resulted in horrible problems when buggy client code hijacked calendar appointments or caused out-of-control transaction log growth on servers.

To the credit of both companies, Apple and Microsoft have worked together to improve the client-side code in iOS and to bulletproof the server against rogue client activity. Perhaps Microsoft and Google need to communicate better too?

Follow Tony @12Knocksinna