Intent to Remove: window.showModalDialog()

12,951 views
Skip to first unread message

James Robinson

unread,
Feb 20, 2014, 9:24:59 PM2/20/14
to blink-dev
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:

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

unread,
Feb 20, 2014, 9:30:43 PM2/20/14
to James Robinson, blink-dev

L.G.T.M.

Dominic Cooney

unread,
Feb 20, 2014, 9:31:46 PM2/20/14
to Darin Fisher, James Robinson, blink-dev
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

unread,
Feb 20, 2014, 9:56:37 PM2/20/14
to Dominic Cooney, Darin Fisher, James Robinson, blink-dev
LGTM

Adam Klein

unread,
Feb 20, 2014, 10:10:53 PM2/20/14
to James Robinson, blink-dev
I'm not an API OWNER, but this looks so good to me I can't help but say "yes please"!

Eric Seidel

unread,
Feb 20, 2014, 10:25:36 PM2/20/14
to Adam Klein, James Robinson, blink-dev
Lgtm. 

Elliott Sprehn

unread,
Feb 20, 2014, 10:27:12 PM2/20/14
to Eric Seidel, Adam Klein, James Robinson, blink-dev
LGTM! So happy this is getting removed.

Boris Zbarsky

unread,
Feb 21, 2014, 12:14:11 AM2/21/14
to James Robinson, blink-dev
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

unread,
Feb 21, 2014, 12:51:17 AM2/21/14
to Darin Fisher, blink-dev, James Robinson

LGTM!!

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

Jochen Eisinger

unread,
Feb 21, 2014, 1:00:15 AM2/21/14
to Alex Russell, Darin Fisher, blink-dev, James Robinson
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

unread,
Feb 21, 2014, 1:07:00 AM2/21/14
to Jochen Eisinger, jam...@chromium.org, blink-dev, Alex Russell, Darin Fisher

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

unread,
Feb 21, 2014, 1:14:00 AM2/21/14
to Pavel Feldman, blink-dev, James Robinson, Alex Russell, Jochen Eisinger

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

Pavel Feldman

unread,
Feb 21, 2014, 1:16:42 AM2/21/14
to Darin Fisher, jam...@chromium.org, blink-dev, Alex Russell, Jochen Eisinger

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

Jochen Eisinger

unread,
Feb 21, 2014, 1:27:52 AM2/21/14
to Pavel Feldman, blink-dev, James Robinson, Alex Russell, Darin Fisher

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

unread,
Feb 21, 2014, 1:43:25 AM2/21/14
to Jochen Eisinger, jam...@chromium.org, blink-dev, Alex Russell, Darin Fisher

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

unread,
Feb 25, 2014, 3:26:26 AM2/25/14
to blink-dev, James Robinson, mi...@mozilla.com
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

unread,
Feb 25, 2014, 6:53:36 PM2/25/14
to blin...@chromium.org
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

unread,
Feb 25, 2014, 7:02:21 PM2/25/14
to splen...@gmail.com, blink-dev
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

unread,
Feb 25, 2014, 7:06:06 PM2/25/14
to splen...@gmail.com, blink-dev
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

unread,
Feb 26, 2014, 4:15:16 AM2/26/14
to blink-dev
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

unread,
Feb 26, 2014, 11:05:49 AM2/26/14
to splen...@gmail.com, Jake, blink-dev
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

unread,
Feb 28, 2014, 6:27:20 AM2/28/14
to blin...@chromium.org
"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

unread,
Feb 28, 2014, 6:58:36 AM2/28/14
to tom.ch...@gmail.com, blink-dev
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

unread,
Feb 28, 2014, 7:28:12 AM2/28/14
to blin...@chromium.org
"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

unread,
Feb 28, 2014, 7:56:58 AM2/28/14
to tom.ch...@gmail.com, blink-dev
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

unread,
Mar 1, 2014, 4:37:58 PM3/1/14
to blink-dev
@Ian,

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

tapasvi...@gmail.com

unread,
Mar 3, 2014, 5:21:44 AM3/3/14
to blin...@chromium.org, tom.ch...@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

unread,
Mar 3, 2014, 1:00:19 PM3/3/14
to tapasvi...@gmail.com, blin...@chromium.org, tom.ch...@gmail.com
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

unread,
Mar 3, 2014, 1:03:46 PM3/3/14
to Adam Barth, tapasvi...@gmail.com, blin...@chromium.org
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

unread,
Mar 3, 2014, 1:45:06 PM3/3/14
to Tom Chiverton, tapasvi...@gmail.com, blin...@chromium.org
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

unread,
Mar 3, 2014, 2:13:01 PM3/3/14
to Adam Barth, tapasvi...@gmail.com, blink-dev, tom.ch...@gmail.com
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

unread,
Mar 3, 2014, 3:55:47 PM3/3/14
to Adam Barth, Tom Chiverton, blin...@chromium.org
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

unread,
Mar 3, 2014, 4:04:53 PM3/3/14
to tapasvi...@gmail.com, tom.ch...@gmail.com, blin...@chromium.org
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

unread,
Mar 3, 2014, 5:53:16 PM3/3/14
to blin...@chromium.org, tapasvi...@gmail.com, tom.ch...@gmail.com, aba...@google.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

Adam Barth

unread,
Mar 3, 2014, 5:55:02 PM3/3/14
to yog...@gmail.com, blin...@chromium.org, tapasvi...@gmail.com, tom.ch...@gmail.com
On Mon Mar 03 2014 at 2:53:17 PM, <yog...@gmail.com> wrote:
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.

How much time would be sufficient?

Adam

yog...@gmail.com

unread,
Mar 3, 2014, 9:23:07 PM3/3/14
to blin...@chromium.org, yog...@gmail.com, tapasvi...@gmail.com, tom.ch...@gmail.com, aba...@google.com
Adam,

We're working on gathering same data to help answer that.

Eric Seidel

unread,
Mar 3, 2014, 9:26:40 PM3/3/14
to yog...@gmail.com, blink-dev, tapasvi...@gmail.com, tom.ch...@gmail.com, Adam Barth
For context, M35 is schedule for branching on March 31st:
http://www.chromium.org/developers/calendar

Releases have historically shipped to stable about 12 weeks after branching:
http://en.wikipedia.org/wiki/Google_Chrome#Release_history

yog...@gmail.com

unread,
Mar 6, 2014, 8:02:15 PM3/6/14
to blin...@chromium.org, yog...@gmail.com, tapasvi...@gmail.com, tom.ch...@gmail.com, Adam Barth
Adam/Eric,

We've done some more detailed assessment and tried a couple of workaround options.  As you know, the challenge is in replicating the blocking nature of the showModalDialog call while still solving for the use cases.  The short answer is that we will need through October 31st to deal with this change.  Please read on for the rationale.

Within our code, we pause execution in the parent, wait for the return value from this call, and use that return value to continue execution in the caller.  Sometimes, the hierarchy takes us multiple levels deep from dialog to dialog.  There are arguments being passed back and forth across the dialogs, and as I mentioned, we have very core business/domain workflows implemented in this way (so the dialogs are pretty heavyweight).  While we'd like to move away from using these dialogs, this is a very large undertaking for us.  It requires us to touch every instance of the call (dialog + caller) to enable the same behavior, making changes up and down that entire call stack.  There are 600+ instances that we need to track down and modify without regression.

Given this complexity and scope, we will need all hands on deck to implement these workarounds, and we're estimating that it'll take 8 months for us to do it.  Obviously, this is pretty disruptive to the business and it deprioritizes other work we have in flight in order to focus on this effort.

Please let me know your thoughts.

--Yogesh

Drew Wilson

unread,
Mar 10, 2014, 11:47:48 AM3/10/14
to Adam Barth, sas...@chromium.org, tapasvi...@gmail.com, blink-dev, tom.ch...@gmail.com
On Mon, Mar 3, 2014 at 7:00 PM, Adam Barth <aba...@google.com> wrote:

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.

One note - the assumption behind UseCounters is that the population with UseCounter reporting enabled is roughly equivalent (in terms of frequency of usage of APIs) to the population that has UseCounter reporting disabled. If there's an API that is primarily used by enterprises (which have a much higher percentage of clients with usage reporting disabled), then that would skew our numbers.

So, we should be cautious about treating statistical projections based on UseCounters as "facts" - they are projections based on the best data we have available, but data which is known to be flawed. 

I would echo Jochen's concern that SAP applications make use of this API, and this use by enterprise apps is likely to be under-reported by UseCounters. I understand the motivation to remove this API (and it's a bit of a fait accompli at this point), but ideally we'd have some time to do outreach with our enterprise customers/ISVs, and I fear that 8-12 weeks will be insufficient.
 

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.

I wouldn't say that the cost is outweighed by the benefit, just that ideally we would give people more time to make this transition, especially since the first time many of them will hear about this is when this change hits the Chrome beta channel.

Adam Barth

unread,
Mar 10, 2014, 11:50:31 AM3/10/14
to atwi...@chromium.org, sas...@chromium.org, tapasvi...@gmail.com, blin...@chromium.org, tom.ch...@gmail.com
On Mon Mar 10 2014 at 8:47:49 AM, Drew Wilson <atwi...@chromium.org> wrote:
On Mon, Mar 3, 2014 at 7:00 PM, Adam Barth <aba...@google.com> wrote:

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.

One note - the assumption behind UseCounters is that the population with UseCounter reporting enabled is roughly equivalent (in terms of frequency of usage of APIs) to the population that has UseCounter reporting disabled. If there's an API that is primarily used by enterprises (which have a much higher percentage of clients with usage reporting disabled), then that would skew our numbers.

So, we should be cautious about treating statistical projections based on UseCounters as "facts" - they are projections based on the best data we have available, but data which is known to be flawed. 

I would echo Jochen's concern that SAP applications make use of this API, and this use by enterprise apps is likely to be under-reported by UseCounters. I understand the motivation to remove this API (and it's a bit of a fait accompli at this point), but ideally we'd have some time to do outreach with our enterprise customers/ISVs, and I fear that 8-12 weeks will be insufficient.
 

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.

I wouldn't say that the cost is outweighed by the benefit, just that ideally we would give people more time to make this transition, especially since the first time many of them will hear about this is when this change hits the Chrome beta channel.

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Adam Barth

unread,
Mar 10, 2014, 12:07:51 PM3/10/14
to yog...@gmail.com, blin...@chromium.org, tapasvi...@gmail.com, tom.ch...@gmail.com
On Thu Mar 06 2014 at 5:02:16 PM, <yog...@gmail.com> wrote:
Adam/Eric,

We've done some more detailed assessment and tried a couple of workaround options.  As you know, the challenge is in replicating the blocking nature of the showModalDialog call while still solving for the use cases.  The short answer is that we will need through October 31st to deal with this change.  Please read on for the rationale.

Within our code, we pause execution in the parent, wait for the return value from this call, and use that return value to continue execution in the caller.  Sometimes, the hierarchy takes us multiple levels deep from dialog to dialog.  There are arguments being passed back and forth across the dialogs, and as I mentioned, we have very core business/domain workflows implemented in this way (so the dialogs are pretty heavyweight).  While we'd like to move away from using these dialogs, this is a very large undertaking for us.  It requires us to touch every instance of the call (dialog + caller) to enable the same behavior, making changes up and down that entire call stack.  There are 600+ instances that we need to track down and modify without regression.

Given this complexity and scope, we will need all hands on deck to implement these workarounds, and we're estimating that it'll take 8 months for us to do it.  Obviously, this is pretty disruptive to the business and it deprioritizes other work we have in flight in order to focus on this effort.

Please let me know your thoughts.

Yogesh,

I sympathize with your situation.  No one wants to distract their development team for re-writing large portions of their app because an API they depend upon has been removed.

Unfortunately, in the period of time this thread has been going on, we've received a report of yet another security vulnerability with showModalDialog (http://crbug.com/350535 for those of you who can access security bugs or those of you reading this email in the future).  On the one hand, that's not particularly surprising because we've seen a long series of vulnerabilities in showModalDialog over the years, but, on the other hand, it makes the costs of keeping showModalDialog very concrete.

What makes removing features like showModalDialog difficult is that the costs are large but borne by relatively few people but the benefits are small but enjoyed by a relatively large number of people.  It can be difficult to judge whether the costs or benefits have more weigh.  Ultimately, that's a judgement call, and our judgement is that the benefits outweigh the costs.

I understand that you're on the cost side of this equation, but  I would ask you to understand that there are people on the benefit side of this equation too.

Adam

Drew Wilson

unread,
Mar 11, 2014, 5:35:00 AM3/11/14
to Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
On Mon, Mar 10, 2014 at 4:50 PM, Adam Barth <aba...@google.com> wrote:

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Agreed, 3 months is a reasonable timeframe. What does it mean for an API to be deprecated - do we do any developer outreach letting people know that the API is going away, or is the deprecation warning printed to the JS console the only notification we provide?

I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday. Undoubtedly that's our own fault for not making sure we keep ourselves informed about developments in Blink, but I suspect that many other developers were unaware that this was coming. Did we see use of this API decrease over the last 3 months? If so, then that would be a signal that our deprecation process is working as intended, and at some point we just need to pull the plug. My concern is that if we didn't see the use decline, that means that developers were generally unaware of the deprecation.

Tapasvi Moturu

unread,
Mar 11, 2014, 11:05:34 AM3/11/14
to Drew Wilson, blin...@chromium.org, Tom Chiverton, sas...@chromium.org, Adam Barth

+1

Adam Barth

unread,
Mar 11, 2014, 11:14:30 AM3/11/14
to atwi...@chromium.org, sas...@chromium.org, tapasvi...@gmail.com, blin...@chromium.org, tom.ch...@gmail.com
On Tue Mar 11 2014 at 2:35:00 AM, Drew Wilson <atwi...@chromium.org> wrote:
On Mon, Mar 10, 2014 at 4:50 PM, Adam Barth <aba...@google.com> wrote:

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Agreed, 3 months is a reasonable timeframe. What does it mean for an API to be deprecated - do we do any developer outreach letting people know that the API is going away, or is the deprecation warning printed to the JS console the only notification we provide?

Deprecation messages are printed to the console and announced on this mailing list.  Some deprecations are announced on the Chromium blog, but I don't see that this one was.  We could certainly do a better job publicizing when we deprecate a feature.
 
I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday.
 
In the near term, the easiest way to learn about deprecations is to search this mailing list for messages with the subject "intent to deprecate" or "intent to remove".

Undoubtedly that's our own fault for not making sure we keep ourselves informed about developments in Blink, but I suspect that many other developers were unaware that this was coming. Did we see use of this API decrease over the last 3 months?

Yes, the usage as been declining:


That data only goes back a month, but even in that time, the usage has fallen significantly.

If so, then that would be a signal that our deprecation process is working as intended, and at some point we just need to pull the plug. My concern is that if we didn't see the use decline, that means that developers were generally unaware of the deprecation.

I suspect that people don't take deprecation seriously because historically we haven't actually followed through and removed features that we've deprecated.  For example, there's another thread on this mailing list currently about a deprecated feature that's used by 24% of pages.  It's very unlikely we'd be able to remove a feature that's used by 24% of pages.  Hopefully we'll raise the signal-to-noise ratio of these messages.

One of our goals for 2014 is to find ways to deprecate and remove large platform features with minimal breakage [1].  We're still learning how to do that effectively.  I really appreciate your feedback about how we can do better in the future.  Hopefully over time we'll iron out the rough spots in this process.

Adam

Dirk Pranke

unread,
Mar 11, 2014, 12:13:26 PM3/11/14
to Drew Wilson, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
On Tue, Mar 11, 2014 at 2:35 AM, Drew Wilson <atwi...@chromium.org> wrote:



On Mon, Mar 10, 2014 at 4:50 PM, Adam Barth <aba...@google.com> wrote:

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Agreed, 3 months is a reasonable timeframe.

I'm not sure that 3 months is a reasonable timeframe, not for changes that might require a substantial reworking of an application (e.g., the showModalDialog case). Having spent plenty of time on the other side of the fence, writing apps in enterprises, 3 months is very aggressive. 

I would be very leery of adopting that number as a baseline; I think we probably need a range of numbers depending on what the impact of the feature going away might be is and how hard it is to migrate to a new solution. Obviously, in some cases the breakage might be cosmetic and the fix a search and replace to remove a prefix; on the other end of the spectrum (again, showModalDialog), apps might lose basic functionality and fixing it might be a substantial amount of work.

-- Dirk

Boris Zbarsky

unread,
Mar 11, 2014, 2:35:51 PM3/11/14
to blink-dev
On 3/11/14 11:14 AM, Adam Barth wrote:
> For example, there's another thread on this
> mailing list currently about a deprecated feature that's used by 24% of
> pages. It's very unlikely we'd be able to remove a feature that's used
> by 24% of pages.

For what it's worth, that 24% number is grossly over-inflated by jQuery
commonly "using" that feature for purposes of the use counter. But in
practice, whenever jQuery hits that codepath its behavior is the same as
it would be if the feature were not supported. See
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25002#c2 for the relevant
jQuery code and a proposal for a use counter that might provide more
relevant data here.

-Boris

Tom Chiverton

unread,
Mar 12, 2014, 5:15:10 AM3/12/14
to Dirk Pranke, Drew Wilson, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev
"apps might lose basic functionality and fixing it might be a substantial amount of work."

This. And a much better job of giving a heads up with a lead time that varies - 3 months for removing a CSS prefix is reasonable, but it's far too short for dropping support for part of the HTML5 spec.
That's even assuming, as above, that you don't have a massive selection bias in the usage number...
--
Tom

Drew Wilson

unread,
Mar 12, 2014, 5:27:04 AM3/12/14
to Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
On Tue, Mar 11, 2014 at 4:14 PM, Adam Barth <aba...@google.com> wrote:
On Tue Mar 11 2014 at 2:35:00 AM, Drew Wilson <atwi...@chromium.org> wrote:
On Mon, Mar 10, 2014 at 4:50 PM, Adam Barth <aba...@google.com> wrote:

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Agreed, 3 months is a reasonable timeframe. What does it mean for an API to be deprecated - do we do any developer outreach letting people know that the API is going away, or is the deprecation warning printed to the JS console the only notification we provide?

Deprecation messages are printed to the console and announced on this mailing list.  Some deprecations are announced on the Chromium blog, but I don't see that this one was.  We could certainly do a better job publicizing when we deprecate a feature.
 
I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday.
 
In the near term, the easiest way to learn about deprecations is to search this mailing list for messages with the subject "intent to deprecate" or "intent to remove".

Jochen pointed this out also, and I've now set up the appropriate filters to make sure I'm able to track upcoming changes like this :)
 

Undoubtedly that's our own fault for not making sure we keep ourselves informed about developments in Blink, but I suspect that many other developers were unaware that this was coming. Did we see use of this API decrease over the last 3 months?

Yes, the usage as been declining:


That data only goes back a month, but even in that time, the usage has fallen significantly.

Thanks - that's a pretty dramatic decline, so it does seem to show that our deprecation process is working.
 

If so, then that would be a signal that our deprecation process is working as intended, and at some point we just need to pull the plug. My concern is that if we didn't see the use decline, that means that developers were generally unaware of the deprecation.

I suspect that people don't take deprecation seriously because historically we haven't actually followed through and removed features that we've deprecated.  For example, there's another thread on this mailing list currently about a deprecated feature that's used by 24% of pages.  It's very unlikely we'd be able to remove a feature that's used by 24% of pages.  Hopefully we'll raise the signal-to-noise ratio of these messages.

One of our goals for 2014 is to find ways to deprecate and remove large platform features with minimal breakage [1].  We're still learning how to do that effectively.  I really appreciate your feedback about how we can do better in the future.  Hopefully over time we'll iron out the rough spots in this process.

I think the overall goals of the blink and chromium teams (removing functionality like showModalDialog, NPAPI) are sound - we can't let ourselves be permanently handcuffed to insecure or poorly designed features. But we should also be cognizant of the fact that more and more enterprises are adopting Chrome precisely because of our focus on stability and security, and these enterprise customers expect a fairly rigorous deprecation process.

I would point at Chrome's removal of NPAPI support as a good example of how we might remove web platform features - there was ample notification, including end-user-visible notification, and a well-publicized deadline that gave partners ample time to migrate to new solutions. Now, granted, NPAPI has several orders of magnitude more adoption than showModalDialog() so it's not likely that we would have such a heavy-weight process for removing that API. But I would think that a public blog post at the time of deprecation, stating that we're deprecating the API and plan to remove it within 120 days would have been appropriate and fairly lightweight. Is there a way to make this part of the deprecation/removal process?

Jochen Eisinger

unread,
Mar 12, 2014, 6:56:12 AM3/12/14
to Drew Wilson, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
On Wed, Mar 12, 2014 at 10:27 AM, Drew Wilson <atwi...@chromium.org> wrote:



On Tue, Mar 11, 2014 at 4:14 PM, Adam Barth <aba...@google.com> wrote:
On Tue Mar 11 2014 at 2:35:00 AM, Drew Wilson <atwi...@chromium.org> wrote:
On Mon, Mar 10, 2014 at 4:50 PM, Adam Barth <aba...@google.com> wrote:

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Agreed, 3 months is a reasonable timeframe. What does it mean for an API to be deprecated - do we do any developer outreach letting people know that the API is going away, or is the deprecation warning printed to the JS console the only notification we provide?

Deprecation messages are printed to the console and announced on this mailing list.  Some deprecations are announced on the Chromium blog, but I don't see that this one was.  We could certainly do a better job publicizing when we deprecate a feature.
 
I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday.
 
In the near term, the easiest way to learn about deprecations is to search this mailing list for messages with the subject "intent to deprecate" or "intent to remove".

Jochen pointed this out also, and I've now set up the appropriate filters to make sure I'm able to track upcoming changes like this :)
 

Undoubtedly that's our own fault for not making sure we keep ourselves informed about developments in Blink, but I suspect that many other developers were unaware that this was coming. Did we see use of this API decrease over the last 3 months?

Yes, the usage as been declining:


That data only goes back a month, but even in that time, the usage has fallen significantly.

Thanks - that's a pretty dramatic decline, so it does seem to show that our deprecation process is working.
 

If so, then that would be a signal that our deprecation process is working as intended, and at some point we just need to pull the plug. My concern is that if we didn't see the use decline, that means that developers were generally unaware of the deprecation.

I suspect that people don't take deprecation seriously because historically we haven't actually followed through and removed features that we've deprecated.  For example, there's another thread on this mailing list currently about a deprecated feature that's used by 24% of pages.  It's very unlikely we'd be able to remove a feature that's used by 24% of pages.  Hopefully we'll raise the signal-to-noise ratio of these messages.

One of our goals for 2014 is to find ways to deprecate and remove large platform features with minimal breakage [1].  We're still learning how to do that effectively.  I really appreciate your feedback about how we can do better in the future.  Hopefully over time we'll iron out the rough spots in this process.

I think the overall goals of the blink and chromium teams (removing functionality like showModalDialog, NPAPI) are sound - we can't let ourselves be permanently handcuffed to insecure or poorly designed features. But we should also be cognizant of the fact that more and more enterprises are adopting Chrome precisely because of our focus on stability and security, and these enterprise customers expect a fairly rigorous deprecation process.

I would point at Chrome's removal of NPAPI support as a good example of how we might remove web platform features - there was ample notification, including end-user-visible notification, and a well-publicized deadline that gave partners ample time to migrate to new solutions. Now, granted, NPAPI has several orders of magnitude more adoption than showModalDialog() so it's not likely that we would have such a heavy-weight process for removing that API. But I would think that a public blog post at the time of deprecation, stating that we're deprecating the API and plan to remove it within 120 days would have been appropriate and fairly lightweight. Is there a way to make this part of the deprecation/removal process?

The chromium blog post contains a link to a list of all added, deprecated, and removed features: http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html

best
-jochen

PhistucK

unread,
Mar 12, 2014, 7:26:03 AM3/12/14
to Jochen Eisinger, Drew Wilson, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
By the way, this is not a very good list, as it does not say to which Chrome version the date of the intent (or actual addition, deprecation or removal commit) corresponds. Also, the audience must be familiar with your terms and the rules for actually acting on an intent (red means it is not approved, green means it is and might have happened).

This should really not be linked from a release notes blog post as it is too internal for the wider audience to comprehend.


PhistucK

Drew Wilson

unread,
Mar 12, 2014, 12:24:10 PM3/12/14
to PhistucK, Jochen Eisinger, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
To follow up after my offline discussion with jochen - a significant portion of the world's web pages are rendered by Blink, and that means that the security benefits from removing fragile APIs like this are commensurately large. However, I'd say that the size of our user base also means that we have an obligation to do an *outstanding* job of publicizing changes like this, because we're large enough that we're effectively changing the web platform when we do this.

Currently, it seems like our public notification of this change was:

1) A warning printed to the JS console for the last couple of months.
2) This email sent to blink-dev announcing our intent to remove on Feb 21 (roughly 3 months before this would hit the stable channel)
3) Line 57 from the "Blink Intents" spreadsheet, linked from a Chrome 34 beta release blog post:

Inline image 1

My concern is that not enough web developers will see any of these notifications. So, to make a concrete suggestion, I'd like to propose that the blink/chrome team publish a blog post at the start of every quarter, stating which APIs we intend to remove the following quarter. This has the side effect of slowing down the velocity of deprecations (if I put up a blog post on Jan 1 announcing our intent to remove API XXXX in Q2, then it likely doesn't the stable channel until midway through Q2, giving developers effectively 5 months to take action).

Jochen expressed his opinion that at this point we've already removed most of the APIs we're planning to deprecate, and that the current process/level of communication has been working OK so far, so this is basically not worth pursuing. And if that's the case, then OK. I just want to make sure that the blink team is aware of the fact that folks outside the team don't have the level of visibility into their plans that the blink team has been assuming.

-atw

Jochen Eisinger

unread,
Mar 12, 2014, 12:27:14 PM3/12/14
to Drew Wilson, PhistucK, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
On Wed, Mar 12, 2014 at 5:24 PM, Drew Wilson <atwi...@chromium.org> wrote:
To follow up after my offline discussion with jochen - a significant portion of the world's web pages are rendered by Blink, and that means that the security benefits from removing fragile APIs like this are commensurately large. However, I'd say that the size of our user base also means that we have an obligation to do an *outstanding* job of publicizing changes like this, because we're large enough that we're effectively changing the web platform when we do this.

Currently, it seems like our public notification of this change was:

1) A warning printed to the JS console for the last couple of months.
2) This email sent to blink-dev announcing our intent to remove on Feb 21 (roughly 3 months before this would hit the stable channel)
3) Line 57 from the "Blink Intents" spreadsheet, linked from a Chrome 34 beta release blog post:

Inline image 1

My concern is that not enough web developers will see any of these notifications. So, to make a concrete suggestion, I'd like to propose that the blink/chrome team publish a blog post at the start of every quarter, stating which APIs we intend to remove the following quarter. This has the side effect of slowing down the velocity of deprecations (if I put up a blog post on Jan 1 announcing our intent to remove API XXXX in Q2, then it likely doesn't the stable channel until midway through Q2, giving developers effectively 5 months to take action).

Jochen expressed his opinion that at this point we've already removed most of the APIs we're planning to

Just to clarify: APIs of the kind of showModalDialog() not in general.

Eric Seidel

unread,
Mar 12, 2014, 1:15:01 PM3/12/14
to Jochen Eisinger, Drew Wilson, PhistucK, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
I've been taking some notes on this thread, which I've now published:


AFAICT we failed to send an Intent To Deprecate about this removal, deviating from our published guidelines.

Michał Gołębiowski

unread,
Mar 12, 2014, 1:55:53 PM3/12/14
to Eric Seidel, Jochen Eisinger, Drew Wilson, PhistucK, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
The public link doesn't work, I get "denied access".
--
Michał Gołębiowski

Eric Seidel

unread,
Mar 12, 2014, 2:06:31 PM3/12/14
to Michał Gołębiowski
[bcc others]

https://docs.google.com/document/d/1WxCkKj28fnvkD0nSZTeu-prjQyg-Hg4acJwEEooZIek/pub works for me in an incognito window.

Please let me know if that still doesn't work.

PhistucK

unread,
Mar 12, 2014, 2:06:39 PM3/12/14
to Michał Gołębiowski, Eric Seidel, Jochen Eisinger, Drew Wilson, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
The first link (with /pub at the end) works for me even in incognito mode.


PhistucK

Michał Gołębiowski

unread,
Mar 12, 2014, 2:08:04 PM3/12/14
to PhistucK, Eric Seidel, Jochen Eisinger, Drew Wilson, Adam Barth, sas...@chromium.org, Tapasvi Moturu, blink-dev, Tom Chiverton
Thanks, works for me now. Maybe only Google Drive on iOS had problems with it.
--
Michał Gołębiowski

tapasvi...@gmail.com

unread,
Mar 14, 2014, 1:16:18 PM3/14/14
to blin...@chromium.org, Adam Barth, sas...@chromium.org, Tapasvi Moturu, Tom Chiverton
Just realized that our Siebel systems also use this feature and have an entire API built around the middleware layer.

Asking users of siebel systems to use IE seems like the only workaround for now.

bhcro...@gmail.com

unread,
Mar 16, 2014, 10:21:41 PM3/16/14
to blin...@chromium.org
FYI: Outlook Web Access (Microsoft Exchange) 2010 uses showModalDialog() for the attachments dialog and showing the address book.

Eric Seidel

unread,
Mar 17, 2014, 3:40:27 PM3/17/14
to blink-dev, James Robinson
We did not do as good a job publicizing our intent to deprecate
showModalDialog as we should have. To give affected sites additional
time to prepare, we have reintroduced showModalDialog into Dev-Channel
Chrome M35 [1] and plan to re-attempt removal in Chrome M36 (stable
around end of July).

Our current metrics show showModalDialog as used on <0.008% of Chrome
page loads [2]. Removing showModalDialog will improve both the
security and stability of Chrome for all users, thus we strongly
encourage remaining consumers of this API to move away from
showModalDialog as soon as possible, allowing all browsers to remove
it without disruption to users.

Mozilla has also shown interest in removing this API and we are
following their progress on their tracking bug [3].

Thank you all again for your feedback and site links.

1. http://crbug.com/345831
2. http://www.chromestatus.com/metrics/feature/timeline/popularity/195
3. https://bugzilla.mozilla.org/show_bug.cgi?id=981796

yog...@gmail.com

unread,
Mar 17, 2014, 3:55:32 PM3/17/14
to blin...@chromium.org, James Robinson
Eric,

Thanks for the update.  Given earlier discussions, any chance you guys can re-attempt removal in M37 instead of M36?  I imagine supporting it for one more release is not unreasonably challenging for you, whereas a September stable timeframe would make a huge difference for us and would be a big help in removing our usage.

Thanks.

--Yogesh

Eric Seidel

unread,
Mar 17, 2014, 4:31:36 PM3/17/14
to Yogesh Bhumralkar, blink-dev, James Robinson
We will re-evaluate site-breakages once we have the showModalDialog
back removed from Chrome again. However, I don't think it's a
reasonable trade-off for the 99.992% majority of page loads to expect
a worse Chrome experience in M37 to support this extreme minority of
usage. We need to move forward with this removal as soon as possible.
I understand this will be difficult for developers with pages
representing the 0.008%, but we cannot continue to defer improvements
for the vast majority of users who never see this feature.

Please expect that window.showModalDialog will be gone from Chrome by
M36 and prepare accordingly.

ilev...@gmail.com

unread,
Mar 21, 2014, 11:14:29 AM3/21/14
to blin...@chromium.org
window.showModalDialog() is used by web applications not by web sites. For this reason its usage seems low. In HTML elements, there is no good dialog for developers. showModalDialog and showModelessDialog was supported by IE and they are useful for us. Recently showModalDialog added to HTML5. There is also a Dialog element but its features lack this functionality.

For popup blockers, many developers left strong native-window dialogs and they use leaky and poor window-dialog implementations.
What we expect from browser vendors is to see native window bounded HTML5 dialog specification including showModalDialog, showModelessDialog etc unifiying HTML5 Dialog element specification.

Let me explain why we need modal dialogs with showModalDialog. If it is removed, we can't use modal dialog's code blocking feature:

SAMPLE FOR MODAL DIALOG:
JSDialog.confirm = function(msg){
 ...
 if(window.showModalDialog)
  return showModalDialog(path,args,alertProperties);
 else{
  return confirm(msg);
 }
};

WITH MODAL DIALOG:
function myCode{
 ...A
 if(JSDialog.confirm("Are you sure?"))
  ....B
 ...C
}

WITHOUT MODAL DIALOG:
function myCode{
 ...A
 JSDialog.confirm("Are you sure?", callbackForRest);
}

function callbackForRest(result){
 // must pass scope parameters and result for execution rest of code
 if(result)
  ...B
 ...C
}



PhistucK

unread,
Mar 21, 2014, 11:27:55 AM3/21/14
to ilev...@gmail.com, blink-dev
I would change the "WITHOUT MODAL DIALOG" example to this, which seems much easier -
function myCode () {
 function callbackForRest(result){
  // simply use the parameters from the outer function (closure).
  if(result)
   ...B
  ...C
 }
 ...A
 JSDialog.confirm("Are you sure?", callbackForRest);
}




PhistucK


ilev...@gmail.com

unread,
Mar 21, 2014, 6:19:19 PM3/21/14
to blin...@chromium.org, ilev...@gmail.com
Yes, it can be made simpler but main problem remains that we lost code execution pause feature. Assume we have many confirmation dialog, we have to split code to many pieces that results a very ugly code.
 

21 Mart 2014 Cuma 17:27:55 UTC+2 tarihinde PhistucK yazdı:

Adam Barth

unread,
Mar 21, 2014, 6:31:56 PM3/21/14
to ilev...@gmail.com, blin...@chromium.org
On Friday, March 21, 2014, <ilev...@gmail.com> wrote:
Yes, it can be made simpler but main problem remains that we lost code execution pause feature.
 
Yes, exactly.  That's the part of the feature that causes security vulnerabilities and the reason we're removing the API.

Assume we have many confirmation dialog, we have to split code to many pieces that results a very ugly code.

I'm sorry if it makes your code uglier, but it's a better user experience (because it does lock up an arbitrary set of tabs) and it let's us protect the vast majority of users who will never encounter a site that uses showModalDialog from the vulnerabilities it creates.

Hopefully Promises and other async programming patterns will make your code less ugly with time.

Adam

 
21 Mart 2014 Cuma 17:27:55 UTC+2 tarihindehistucK yazdı:

PhistucK

unread,
Mar 21, 2014, 6:32:07 PM3/21/14
to ilev...@gmail.com, blink-dev
While this is true, in browsers that fully support showModalDialog, the user experience was pretty awful anyway (which I believe is one reason the vendors want to remove it from the platform).
You have to remember that it was some Internet Explorer feature that got too popular that other vendors had to implement it in order not to break websites, not because they agree that this is a good feature. Luckily, the usage became very low now and the platform can get rid of it with minimal disruption. Unfortunately, your websites would take a hit, but your users will benefit once you move away from it.


PhistucK

Daniel Bratell

unread,
Mar 31, 2014, 6:38:44 AM3/31/14
to blin...@chromium.org, ilev...@gmail.com
On Fri, 21 Mar 2014 23:19:19 +0100, <ilev...@gmail.com> wrote:

> Yes, it can be made simpler but main problem remains that we lost code
> execution pause feature.

The exact reason it is useful is also the exact reason it is difficult to
implement correctly and in a useful manner. You want javascript execution
to pause, but most javascript engines are not designed to allow that, and
even if they were taught how to pause, the shared execution thread between
tabs will probably pause more than you would have expected.

I can see that there is a need for support for blocking input, but I think
another approach than showModalDialog is needed.

/Daniel

Jochen Eisinger

unread,
Mar 31, 2014, 7:11:04 AM3/31/14
to Daniel Bratell, blink-dev, ilev...@gmail.com
Note that there is window.confirm/prompt/alert which block JS execution, allow for user input, and are support correctly in chromium.

best
-jochen

monk...@gmail.com

unread,
Apr 2, 2014, 11:16:34 AM4/2/14
to blin...@chromium.org, ilev...@gmail.com, aba...@google.com
<<protect the vast majority of users who will never encounter a site that uses showModalDialog from the vulnerabilities it creates.>>
 
Seems to me it would only effect users that hit sites (like some APPLICATIONS) that actually use it.  If its usage is so low, why worry?  The people that do see it, use applications that NEED it. How does it protect affected users that never hit sites that use it?
 
Sounds like a cop out to me.  Sorry.
 
Dave

Anne van Kesteren

unread,
Apr 2, 2014, 11:31:38 AM4/2/14
to monk...@gmail.com, blink-dev, ilev...@gmail.com, Adam Barth
On Wed, Apr 2, 2014 at 4:16 PM, <monk...@gmail.com> wrote:
> Seems to me it would only effect users that hit sites (like some
> APPLICATIONS) that actually use it. If its usage is so low, why worry? The
> people that do see it, use applications that NEED it. How does it protect
> affected users that never hit sites that use it?

Because, as explained several times, it affects the implementation of
many other features. It makes the entire platform stack harder to
implement and reason about. Paired with its low usage, it is time for
it to die.


--
http://annevankesteren.nl/

PhistucK

unread,
Apr 2, 2014, 1:39:02 PM4/2/14
to Anne van Kesteren, monk...@gmail.com, blink-dev, ilev...@gmail.com, Adam Barth
Plus, it is a source of many security vulnerabilities because of the major complexity of the feature.


PhistucK


da...@davidlovell.com

unread,
Apr 10, 2014, 4:05:25 PM4/10/14
to blin...@chromium.org
I am new to this discussion, so forgive me if it is too late, but this is a pretty critical feature to a lot of large enterprise web applications. You will never record this traffic because it is intranet only. I guarantee you it is far more important than your search reveals.
 
An application I work on was IE only up until our current release and we chose Chrome as our first browser to become cross-browser compliant. Upon reading this thread, we may be unable to support Chrome for this application. The other alternative is a massive amount of refactoring of legacy code that is mature and tested. The development and QA effort is non-trivial for us to find another way to show these dialogs, not to mention testing code that hasn't required changes/testing for a long time.
 
I am here to put in the vote to not remove this functionality. If you want it to be removed from the standard, get that done first. Microsoft was rightly excoriated for years for flouting standards and not supporting standard features, yet Chrome is about to do the exact same thing. I predict that you will remove this, cause a lot of pain for enterprise application developers, product managers and software companies, and then have to painfully add it back. Seriously I am in a meeting right now and eveyrone groaned as I put this discussion on the projector.
 
Hoping for sanity!!
 
Thank You

On Thursday, February 20, 2014 9:24:59 PM UTC-5, James Robinson wrote:
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:

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

Mathias Bynens

unread,
Apr 10, 2014, 4:11:04 PM4/10/14
to da...@davidlovell.com, blin...@chromium.org
On 10 Apr 2014, at 13:05, da...@davidlovell.com wrote:

> I am new to this discussion, so forgive me if it is too late, but this is a pretty critical feature to a lot of large enterprise web applications. You will never record this traffic because it is intranet only. I guarantee you it is far more important than your search reveals.

UseCounters apply to all web pages that are opened in Chromium – including intranet documents.

da...@davidlovell.com

unread,
Apr 10, 2014, 4:17:30 PM4/10/14
to blin...@chromium.org, da...@davidlovell.com
So you are saying that Chrome is somehow able to communicate outside of completely locked down networks that have no internet access? This is the use case for our application and many applications like this.

Dirk Pranke

unread,
Apr 10, 2014, 4:17:06 PM4/10/14
to Mathias Bynens, da...@davidlovell.com, blink-dev
Enterprises may disable the UseCounter reporting, so, not necessarily.

AFAIK we have no idea how far off UseCounter metrics may be as a result of this, but it is a known flaw of our reporting.

-- Dirk

PhistucK

unread,
Apr 10, 2014, 4:17:52 PM4/10/14
to da...@davidlovell.com, blink-dev
Actually, web standards are a bit confusing in this regard.
While it usually makes sense that there is a standard and then the implementations arrive in some fashion, this is not always the case when it comes to browsers that have to deal with legacy code and old proprietary 'innovations'.
While new features are usually first specified and later implemented, old de facto, legacy and proprietary features that were never featured in a standard are being incorporated and specified in new standards in order to reflect the current state of the world and not in order to be innovative.
If browsers decide to remove a legacy, de facto or proprietary feature, the feature is first removed from the implementations and once the standards bodies get a positive feedback about compatibility and similar, the feature is removed from the specification.


PhistucK


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

da...@davidlovell.com

unread,
Apr 10, 2014, 6:42:50 PM4/10/14
to blin...@chromium.org
This is a fair point about the adoption and evolution of the standard. Pragmatically speaking, at the current time, browsers are a platform for applications: past, present and future. Even if this API was formally removed from the standard, you will break existing large-scale enterprise applications. I honestly believe that your statistics grossly underestimate the usage of showModalDialog(). I don't personally have concrete data, but I have worked on a lot of mature closed-network applications that use this functionality extensively. In most cases, it is fair to argue there are better ways to do this and I avoid this API in any new development. Regardless, I believe there is a lot of completed development work that will be broken by this. I think Chrome will be hurt as a viable enterprise platform by decisions like this.
 
In terms of advance notice, I only discovered this thread while searching for an unrelated issue about showModalDialog behavior on a Mac Chrome. If hadn't had that minor bug, I wouldn't even know this would be soon to dissapear and our customers would have been blindsided.
 
Has this ship already sailed or is there any chance that the decision will change in the near term?
 
I am at the point where we will have to either drop Chrome support in the current release or reforecast due to a non-trivial refactor effort. It would be useful for our planning process to know how definite this change is.
 
-David

Eric Seidel

unread,
Apr 13, 2014, 5:17:15 PM4/13/14
to da...@davidlovell.com, blink-dev
David:

Please assume showModalDialog will be removed from Chrome M36 (and
likely from other browsers [3] over the coming months/years).

Although it is possible Blink may have to delay removal of
showModalDialog again, I think at best that's likely to be a delay.
The vast majority of Chrome views do not involve showModalDialog and
it makes little sense for Blink divert engineering efforts away from
supporting the 99.99% of reported views which do not involve
showModalDialog [1] towards supporting this long-deprecated [2] (and
historically insecure) feature.

I would encourage everyone to read Opera's fantastic post [4]
summarizing this discussion.

I'm sorry I don't have a better answer for you. I very much
appreciate your reaching out to Blink with your concerns.


1. http://www.chromestatus.com/metrics/feature/popularity#ShowModalDialog
2. https://developer.mozilla.org/en-US/docs/Web/API/Window.showModalDialog
3. https://bugzilla.mozilla.org/show_bug.cgi?id=981796
4. http://dev.opera.com/articles/view/showmodaldialog/

da...@davidlovell.com

unread,
Apr 13, 2014, 9:11:00 PM4/13/14
to blin...@chromium.org, da...@davidlovell.com
Understood. I respect your decision and we will plan accordingly.

I do want to point out that your argument for removal seems based on existing Chrome user's usage. My point is that our app has never supported Chrome and we are trying to add Chrome support for the latest release. You may want to consider API usage statistics from all browsers not just Chrome if your goal is to expand the usage of this browser to new users, particularly in business environments where IE has typically dominated.

Thank You,
David

hans...@backbone4media.com

unread,
Apr 23, 2014, 8:13:03 AM4/23/14
to blin...@chromium.org, Adam Barth, sas...@chromium.org, Tapasvi Moturu, Tom Chiverton
+1


On Tuesday, March 11, 2014 10:35:00 AM UTC+1, Drew Wilson wrote:
On Mon, Mar 10, 2014 at 4:50 PM, Adam Barth <aba...@google.com> wrote:

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Agreed, 3 months is a reasonable timeframe. What does it mean for an API to be deprecated - do we do any developer outreach letting people know that the API is going away, or is the deprecation warning printed to the JS console the only notification we provide?

I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday. Undoubtedly that's our own fault for not making sure we keep ourselves informed about developments in Blink, but I suspect that many other developers were unaware that this was coming. Did we see use of this API decrease over the last 3 months? If so, then that would be a signal that our deprecation process is working as intended, and at some point we just need to pull the plug. My concern is that if we didn't see the use decline, that means that developers were generally unaware of the deprecation.
 

Adam

 
On Friday, February 28, 2014 4:56:58 AM UTC-8, PhistucK wrote:
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


On Fri, Feb 28, 2014 at 2:28 PM, <tom.ch...@gmail.com> wrote:
"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

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


hans...@backbone4media.com

unread,
Apr 23, 2014, 9:01:32 AM4/23/14
to blin...@chromium.org, yog...@gmail.com, tapasvi...@gmail.com, tom.ch...@gmail.com, aba...@google.com
Adam/Eric 

We are in a similar situation as Yogesh.
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 to aggressive for a change of this magnitude.
Our only option is to block Chrome users @ M36. Sad :-(

Epilogue:
Funny is how we waited > 2 yrs for Chrome to support showModalDialog. When it came it was buggy. You guys fixed the worst bugs and got it working ok, but as pointed out earlier in this thread, Chrome never got it right. Now you are removing it, maybe as the first of the big 3. And you only give us three months notice?? If you don't take more responsibility than that, why did you implement it in the first place? 

A viable alternative, and an understanding of writing internet applications with showModalDialog would be appreciated. 
@Adam: you cost and benefit comparison does not add up. The time we need to spend re-writing has no equivalent on the up-side. 
I understand we probably need to replace this feature. But your aggressive time frame makes us having to discuss if we should cancel vacation this year, or not support Chrome. My developers vote for the latter. 

/Hans
"There's always a snake in paradise"


On Monday, March 10, 2014 5:07:51 PM UTC+1, Adam Barth wrote:
On Thu Mar 06 2014 at 5:02:16 PM, <yog...@gmail.com> wrote:
Adam/Eric,

We've done some more detailed assessment and tried a couple of workaround options.  As you know, the challenge is in replicating the blocking nature of the showModalDialog call while still solving for the use cases.  The short answer is that we will need through October 31st to deal with this change.  Please read on for the rationale.

Within our code, we pause execution in the parent, wait for the return value from this call, and use that return value to continue execution in the caller.  Sometimes, the hierarchy takes us multiple levels deep from dialog to dialog.  There are arguments being passed back and forth across the dialogs, and as I mentioned, we have very core business/domain workflows implemented in this way (so the dialogs are pretty heavyweight).  While we'd like to move away from using these dialogs, this is a very large undertaking for us.  It requires us to touch every instance of the call (dialog + caller) to enable the same behavior, making changes up and down that entire call stack.  There are 600+ instances that we need to track down and modify without regression.

Given this complexity and scope, we will need all hands on deck to implement these workarounds, and we're estimating that it'll take 8 months for us to do it.  Obviously, this is pretty disruptive to the business and it deprioritizes other work we have in flight in order to focus on this effort.

Please let me know your thoughts.

Yogesh,

I sympathize with your situation.  No one wants to distract their development team for re-writing large portions of their app because an API they depend upon has been removed.

Unfortunately, in the period of time this thread has been going on, we've received a report of yet another security vulnerability with showModalDialog (http://crbug.com/350535 for those of you who can access security bugs or those of you reading this email in the future).  On the one hand, that's not particularly surprising because we've seen a long series of vulnerabilities in showModalDialog over the years, but, on the other hand, it makes the costs of keeping showModalDialog very concrete.

What makes removing features like showModalDialog difficult is that the costs are large but borne by relatively few people but the benefits are small but enjoyed by a relatively large number of people.  It can be difficult to judge whether the costs or benefits have more weigh.  Ultimately, that's a judgement call, and our judgement is that the benefits outweigh the costs.

I understand that you're on the cost side of this equation, but  I would ask you to understand that there are people on the benefit side of this equation too.

Adam

Adam Barth

unread,
Apr 23, 2014, 10:42:10 AM4/23/14
to hans...@backbone4media.com, blin...@chromium.org, yog...@gmail.com, tapasvi...@gmail.com, tom.ch...@gmail.com
I understand that you are unhappy with our removing showModalDialog.  You're right in saying that the implementation in Chrome has never worked well.  If you choose not to support Chrome in your application because of this change, I can understand and respect that decision.

Adam

ilev...@gmail.com

unread,
May 11, 2014, 8:53:57 AM5/11/14
to blin...@chromium.org
For our web applications, Chrome was the best alternative for IE. Chrome always supported new HTML standards ver well. Popups are an important part of our application and we use many windows for application. If we cannot open them as dialog in single window, they are going to be opened as windows and that will cause more windows to manage for users, that is a very bad user experience. As I said before we want native browser support for dialogs and don't want to use leaky js popup libraries. I hope chrome team revise their decision again.

21 Şubat 2014 Cuma 04:24:59 UTC+2 tarihinde James Robinson yazdı:

Ian Hickson

unread,
May 11, 2014, 12:13:38 PM5/11/14
to ilev...@gmail.com, blin...@chromium.org
On Sun, 11 May 2014, ilev...@gmail.com wrote:
>
> For our web applications, Chrome was the best alternative for IE. Chrome
> always supported new HTML standards ver well. Popups are an important part
> of our application and we use many windows for application.

For the record, showModalDialog() was a non-standard IE extension. It only
ended up in the HTML spec at all because the extension was later picked up
by multiple browsers, and when it was added it was with a sad heart since
it was quite poorly designed. I wouldn't use standards as a reason for
showModalDialog() to be supported.

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

Jochen Eisinger

unread,
May 11, 2014, 2:45:16 PM5/11/14
to Ian Hickson, ilev...@gmail.com, blink-dev
Also, the way showModalDialog is implemented in Chrome is no different that window.open() from point of view of how many open windows the user gets to see.

I agree however that opening several popups might not be the best user experience, and we hope to support the <dialog> element at some point to address this issue.

best
-jochen

gerla...@gmail.com

unread,
May 22, 2014, 2:38:04 AM5/22/14
to blin...@chromium.org, ilev...@gmail.com
Same here.

We're writing a huge business application. We don't see ways to create such applications without modal dialogs.
In our code we use this function about 900 times.

So we have to ask all of our customers to switch to IE. Or may be you can add a switch or something for the user to keep this function?

Hoping for some understanding...

Marco

thek...@gmail.com

unread,
May 22, 2014, 4:58:25 AM5/22/14
to blin...@chromium.org
No please not!!! We also got a huge web-application and most of our customers (over 15.000) are using chrome to run our software.. 
we have used this showModalDialog() function over 1000 times in our application ... it is very important for us! because sometimes we NEED to wait for an input in our business-application!

Please try to find a way that we can use this function in future... or all of this customers are forced to use an other browser


Regards Klaus

boot...@gmail.com

unread,
May 23, 2014, 6:46:37 AM5/23/14
to blin...@chromium.org
We're also running a business application which just works with Chrome and IE so dropping this, will force us to switch to IE for our customers,
which will arise huge problems for our Mac users.

So my idea is, why not wait with dropping this feature until the dialog element is officially supported?
In that way, developers would have a real alternative to simulate the functionality.

Regards

Carsten

PhistucK

unread,
May 23, 2014, 7:02:48 AM5/23/14
to boot...@gmail.com, blink-dev
Unless I am mistaken, I do not think <dialog> stops (or pauses) the script execution, so if your application could support the dialog element once it is enabled in the browser, you should be able to polyfill it already (I think there are already polyfills for it) and not wait for the browser to implement it or enabled it by default.


PhistucK


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

boot...@gmail.com

unread,
May 23, 2014, 7:14:14 AM5/23/14
to blin...@chromium.org
Anyway I think a web developer Roadmap when Chrome depreciates a features and when it is intended to beeing removed is urgently need, currently I find it very hard to get information on the chromium site as the informatins are really widespread and have to searched for here and there. Or am i wrong?


PhistucK

unread,
May 23, 2014, 8:15:01 AM5/23/14
to Nikolaus Schuh, blink-dev
From now (actually, since a few months ago) on, chromestatus.com should have all of the information you need regarding deprecations and feature usage (low non new feature usage can lead to deprecation and should be avoided).
I am not sure regarding smaller deprecations, so you should be able to find them at https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AjGgk26K1Cc-dEIySWlPNmFHMWlCUGxIQkstZXJ3clE#gid=0. Basically, the rows with 3 LGTMs will be deprecated or removed (depending on the value of the first column).


PhistucK


On Fri, May 23, 2014 at 2:14 PM, <boot...@gmail.com> wrote:
Anyway I think a web developer Roadmap when Chrome depreciates a features and when it is intended to beeing removed is urgently need, currently I find it very hard to get information on the chromium site as the informatins are really widespread and have to searched for here and there. Or am i wrong?


PhistucK

unread,
May 23, 2014, 8:17:06 AM5/23/14
to Nikolaus Schuh, blink-dev
Actually, this is not accurate. There are also trivial deprecations and they are not listed anywhere. You must go through the commits in order to find them, but trivial deprecations are less interesting (though I think any deprecation or addition, as trivial as it is, should be listed in a single place).


PhistucK

gerla...@gmail.com

unread,
May 23, 2014, 9:45:52 AM5/23/14
to blin...@chromium.org
Hello James,

please consider also that there are today a lot of applications running in browsers (netsuite, salesforce, myfactory, sap by design) - such applications aren't simple web sites but real line-of-business-apps. Your gonna break them, if you remove the modal dialogs.
So please have a heart for us developers. Our customers will kill us, if their daily work can't be done anymore...

musafi...@gmail.com

unread,
May 28, 2014, 2:11:42 AM5/28/14
to blin...@chromium.org
Hi,

Our application is on healthcare domain and has huge client base. In our application we have extensive use of window.showModalDialog(). As chrome is removing this feature, we will be in a great trouble and client will kill us. 

Is there any alternative solution in chrome which give us same functionality as showModalDialog() blocks the parent thread. I have tried javascript promise to open modal dialog with jquery but that does not block the parent thread and if we want to implement that we have to undergo a huge change.

Our code is something like:

var args = new Array();
args[0] = 1;
args[1] = 2;
var retVal = window.showModalDialog(url,args,width,height);
if (retVal==true)
{
   //do something
}
else
{
   //do something
}

So whatever alternate solution I have tried like javascript promise instead of window.showModalDialog(), the thread cannot be stopped after the call so that I can get the retVal.
Is there any way to stop the caller thread until the dialog is closed and I can get the retVal?

This is what my requirement. Please suggest any solution so that I can do the above or please do not remove window.showModalDialog() feature.

Thanks

Anirban Roy 

Torne (Richard Coles)

unread,
May 28, 2014, 5:01:11 AM5/28/14
to musafi...@gmail.com, blink-dev


On 28 May 2014 07:11, <musafi...@gmail.com> wrote:
> Is there any alternative solution in chrome which give us same functionality as showModalDialog() blocks the parent thread. I have tried javascript promise to open modal dialog with jquery but that does not block the parent thread and if we want to implement that we have to undergo a huge change.

No. The whole reason we want to remove showModalDialog is *because* it blocks the parent window, which is difficult to implement in a sane way. Modern web APIs are asynchronous, and you would need to restructure your application to be asynchronous too.

gerla...@gmail.com

unread,
May 28, 2014, 6:06:55 AM5/28/14
to blin...@chromium.org, musafi...@gmail.com
But You have done it before?
The Safari guys can do it and of course the Microsoft guys do it.

Please think of us developers - we just need such a method desperately. 

Torne (Richard Coles)

unread,
May 28, 2014, 6:10:26 AM5/28/14
to gerla...@gmail.com, blink-dev, Anirban Roy
If you read the previous posts in this thread, you will see that it's been a persistent and recurring source of bugs, and that it *still* doesn't actually work correctly in Chrome today - it *is* possible for JS code to still execute in the opener's context under certain conditions. So no, we haven't actually done this correctly before either.

The entire web platform is structured around asynchronous APIs. Your app must surely handle asynchronous behaviour in many other places already?

gerla...@gmail.com

unread,
May 28, 2014, 6:25:53 AM5/28/14
to blin...@chromium.org, gerla...@gmail.com, Anirban Roy
For us it would be just fine, to keep the function like it is - it works well.

We have a really large web application (more than 100 man years of development) with lots of plugins of external developers. More than 1000 usages of modal windows throug the code with lots of recursive calls. We don't see a way to live without it.

Tim Suh

unread,
May 28, 2014, 5:04:23 PM5/28/14
to gerla...@gmail.com, blin...@chromium.org, Anirban Roy
Is there a way to know in advance when the removal of showModalDialog will be committed for Chrome 36 (or deferred to a future version)? We've been following the discussion for the last several months and have been preparing to mitigate our customer experience in conjunction with 36 (after it was deferred from 35).

We're at the final stages of our preparation and need to make some decisions on whether to pull in resources to meet the estimated 36 stable date (which we think is around the beginning of July).

As much advanced notice as possible would be greatly appreciated. We're watching the SVN revisions for each release and checking these too:



--tim
It is loading more messages.
0 new messages