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?
showModalDialog allows one WebView to schedule work, whereas with alert/confirm/prompt/print, no WebView may schedule work.
What about debugger? Mutating DOM and evaluating setTimeout from the console while on a breakpoint is a generic use case for us.
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.
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.
"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.
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.
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.