New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 55 users
Status: WontFix
Owner:
Closed: Feb 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Compat

Blocking:
issue 42939
issue 159838



Sign in to add a comment
showModalDialog should be modal to the opener page (input events should be suppressed on the page that opened the dialog)
Project Member Reported by darin@chromium.org, Jul 6 2009 Back to list
showModalDialog should be modal to the opener page (input events should be 
suppressed on the page that opened the dialog)

this is a web compat bug since it impacts sites that use showModalDialog.

the behavior of showModalDialog should be to lock out all tabs just like 
alert, confirm and prompt.

this bug is windows only (or perhaps views only) since the corresponding work 
for mac and linux is covered by  issue 15891 .
 
Comment 1 by ben@chromium.org, Jul 6 2009
Labels: -Pri-2 Pri-1 Mstone-3
Comment 2 by ben@chromium.org, Jul 6 2009
Status: Available
Comment 3 by ben@chromium.org, Jul 6 2009
It's not clear to me that we want to reuse the Alert code here. We should be figuring 
out how to reduce the number of app-modal locks rather than adding to them. So I would 
say that an implementation of this feature should not block the app like current app 
modal dialogs do.
Comment 4 by darin@chromium.org, Jul 6 2009
Ben, I'm not sure how to do that given the constraint that JS execution blocks on a 
call to showModalDialog.  Not making it app modal would cause other scripts interacting 
with the opener to re-enter JS.  Satisfying that constraint without making the dialog 
app-modal implies making the dialog modal to N tabs.  Such UI seems like it could be 
odd to the user.  I wish we could do something...
Labels: -Pri-1 -Mstone-3 Pri-2 Mstone-4
Comment 6 by jam@chromium.org, Sep 28 2009
 Issue 20490  has been merged into this issue.
Comment 7 by ben@chromium.org, Sep 29 2009
Labels: -Mstone-4 Mstone-5
Comment 8 by ben@chromium.org, Nov 19 2009
Labels: -Size-Medium
Comment 9 by oritm@chromium.org, Dec 18 2009
Labels: -Area-BrowserUI Area-UI-Features
Updating labels:
Area-UI-Features replaces Area-BrowserUI

Labels: -Area-UI-Features Area-Feature
Labels: -Area-Feature Area-UI
Labels: -Mstone-5 Mstone-X
Comment 13 by Deleted ...@, Mar 19 2010
Hi Guys,

we are heavily working with Chrome even on the developer builds - especially on web
sockets, see http://jwebsocket.com where we explicitly recommend Chrome! Could it be
a solution for all to let the showModalDialog act as your authentication window (in
5.0.356.0 dev) does? IMO you already implemented a really great solution here, all
requests mentioned in this thread should be satisfied with this because...

a) it really blocks the code of the current tab and waits for the result
b) you can click on other tabs, so app in these are not affected, which is great
c) the background (i.e. the parent tab) is grayed out, which is nice, however, which
IMO should be up to the application -> just don't give it the focus, if the app
intends to it can put a whatever colored div on it himself.
d) the modal popup can be moved only with the limits of the tab, which is fine as
well and does not confuse the user in other tabs.

We intensively vote for this solution.

Thanks to you all,
Alex from jWebSocket.org
Comment 14 by darin@chromium.org, Mar 19 2010
@fivefeetfurther: We would love that, but sadly it is nearly impossible to do.  The 
problem is that two tabs may be able to script each other, and if one tab is blocked on 
a showModalDialog call, then the other would be able to mutate the state of the blocked 
tab while it is calling showModalDialog.  As a result, web programmers would need to 
know how to deal with making their code safe to handle re-entrancy while calling 
showModalDialog.  That is asking a lot of web developers.
Fair to assume that this is off the plate for fixing due to the above mentioned technical reasons and/or usability 
reasons of like locking out tabs? I guess it's time to convert legacy stuff to html div based modal dialogs rather 
than window popups.
@darin: I don't see your point. Even with 1 tab and 1 modaldialog you can cause
re-entrancy. Just let the modaldialog call a function of it's opener.
And yes, 2 tabs can script each other. It's the web developer who decides which
functions are called on the other tab-window. I guess most web developers never call
a function on the other tab-window. The developers who do, surely now how to handle
re-entrancy. (The same issue you have with html div based modal-like dialogs.)
Comment 17 by darin@chromium.org, Mar 24 2010
@robinpelgrim: you are describing cases where the author intentionally introduces re-
entrancy.  my concern was with cases where the author did not intend re-entrancy.  we 
get enough bug reports about such problems when some input events mistakely slip in 
while an alert dialog is showing, that i am convinced that in general it would cause 
problems for web apps.  there is a run-to-completion promise when you call alert, 
confirm, prompt or showModalDialog.
@darin
What do you mean by 'mistakenly slips in'. I think you mean a mistake by the web
developer (application developer on the web?). Or am I wrong?
What cases are you referring to?

Run-to completion has nothing to do with re-entrancy. The promise still holds. You'll
just get another modal dialog.
The "html div based modal-like dialog" doesn't make it easier; it has the same
'problem' that there can popup (mistakenly) more than one 'modal' dialog.

Will that be resolved eventually? This is especially frustrating since Chrome is the best browser by far for our web apps except for these modal dialogs that do not behave as modal and get in the background.
Comment 20 by Deleted ...@, Oct 15 2010
We decided to refuse support Chrome in our intranet app because of lack ShowModalDialog Method! 
One way developers can workaround would be to have a page overlay (like div based html modal popups do)

set the overlay via js
window.showModalDialog()
unset the overlay via js


The un-setting only gets executed wehn that modal dialog is closed.

Though it would be nice if Chrome's own chrome gave an indication  
Comment 22 by Deleted ...@, Jan 3 2011
Hello Guys!

Can you please let us know the status of this? i believe, for the comments, it is not far from resolution once you decide what the resolution is, but the last post of discussion is dated of Mar 24 2010!!!
I personally am not sure if this should be fixed or given time investment if there are better things to do. While I am biased for this issue to be fixed since the app I work on uses/requires modal dialog's modality, from a usability standpoint, having modal dialogs locking out tabs or browser windows = not good/annoying. Looks at the alerts and confirm boxes. Applications written today should be relying on HTML div modal popups with callbacks rather than halting of JS execution or whatever the old way was. As for older applications that were written in the IE5 world, dunno, perhaps should change.
@priyajeet: Sorry, but you told us now the third time that you prefer "HTML div modal popups". I my eyes they are just a nasty workaround. YOU have to care to keep them cross browser compatible and there a lot of possible side effects (window resizing) with them. If all browsers would provide native modal dialogs like the other browsers already do life would be easier. This just not something a web developer should have to write code for.
@kaiser.nico: You can use a framework like dojo or jquery or prototype which take care of most cross browser issues. I have personally used dojo dialogs and they worked fine in any browser beyond IE6. Window popups are generally considered annoying, hence why the evolution of popup blockers. Window popups that lock you out are even more annoying. Try working on a mac with a modal popup, not only it locks you out of the browser tabs but also keeps right in your face even when you are in another app (till you close it).
We are talking about modal dialogs here which are opened by an app which depends on a certain dialog to be displayed to the user. This is no situation where you are in another app or tab. This is is something which is triggered by user interaction. The user wants to do something and the app needs a dialog to be displayed and filled by the user in order to continue as expected. This should be handled reliable for the developer by the browser. Of course it should be tab specific and not block the whole browser window. But that it locks the current tab until you close it is exactly what is needed here...
Yeah I know, I am just saying that reading above and stuff here http://code.google.com/p/chromium/issues/detail?id=456 it seems that this issue has no easy solution for Google to fix. If there is an easy solution then sure they should fix it. But the fact that this is an issue for alerts, an issue in Firefox as well as safari and google hasnt fixed both of these issues thus far = fair assumption its not a trivial task to fix. Both firefox and safari modal dialogs make it modal to your entire browser thus locking out all tabs. This is not good behavior. Why should site A block me from using site B. I am a multi site user and have 10 sites open, I dont want one of my sites blocking the other 9. Also this becomes even more cubersome if you launch modals from modals. Try this with a mac and you will see the issues modal windows give. Like I said neither safari nor firefox have this issue fixed. So in the end you have to give up something - perhaps locking out all tabs is easier to implement. But then back to square one, bad usability.

So like I said, if this is an easy task they should fix it, would make my own life easier, but if this is something that will require months / years (already been 2 years since this issue was opened) then well, more important bugs to fix.

However as a web developer its easier though a bit time consuming (still less than waiting for this bug to be fixed) and some learning curve to utilize html modal dialogs that are modal to that tab only (by putting a overlay preventing page access) + dont lock out other tabs + use notifications to launch chain of popups and/or have callbacks, add layer of overlays with different z-indexes etc. Not only you gain a windowless modal popup, you also dont ever have to worry about popup blockers.
I was thinking a few hacky ways to get close to app modality with that Chrome has. Too sleepy atm so just thinking aloud below.

We know that in its current implementation Chrome's modal popup halts execution on the main parent window till the popup is closed. However it allows a person to still muck around the main window and ignore the popup. In other browsers the popup is your focus and you never loose it till its closed. So say we do the same thing I mentioned before:

Current Parent Window:
- add a <div id='modalOverlay'> in the window.top // top so that you have overlay top most if you have iframes around.
- give it similar to this css

position: fixed;
top: 0px;
left: 0px;
opacity: 0.75
background-color: black;
display: none;
z-index: 1;

- create a wrapper for showModalDialog() or do this before you call that

var args = new Object();
args.opener = window // passing in current window reference

var overlay = top.document.getElementById('modalOverlay')
overlay.style.display = 'block';
overlay.style.width = window.innerWidth + 'px';
overlay.style.height = window.innerHeight + 'px';
overlay.style.zIndex = 9999;

var popup = window.showModalDialog(url, args, more_args);

// execution halted till that window is closed.
var overlay = top.document.getElementById('modalOverlay')
overlay.style.display = 'none';
overlay.style.width = '0px';
overlay.style.height = '0px';
overlay.style.zIndex = 1;

______________________


Now in your modal popup do something like

window.opener.top.document.getElementById('modalOverlay').onclick = function() { top.focus() } // top in latter case will refer to the popup window.


So now you have
1] Use of existing showModalDialog() without using a framework or implementing your own dialogs
2] Dialog halting JS on parent - existing functionality of Chrome
3] An overlay preventing user from mucking around or changing parent window unless of course he opens web inspector and starts changing html
4] Any clicks on the parent window will focus the pop-up, that is bring it to your face - this is useful when you have a modal popup and you switch tabs or applications and that popup gets hidden or minimized to the taskbar. So coming back to the parent tab shows the parent screen but the popup is still hiding and the user gets confused as to whats up. You can also put a message on the parent windows overlay to say 'dude there is a popup' 

Maybe you can do more and add more events or something to make this better. But seems like it will work though its just a workaround.
Comment 29 by Deleted ...@, Jan 4 2011
priyajeet: I agree with you modalDialogs are annoying for locking the whole browser. But this is just an inconvenience, while not providing modal dialogs at all is a huge problem.

I am a developer of a complex application, wich uses modal dialogs heavly. We would like to make it compatible with google chrome, but the non existence of modal implementation makes it too expensive to worth the effort. So, the better solution to the problems you indicated with modalDialogs is not providing modal at all? I don't think so.

If google can deliver something enhanced, that would be awesome!!! But if not, please deliver at least what we need to make it work.


I agree with fabiosg. The current state makes Chrome incompatible with many apps. Cross browser compatibility is crucial.

Eric
 Issue 82760  has been merged into this issue.
Any news on this? It still prevents us from using Chrome for enterprise applications. That bug has been reported 2 years ago.
Comment 33 Deleted
Bug is present in 13.0.782.218 m on windows.

The following javascript produces a window that is not modal.


window.showModalDialog(pageURL,Title,'dialogWidth:800px;dialogHeight:600px;');

Comment 35 by Deleted ...@, Sep 6 2011
Any updates in this issue. It prevents our users to use chrome for our application in which showmodaldialog is extensively used.

 Issue 95173  has been merged into this issue.
Will somebody ever look into this problem? It has been a few years and it still prevents a lot of enterprise applications from using Chrome
I have read the entire discussion here and I understand the difficulties to solve this problem. But I can't agree that the solution is to re-write thousands(maybe millions) of web apps to change their code because their code don't work on Chrome.
Owner: thestig@chromium.org
Status: Started
Yes, I've started looking into this. It's a tough cookie to crack.
Comment 40 by Deleted ...@, Mar 12 2012
Is there any light at the end of the tunnel with regards to fixing this? It is preventing us from bringing our Enterprise App (which relies heavily on Modal Dialogs) into Chrome.
Comment 41 by Deleted ...@, May 2 2012
We have Enterprise App supporting IE(relies on Modal Dialogs heavily) and want to extend to Chrome too. Is there any progress on this or when can we expect this.
We have an order management application that has been IE-only for years, and the only thing stopping us from porting it to Chrome is the fact that Modal Dialogs in Chrome are not really modal.  I mean seriously this bug has been around for three years?  Even FireFox has Modal Dialogs that work properly...
Hope this will be fixed...
showModalDialog is actually part of the HTML5 spec.
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dialogs-implemented-using-separate-documents

Sorry Chrome... but You need to fix this issue!
Comment 44 by dhw@chromium.org, Oct 10 2012
 Issue 155025  has been merged into this issue.
Will it be fixed? If so; any ideas when it will be fixed?
Comment 46 by cpu@chromium.org, Nov 13 2012
Blocking: chromium:159838
Project Member Comment 47 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Type-Bug -Area-Compat -Area-UI Type-Compat Cr-UI
Comment 48 by Deleted ...@, Apr 12 2013
vai demorar muito para corrigir este erro???
Cc: darin@chromium.org jochen@chromium.org
I would argue that we should solve this as follows:

1) fix  issue 42939 
2) make the window shown in response to showModalDialog modal
3) run the render view for the modal dialog in a dedicated window

Due to (3), the window can't script window.opener. However, that's only consistent with the window being modal. Also, it matches IE's behavior
 Issue 286298  has been merged into this issue.
Comment 51 by darin@chromium.org, Feb 24 2014
Status: WontFix
Marking WontFix. showModalDialog is being removed. See  issue 345831 .
This is actually blocking #139706, which according to initial comments, could have been fixed by using showModalDialog internally to implement the print preview.

The reason showModalDialog has so little usage is probably that it doesn't work in chrome; the kind of business SAAS applications which rely on showModalDialog aren't therefore compatible with chrome.

I wish I could start telling some of our diehard windows XP users to replace IE8 with Chrome. At present, I have to keep them on the IE upgrade path. (Our customers are schools, and our users are teachers - its proved almost impossible to convince them to upgrade beyond XP, the inertia is huge it would seem)



Sign in to add a comment