Intent to Remove: window.showModalDialog()

[James Robinson]

Use counter data from the stable channel shows that window.showModalDialog() is used on less than 0.006% of page visits.  This feature has an incredibly high cost in terms of code complexity since it requires us to run an event loop on top of an arbitrary javascript stack.  It also complicates the web platform by making task dispatch reentrant and hard to reason about.  To this day, it's unclear how microtask delivery should work with this API.

We marked this API as deprecated 3 months ago:

http://src.chromium.org/viewvc/blink?view=revision&revision=161186

and given the usage numbers I believe we should remove this from Blink now and see how web compatible this ends up being.  Even if we suffer a bit of pain, I think it's worthwhile to remove this functionality.  In particular I do not think we need to tie this removal to any other features like <dialog>.

- James

[Darin Fisher]

L.G.T.M.

[Dominic Cooney]

Removing showModalDialog? :D awesome.

FWIW, in case anyone has any doubt... showModalDialog and <dialog> are completely unrelated (implementation is completely unrelated, <dialog> doesn't require any of this crap with nested event loops, etc.) The only thing they really have in common is the word "dialog".

[Ojan Vafai]

LGTM

[Adam Klein]

I'm not an API OWNER, but this looks so good to me I can't help but say "yes please"!

[Eric Seidel]

Lgtm. 

[Elliott Sprehn]

LGTM! So happy this is getting removed.

[Boris Zbarsky]

On 2/20/14 9:24 PM, James Robinson wrote:
> and given the usage numbers I believe we should remove this from Blink
> now and see how web compatible this ends up being. Even if we suffer a
> bit of pain, I think it's worthwhile to remove this functionality.

Thank you for being willing to take this on! If you do manage to remove
this successfully, I'm fairly certain that Gecko will follow suit, for
all the reasons you list.

-Boris

[Alex Russell]

LGTM!!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jochen Eisinger]

I support removing showModalDialog LGTM

Having looked at this before, there appear to be some customers of showModalDialog. AFAIK hotmail uses it e.g. for attaching files. It appears to be used a lot in software written around SAP. So while the usage might be indeed very low, I would expect this change to not go unnoticed.

best

-jochen

[Pavel Feldman]

What about alert messages and the debugger? They are no different from the modal dialog - they run nested event loops on arbitrary JS stack and make same web calls reentrant. What part of the complexity is going away with the showModalDialog?

Regards
Pavel

[Darin Fisher]

showModalDialog allows one WebView to schedule work, whereas with alert/confirm/prompt/print, no WebView may schedule work.

[Pavel Feldman]

What about debugger? Mutating DOM and evaluating setTimeout from the console while on a breakpoint is a generic use case for us.

[Jochen Eisinger]

The debugger at least doesn't let the page decide to start a nested message loop.

Also, it doesn't require the entire browser to stop doing anything else (note that this is actually broken in chrome - the dialog is currently not modal).

Last but not least, we could do something similar on the main thread to what I recently added for workers: add a separate message queue for debugger tasks, then we don't need a nested message loop anymore.

Best
Jochen

[Pavel Feldman]

Alright. I just wanted to bring attention to other use cases that require similar complexity. Given they are on radar, this intent looks good.

Jochen, I'll follow up with you on a separate message queue. WebView might be not as simple as worker there.

Regards
Pavel

[Simon Pieters]

On Fri, 21 Feb 2014 03:24:59 +0100, James Robinson <jam...@chromium.org>
wrote:

I asked Mike Taylor to grep for 'showModalDialog' in his data set from
64618 front pages from Alexa's top 1m URLs. His data set includes external
scripts. See https://github.com/miketaylr/fetcher for details.

The result is available at https://gist.github.com/miketaylr/9190295

The string appeared in 608 pages, so 0.94%.
https://gist.github.com/zcorpan/9204753

Some occurrences are irrelevant, like commented out code, or defining
their own showModalDialog. Some use it as part of browser detection. Some
check for its existence before using it, some (most maybe) just use it
without checking.

--
Simon Pieters
Opera Software

[splen...@gmail.com]

I'm surprised nobody's really spoken up about the negative effects of this change.  I'll try not to make this too rant-y but...

I'm kind of amused at the fact that everyone's quick to say L.G.T.M. without giving any consideration to the implications of a change like this.  It seems like this is being removed only because its 'hard to do' and 'nobody uses it'.  What real good reason do you have to remove it?  Last I checked, its in the HTML5 spec.  Maybe I'm crazy and I'm missing something.

What about the people who do use it?  Did you guys every think about web application usage?  Just to clarify, I'm talking business applications here.  Of course you'll only see a small percentage because most people are looking at cat pics or wasting their lives on facebook.  I feel like no real research has gone into examining the overall effects of this.  Somebody did a web search and said that's good enough.  Absolutely ludicrous.

After the scrollbar issue in v.32, all the odd-ball issues using gmail, and this issue, I really have to wonder what's next on your agenda to break/remove?

... end of rant ...

I enjoy using the browser you guys helped create.  In fact, it's my main browser.... But I'm really starting to wonder whether I should continue to use it or not.

[Eric Seidel]

If you are aware of high-usage sites which we should avoid breaking,
that would be a very useful addition to the discussion.

As mentioned in the thread, showModalDialog has a very large
complexity cost to Chrome (impeding the quality of all the rest of the
pieces you like about Chrome) while having extremely low usage.

In general we're interested in trying to support the current and
future web as well as possible, while slowly letting go of the parts
of the web which web authors are no longer using. If web authors (or
popular sites) are still using showModalDialog, we can't let go of it
yet, but that just means that other improvements in Chrome will have
to wait until we can.

[James Robinson]

On Tue, Feb 25, 2014 at 3:53 PM, <splen...@gmail.com> wrote:

I'm surprised nobody's really spoken up about the negative effects of this change.  I'll try not to make this too rant-y but...

I'm kind of amused at the fact that everyone's quick to say L.G.T.M. without giving any consideration to the implications of a change like this.  It seems like this is being removed only because its 'hard to do' and 'nobody uses it'.  What real good reason do you have to remove it?  Last I checked, its in the HTML5 spec.  Maybe I'm crazy and I'm missing something.

These issues have been carefully considered and discussed with the editor of the HTML spec and other members of the community.  Everyone is in agreement that this API is pretty much the worst thing imaginable in terms of user experience and complexity of the platform.

 

What about the people who do use it?  Did you guys every think about web application usage?  Just to clarify, I'm talking business applications here.  Of course you'll only see a small percentage because most people are looking at cat pics or wasting their lives on facebook.  I feel like no real research has gone into examining the overall effects of this.  Somebody did a web search and said that's good enough.  Absolutely ludicrous.

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.

- James

[Jake]

Heh. I say <blink> was by far the worst thing imaginable. :)

Just a suggestion, but perhaps it would help if y'all provided guidance on replacements/workarounds for those impacted by the change?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ian Hickson]

On Tue, 25 Feb 2014, splen...@gmail.com wrote:
>
> I'm kind of amused at the fact that everyone's quick to say L.G.T.M.
> without giving any consideration to the implications of a change like
> this. It seems like this is being removed only because its 'hard to do'
> and 'nobody uses it'. What real good reason do you have to remove it?

This API is a really poorly designed API. It causes a popup to show, which
is extremely awkward on e.g. mobile platforms; it causes the event loop to
nest, which is extremely problematic for multiple reasons, including
having serious security implications; it makes modal UI dependent on
network traffic, which is very undesireable; exactly how it works in a
multi-process multi-tab UI is highly unintuitive (which windows should it
disable while it's up?); it is the only API that can cause JavaScript
execution to appear in the stack below core functionality like pumping OS
events; and, the straw that broke the camel's back for the Chrome team, it
has huge implications for how complicated implementing mutation observers
will be.

This API single-handedly makes completely unrelated parts of the platform
significantly more complicated to implement, which leads to more bugs,
which makes everything worse for everyone.

And to top it all off, it's not even a particuarly good UI. We have much
better solutions in the works, too, like <dialog>.

> Last I checked, its in the HTML5 spec.

It's only in the HTML standard because browsers implement it. As the
editor of the HTML spec, I am more than eager to get rid of it.

Originally, it was a non-standard single-vendor extension.

> What about the people who do use it?

The current usage is the only reason other browsers haven't already
dropped support for this API. (Indeed, the current usage is the only
reason that most current browsers ended up supporting it at all, and
that's the only reason it's in the HTML spec.)

On Wed, 26 Feb 2014, Jake wrote:
>
> Heh. I say <blink> was by far the worst thing imaginable. :)

<blink> is implemented in one line of CSS, and the relevant CSS is
effectively just a short-hand for triggering some animation code, which is
needed anyway for CSS animations. It's trivial in comparison.

> Just a suggestion, but perhaps it would help if y'all provided guidance
> on replacements/workarounds for those impacted by the change?

showModalDialog() shouldn't be used regardless of whether it's
implemented, because it's a horrible UI (it causes part of the browser to
be disabled while a Web page loads, etc). The workaround is to display
inline UI on the page. Medium-term, <dialog> is a better alternative.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[tom.ch...@gmail.com]

"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."

Well, that's us, for instance. Part of our web based application is content creation, using CKEditor on part of the page. Our users are effectively creating HTML pages, and sometimes need more room than is available in the region of the page CK is restricted to. For this reason we have a button that reopens CKEditor in a detached window that can use the whole screen. This has to be modal so changes can't be made in the smaller version at the same time.
We use showModalDialog() for this, because it conveniently pauses execution in the opener until the window closes, at which point it returns (via window.returnValue) the new content and we can just update.

The 'fix' for loosing showModalDialog() would be to display a full-page overlay, right ? This is not as useful as a detached window, because I have to resize the browser (and all its tabs) rather than just the window of interest.

It seems to me that the only real complaint is "how it works in a multi-process multi-tab UI is highly unintuitive", but this is because Chrome currently gets it wrong (by allowing the new window to hide behind the opener and not visually disabling it, only preventing clicks) , where as FireFox does the right thing (IMHO) and makes the opener window disabled and locked to behind the popup.

[Jochen Eisinger]

On Fri, Feb 28, 2014 at 12:27 PM, <tom.ch...@gmail.com> wrote:

"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."

Well, that's us, for instance. Part of our web based application is content creation, using CKEditor on part of the page. Our users are effectively creating HTML pages, and sometimes need more room than is available in the region of the page CK is restricted to. For this reason we have a button that reopens CKEditor in a detached window that can use the whole screen. This has to be modal so changes can't be made in the smaller version at the same time.
We use showModalDialog() for this, because it conveniently pauses execution in the opener until the window closes, at which point it returns (via window.returnValue) the new content and we can just update.

Note that one reason we want to get rid of showModalDialog is that in chrome, it does not really pause execution. It's still possible trigger JS execution in the opener's context.

The 'fix' for loosing showModalDialog() would be to display a full-page overlay, right ? This is not as useful as a detached window, because I have to resize the browser (and all its tabs) rather than just the window of interest.

You can just use window.open() to create a new window. You'd use postMessage to communicate with the popup, or, if it's from the same origin, you can even invoke js functions in both directions.

Of course you lose the modality aspect, but as you note below, that never really worked in chrome...

[tom.ch...@gmail.com]

"Of course you lose the modality aspect, but as you note below, that never really worked in chrome..."

Yup. Which is why we use it, and we've always considered it a bug in Chrome that would get fixed, rather than Chrome deciding it could pick and choose what parts of HTML5 to support.

Tom

[PhistucK]

I think a polyfill for (an even less buggy version of) showModalDialog would be pretty trivial to implement (like Jochen mentions, window.open, window.onmessage and opener.postMessage). While the JavaScript execution would not be halted (which does not change the current state in Chrome), you can make use of this CSS -

*

{

 pointer-events: none !important;

}

To make sure no (mouse or touch) events are triggered (as part of the polyfil).

Then just include the polyfill in both of the ends of that interaction and you should be done.

The JavaScript execution bug will probably never be fixed anyway, so there is no reason to ever count on it.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jake]

@Ian,

My <blink> comment was a poor attempt at humor. Back in the day that tag annoyed me to no end :)

[tapasvi...@gmail.com]

The showModalDialog method along with alert and prompt are one of the few true blocking calls. Implementing a polyfill is next to IMPOSSIBLE without crashing the browser.

Here is an example of why: 

var returnValue = window.showModalDialog(<someuri>);

Now since this is a blocking call window.showModalDialog will not return until the child window (<someurl>) calls a window.close on itself.

There is no practical way to simulate a blocking call in javascript to write out a backward compatible javascript polyfill.

Here is a practical example of a use case that is in production on a multi million dollar product.

A user is clicking on a feature that requires some setup before it continues to render the page.

var featureConfig = window.showModalDialog(<someUrl>); //someUrl might be a wizard walking the user through the complex flow to finally submit the results back to the parent window as the result object.

Since the call was blocking the code is scripted to assume a synchronous nature of the method call..

I also have a concern regarding the source of the data in making a swift decision. Most of these method calls tend to happen on pages that require a logged in context. Hence this will not show in a grep search of the top public websites. The amount of work involved in converting a previously synchronous flow (by leveraging the blocking nature of window.showModal) into asynchronous one is not trivial. 

This will cause significant issues for some applications and may require more than 3 months of notice to fix.

[Adam Barth]

On Mon Mar 03 2014 at 2:21:47 AM, <tapasvi...@gmail.com> wrote:

The showModalDialog method along with alert and prompt are one of the few true blocking calls. Implementing a polyfill is next to IMPOSSIBLE without crashing the browser.

Here is an example of why: 

var returnValue = window.showModalDialog(<someuri>);

Now since this is a blocking call window.showModalDialog will not return until the child window (<someurl>) calls a window.close on itself.

There is no practical way to simulate a blocking call in javascript to write out a backward compatible javascript polyfill.

Yes, that's one of the reasons we've removed the feature.  It adds constraints to the engine that exist in no other API.

If you're using showModalDialog, you'll probably need to restructure your code a bit to be asynchronous.  For example, you might consider using Promises:

var result = window.showMyDialog(...);

...

result.then(function(returnValue) {

  ...

});

Here is a practical example of a use case that is in production on a multi million dollar product.

A user is clicking on a feature that requires some setup before it continues to render the page.

var featureConfig = window.showModalDialog(<someUrl>); //someUrl might be a wizard walking the user through the complex flow to finally submit the results back to the parent window as the result object.

Since the call was blocking the code is scripted to assume a synchronous nature of the method call..

To address that use case, you'll probably want to create a full-page element that dims the existing content of the page and prevents the user from interacting with it.  You can position your custom dialog on top of that element to let the user interact with the dialog.  That's how most web apps handle this use case.

I also have a concern regarding the source of the data in making a swift decision. Most of these method calls tend to happen on pages that require a logged in context. Hence this will not show in a grep search of the top public websites. The amount of work involved in converting a previously synchronous flow (by leveraging the blocking nature of window.showModal) into asynchronous one is not trivial.

UseCounters measure both logged in and not logged in content in proportion to how often that content is viewed by users.  The fact is that showModalDialog is used extremely rarely.

This will cause significant issues for some applications and may require more than 3 months of notice to fix.

I appreciate that it's going to be some amount of work for you to retrofit your web site to avoid showModalDialog.  We understand that's a cost of removing this feature.  On balance, however, we feel that the benefits of removing the feature outweigh the costs.

Adam

[Tom Chiverton]

It's not a benefit to the developers who have to rewrite their code, or the companies that have to pay for that, or replace a whole site because the developer isn't around any more.

It's not a benefit to users, who have a site break.

So it's only for Chrome developers benefit ?

--
Tom

[Adam Barth]

You're right that the costs largely accrue to people who maintain web sites that use showModalDialog.  The benefits largely accrue to users, who gain a browser with fewer security vulnerabilities and that can support richer user experiences without the constraints imposed by this API.

The UseCounter data tells us that the former group is quite small, which is why it's an important input into this decision.  Of course, small does not mean "empty," and it's easy for folks like yourself to be vocal on mailing lists.  That's why we use usage data to make these sorts of decisions.

Adam

[Dominic Mazzoni]

On Mon, Mar 3, 2014 at 10:00 AM, Adam Barth <aba...@google.com> wrote:

var featureConfig = window.showModalDialog(<someUrl>); //someUrl might be a wizard walking the user through the complex flow to finally submit the results back to the parent window as the result object.

Since the call was blocking the code is scripted to assume a synchronous nature of the method call..

To address that use case, you'll probably want to create a full-page element that dims the existing content of the page and prevents the user from interacting with it.  You can position your custom dialog on top of that element to let the user interact with the dialog.  That's how most web apps handle this use case.

In my experience, web developers usually get this wrong - for example by still allowing elements behind the dialog to receive focus.

I'm totally supportive of removing showModalDialog, but I also think this might be a good excuse to try to figure out how we can ship the dialog element and/or inert attribute soon.

The dialog element is fully implemented, but the Intent to Ship discussion fizzled. Could we pick it up and try to reach a consensus on the next step there? Alternatively, I know Matt was thinking of implementing "inert" because it might still help developers, while being simpler and a lot less controversial. Would there be more support for implementing and shipping "inert" soon?

[Tapasvi Moturu]

Adam,

Don't get me wrong, I am totally in favor of removing this from the browser codebase as it simplifies a lot of things and truly reflects the asynchronous nature of javascript by removing the blocking methods.

At the same time, we do also want to point out that despite making progress on the reducing/removing the use of blocking calls, three months is not enough for us. Out entire app (an older version) that has more that half a million active users will be impacted pretty significantly as we will not be able to turnaround in time. We have a fairly large codebase that uses this feature a lot.

At this point, is it a given that this will be removed in the next release of chrome or do we have a chance to postpone the removal of this feature by one more release ?

Please advise

Tapasvi Moturu

 

[Adam Barth]

On Mon Mar 03 2014 at 12:56:08 PM, Tapasvi Moturu <tapasvi...@gmail.com> wrote:

Adam,

Don't get me wrong, I am totally in favor of removing this from the browser codebase as it simplifies a lot of things and truly reflects the asynchronous nature of javascript by removing the blocking methods.

At the same time, we do also want to point out that despite making progress on the reducing/removing the use of blocking calls, three months is not enough for us. Out entire app (an older version) that has more that half a million active users will be impacted pretty significantly as we will not be able to turnaround in time. We have a fairly large codebase that uses this feature a lot.

At this point, is it a given that this will be removed in the next release of chrome or do we have a chance to postpone the removal of this feature by one more release ?

The feature will still be present in the next release of Chrome (M34).  The feature is unlikely to be present in the release after that (M35).

Adam

[yog...@gmail.com]

Hi Adam,

I'm a colleague of Tapasvi's.  I read somewhere at the top of the thread that you were open to information on actual product usage to inform your decision, and I hope that you reconsider the timing for this change.

Our product is a mission critical application for small businesses.  We have over 1 million active small business users who depend on us on a daily basis.  We rely heavily on showModalDialog - we have hundreds of instances of these throughout the code.  These dialogs are used in core workflows and implementing large parts of the functionality of the application - removing this API will render the product unusable.  3 months is simply not enough time for us to react to this change.  Even implementing workaround solutions will take considerably longer so I'm wondering what options there are to delay releasing this change - given the nature of our product, we will need considerably more time to implement and regress workarounds.  I imagine there are other products (perhaps enterprise solutions) that will also break as a result of this change. As with us, raw usage numbers may not necessarily reflect the criticality of this change to some of these products, and certainly, the impact is very big.

Please let me know your thoughts.

--Yogesh