By now you’re probably well aware that Google deprecated the showModalDialog method in version 37 of their Chrome browser and caused some problems for Outlook Web App (OWA) and Exchange Administration Center (EAC), both of which use the method to display modal screens to collect user input. Well, there’s good news and bad news to report on that topic.
Google remains adamant that the problem is with Microsoft’s use of what Google considers to be an outdated and possibly insecure method. Google will fix problems in Chrome if they believe that they are real bugs – and proved that they would do so when fixing the recent issue that caused OWA to be unable to display calendar appointments.
The good news is that some relief is on the horizon because Microsoft is busily eliminating the use of the offending method. For example, the new OWA options implementation inside Office 365 introduces a different approach to displaying and gathering user options (see below). So far I haven’t encountered any problems using OWA with Chrome version 38, so that’s a good sign – albeit a single-user test.
Even better, on October 8, Microsoft introduced a new method of adding attachments to OWA messages that eliminates the original problem run into by so many people who clicked the paperclip icon to add an attachment only to find nothing happened. (By the way, if you're affected by this problem, take the time to express your displeasure by clicking this link and sharing your views with Google). The "new method to share files" is part of the effort to encourage users to make more use of OneDrive for Business by sending links to documents rather than distributing multiple copies via email. The new dialog (below) allows you to browse OneDrive, your computer, and items stored in Office 365 Groups.
The bad news is that these OWA improvements are only available in Office 365 and there’s no sign of similar progress in either EAC or OWA for on-premises Exchange yet. Don’t hold your breath for an update in Exchange 2013 CU7 because I doubt that any change will happen there, even if its release was delayed last week.
The simple fact is that a lot of work is necessary to make changes in user interfaces, especially when something like a programming method is removed from the mix. Sure, you can argue that Microsoft has made the change already for OWA in Office 365 and that it must surely be straightforward to take that change and implement for on-premises versions. But that ignores two simple facts.
First, Microsoft has total control over the code running in Office 365 and is therefore able to make updates more easily than for on-premises software. Remember that the code that is included in a cumulative update is planned and tested over several months before it is made available to customers. That code has to run in many different environments and rushing a fix to market is a good recipe for flaws. Second, the problem isn’t just with OWA for Exchange 2013 – it affects OWA for Exchange 2010 too (I have seen no reports of similar issues with Exchange 2007). So the work needs to be done for Exchange 2010 SP3 too.
Overall, the OWA/Chrome situation is a bit of a mess and the best advice that I can give those of you who use Chrome with Exchange is to a) implement the GPO fix that makes Chrome work nicely until time runs out in May 2015 and b) wait patiently for Microsoft to fix the underlying OWA and EAC code base (and CRM Dynamics too) and ship it in a future update. If fate allows all will be good and the updated code will be available before 30 April 2015.
I’m still under impressed at how Microsoft managed to drop the ball here and how Google seems so unsympathetic to the real-world needs of enterprise customers. It would be nice if the two companies kissed and made up so that they might work together better for the benefit of their mutual customers. Or something like that.
Follow Tony @12Knocksinna
