Google Chrome ending support for Modal Pop-Ups (Outlook Web App)

[Yeo695]

Not sure if you guys have seen the battle going on between Chrome vs Microsoft vs Angry Users vs Modal, but it now seems that Chrome is ending support for Outlook Web App as it stands, and essentially anything else that runs on Modal Pop-Ups. A few of my schools are in chaos right now because since they use Chrome with OWA and are going crazy because OWAs functionality is limp. I see that Google released a temp GPO to enable Modal Pop ups again and this will be my project of the day, but it will only work till May 2015 (when they completely eliminate support for Modal).

 

Should we expect Microsoft to change OWA to work with Chrome or is this where the two finally part ways?

 

Or should I be preparing the bad news for my faculty for the bad news that they have to go back to IE when using OWA?

 

 

 

Oh and here is a source that sums up the issue pretty well with instructions on how to deploy the GPO to re-enable Model temporarily

http://www.bugdebugzone.com/2014/08/sitecore-modal-pop-ups-are-not-working.html

[JRowley]

I would argue that the glove should be designed to fit the hand, in this case Chrome is the glove. A web browser, that has chosen not to support a specific design used not only by OWA but many web apps, is no longer fit for purpose. This coming from someone who uses Chrome as their main browser both at work and at home, very disappointing.

 

They may well argue that only 0.006% of pages use it, but they are almost all essential pages for enterprise users, they need only make it a GPO controlled config option and default it off. There's no need to remove it completely, better to improve on it and provide an upgrade path for sites depending on it than try and force it out.

[localzuk]

In that sort of timeframe? I doubt Microsoft will turn around a fix to handle browsers which don't have model popups supported.

[Arthur]

Should we expect Microsoft to change OWA to work with Chrome

For Exchange 2010 OWA, probably not. The best thing to do is complain to Microsoft.

 

The rapid release schedules of Chrome and Firefox do have unfortunate results such as this. I don't know, and couldn't publically confirm if I did, what the OWA team will do here. If this isn't working in 2013 CU6 then you are looking at least to CU7 for a fix if one is planned and that's a good 3-4 months away if you look at the rough quarterly release schedule. Office 365 would get a fix much sooner if one was planned given its own rapid update schedule.

 

If OWA is degraded due to a browser change I would suggest you open a case so it can be triaged appropriately. Customer hit-rates are one of the factors that help determine if there is value in exploring code changes.

 

Exchange 2010 was first released when Chrome 3 was out and it enters extended support in January of 2015. If there is a *lot* of code change required to fix what Chrome has essentially broke it may not be possible to do anything at this stage of 2010's life.

 

Source: arstechnica.com/civis/viewtopic.php?p=27535131#p27535131

[ellsandell]

Chrome is not the only one removing it. Firefox will be removing it next year as well:https://developer.mozilla.org/en-US/docs/Web/API/Window.showModalDialog

[Arthur]

As a temporary measure, I did the fix mentioned in the article below (in addition to setting the ShowModalDialog_EffectiveUntil20150430 policy).

 

blog.leederbyshire.com/2014/09/15/a-workaround-for-an-outlook-web-app-problem-with-chrome-and-modal-popup-dialogs/

[SovietRussia]

Im using Chrome and OWA but I dont use Modals Pane view ftw!

[spacebar]

Microsoft will change owa.

[tommej]

Worth noting firefox are also due to drop support for modal popups.

 

edit: really should stop leaving tabs open

[Yeo695]

Hopefully MS will rebuild OWA to work with other browsers by may or else I'm going to start moving over to using enterprise gmail.

[free780]

Are schools using chrome due to still being on xp. Surely a ms web app is going to work best with ie.

[localzuk]

Are schools using chrome due to still being on xp. Surely a ms web app is going to work best with ie.

 

There are many devices, OS's etc... now. We use Chrome here as it is simply a better browser for most websites. IE is only advised for those odd sites that require it now.

[SteveBentley]

I would argue that the glove should be designed to fit the hand, in this case Chrome is the glove. A web browser, that has chosen not to support a specific design used not only by OWA but many web apps, is no longer fit for purpose. This coming from someone who uses Chrome as their main browser both at work and at home, very disappointing.

 

This is why we have standards. If you design your site to require features which are additional to the standards, you can't complain too much when it doesn't don't work in every browser.

 

I would argue that a website that doesn't have at least the basic functionality working properly in a standards compliant browser is what is unfit for purpose.

[synaesthesia]

You'd think. The majority of sites work better with Chrome, it does away with the need for Flash "Player" to be installed and we have actually recommended people use Chrome for OWA instead of IE because yes, it actually works better.

[JRowley]

This is why we have standards. If you design your site to require features which are additional to the standards, you can't complain too much when it doesn't don't work in every browser.

 

I would argue that a website that doesn't have at least the basic functionality working properly in a standards compliant browser is what is unfit for purpose.

 

Microsoft is the one following the standards here, Chrome and Firefox are not:

 

HTML5 Differences from HTML4

 

Please disregard the above.

Edited September 30, 2014 by JRowley

[localzuk]

Microsoft is the one following the standards here, Chrome and Firefox are not:

 

HTML5 Differences from HTML4

 

Not really. The feature in question was an extension to the HTML spec that was introduced by Microsoft, and then adopted by others. As far as I'm aware, the lead editor of the HTML5 spec wants it to be removed (according to the spec editor Ian Hickson).

[JRowley]

Not really. The feature in question was an extension to the HTML spec that was introduced by Microsoft, and then adopted by others. As far as I'm aware, the lead editor of the HTML5 spec wants it to be removed (according to the spec editor Ian Hickson).

 

Yes sorry, disregard that.

 

It was present in the W3C HTML5 standard up until April 2014 when it was deprecated, what strikes me is the speed at which main stream browsers have acted to comply with this particular part of the standard when there are whole chunks of their own proprietary spec active, that has never been standard. Not to mention the fact that almost all HTML5 implementations are based on the 2012 draft and not the April 2014 standard, so I would imagine there is a large amount of changes they should be making immediately if they wish to comply with it.

 

Nevermind one that is used almost exclusively by enterprise users and makes up a fraction of pages.

[localzuk]

The reason they've moved so fast to do it is that the code to implement this feature is bulky and complex, so was a pain to maintain. If they don't have to maintain it, they won't. Not to mention, the implementation in tabbed browsers is, let's just say, odd. The whole idea of it is that when a modal popup is active, the underlying window is "locked" and paused, but the Chrome implementation never fully managed this. Not to mention, the popup could be hidden behind the window, which wasn't a great function.

 

Really, there's no need to use this feature - an in browser overlay is more friendly to devices (modal popups never worked great on tablets and phones).

[Arthur]

Nevermind one that is used almost exclusively by enterprise users and makes up a fraction of pages.

According to Google, less than 0.006% of webpages use the showModalDialog API, although I am not sure how they worked out that figure.

 

blog.chromium.org/2014/07/disabling-showmodaldialog.html

 

showModalDialog was first introduced in Internet Explorer 4 and although it was never formally standardized, over time most other browsers added support for it. It allows applications to show a dialog of HTML content that freezes all other content while showing. showModalDialog is not a commonly used API: based on our usage counters, less than 0.006% of pages use it.

 

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.

 

Although very few sites use showModalDialog, the small minority that do—disproportionately enterprise sites—have come to rely heavily on it.

[JRowley]

Yes, their statistics show a sharp decline from 0.03% February to about 0.006% in August. The data is collected from Chrome's opt in usage statistics, so these figures are purely based on Chrome user's experiences. So this is likely not representative given this effects mostly enterprise users who likely have not opted in. Edited September 30, 2014 by JRowley

[localzuk]

Its a bit of a chicken or egg problem though - they want developers to stop using it and update their software to be a bit more modern (who won't because they have no reason to), but can't remove it until they have.

 

This is somewhat of the nuclear option - force sites to modernise.

[JRowley]

Its a bit of a chicken or egg problem though - they want developers to stop using it and update their software to be a bit more modern (who won't because they have no reason to), but can't remove it until they have.

 

This is somewhat of the nuclear option - force sites to modernise.

 

Admittedly this does force the issue, sites will have to modernise, though I disagree with Chrome's method. Basically if your an enterprise user and you need to use OWA at home, you can no longer use Chrome unless you've had the GPO pushed to the device, this is a ludicrous way of doing it. Firefox have had the foresight to announce it's removal next year which allows for modernisation to take place without immediately effecting users, this is the right way to do it.

 

I fully understand the need to keep up, and obviously this had to be removed at some stage to enforce the standard, but this is a very poor approach to take to the issue especially given they knew it was primarily enterprise users who will be effected. Isn't Google's slogan still "Don't be evil"? It's still in their code of conduct so you would assume so. Seems that doesn't apply to none Google enterprise companies.

Edited September 30, 2014 by JRowley

[SteveBentley]

Modals are also a bloody awful user experience on mobile devices, especially when (mis)used for adverts and you have to play hunt the close button.

[jcookhgs]

How did people eventually deal with this in the end?

[Valyyn]

This is the first I've heard of this issue (gave me a panic when I saw the title before I saw the date).

 

We don't have any issues with OWA (on Exchange 2010) using Chrome here, nor have we done, so I'm a bit confused.

 

Does this only apply to older versions of OWA maybe?

 

Edit:

Just found this:

OWA fix in Exchange Cumulative Updates

Exchange 2013 buttonAs the Exchange Team intends to fully support Google Chrome as a browser for OWA, installing the latest Rollup Update for Exchange 2010 or the latest Cumulative Update for Exchange 2013 also solves the aforementioned issues.

 

Any issues in OWA 2007 and previous caused by the latest version of Chrome will not be addressed as they are out of mainstream support and never officially supported Chrome anyway.

So basically, having a patched 2010 or later server should resolve any issues with it!

Edited July 27, 2015 by Valyyn