Closed Bug 618856 Opened 14 years ago Closed 14 years ago

Multiple modal windows should not be able to open on top of each other

Categories

(Toolkit :: General, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED WONTFIX
mozilla2.0
Tracking Status
blocking2.0 --- -

People

(Reporter: pocketgamer5000, Assigned: Dolske)

References

()

Details

Attachments

(3 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101213 Firefox/4.0b8pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101213 Firefox/4.0b8pre I am aware that Firefox is trying to do something with modal windows (making them seem apart of the web browser instead of outside of it?). Everything is going nicely- however, I believe these notifications should be persistent (stay on screen) until the user clicks OK or does an action that lets the website know he/ she acknowledged it. One prime example would be with GMail.com. Gmail has this feature that notifies you when you sign in and out too quickly in their service (something about potential malware). Unfortunately, the browser refreshes before the text can be read. I am aware that Chrome displays this notification by displaying it and them refreshing the page (or something along those lines). Firefox seems to associate the notification with the webpage, and when it refreshes, gets rid of it. I believe the severity should be major- because this is an "improved" feature that does not work like it used to (or is supposed to). Reproducible: Always Steps to Reproduce: 1. Log into Gmail 2. Quickly log out of Gmail Actual Results: Notification should appear, but as page reloads, it is gone without the user even being aware that there was a notification Expected Results: I suggest that Firefox should either behave similarly to Chrome in this manner- or even refresh the page behind while the notification is still being displayed (like in Firefox 3.6).
Blocks: 59314
blocking2.0: --- → ?
OS: Windows 7 → All
Product: Firefox → Toolkit
QA Contact: general → general
Target Milestone: --- → mozilla2.0
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, uiwanted
Slightly bit different test case can be found on http://mulletxhr.com/ - click the "Click me" button and see that the second alert shows right after the first one
Edge case, not going to block the release unless there is a common use case that this breaks.
blocking2.0: ? → -
Imagine that there is an ajax application which shows alert when the XHR failed. When user (or application itself) triggers two XHRs, for example removing items from the list, and the server is down at the moment then two alerts at the time will be shown. It will also be layout issue as the background will be darkened twice. I don't think it's very common case, but I wouldn't call it an edge case.
I believe this should be a blocker bug and I do not agree that this is an edge case; I do not think web developers use javascript alerts with the current behavior of FF4.0 in mind. What I'm saying is that FF4.0's current behavior is not the standard response for the alerts. They are supposed to be read and acknowledged (being clicked), and then something else follows, and with gadjo's test case, it seems that the first alert is read LAST and the last alert is displayed FIRST, above everything else. This shouldn't happen. Firefox's way of dealing with the alerts makes everything out of context. I really think it should be fixed.
Javascript alert, confirm, and prompt are produced by a script on a _page_. The tab-modal prompts that these produce should be and are currently page-modal. Also, by keeping a prompt open while the tab has already been navigated to another page is misleading UI and has similarities to phishing. I would call this WONTFIX or INVALID.
The latest comments seem to describe a different bug to what I thought the original bug described to resummarising. Please correct if it's wrong though I'm not sure how this is a regression.
blocking2.0: - → ?
Summary: Modal windows (?) in Firefox 4.0 should be persistent until the user clicks OK. → Multiple modal windows should not be able to open on top of each other
(In reply to comment #7) This is actually two closely related bugs. The previous and current descriptions describe the two issues. The first issue is the tab-modal dialog (produced by js alert/confirm/prompt) closing upon page navigation. This is new behavior, since the dialogs used to be window-modal. I explained in comment 6 why this is desired behavior and why the issue is INVALID/WONTFIX. The second issue is multiple tab-modal dialogs being opened on top of each other within a single tab. This is a valid issue and shouldn't happen.
(In reply to comment #8) > The first issue is the tab-modal dialog (produced by js alert/confirm/prompt) > closing upon page navigation. This is new behavior, since the dialogs used to > be window-modal. I explained in comment 6 why this is desired behavior and why > the issue is INVALID/WONTFIX. IMHO the issue from the attached testcase should be fixed at least in the way that alert shouldn't show at all. The code after window.location=... shouldn't be executed, we already changed the page by changing the location so we shouldn't run the code from the previous page
In other words these two examples have similar result, but the root cause is different. In the first one the script should be stopped after changing the page (changing the window.location) and in the second one the script should be stopped after showing modal prompt. And I'm pretty sure that the second issue was discussed in other bug, but I can't recall in which one.
This bug is very confusing, but I believe the following thing to be true: * XHR results should not be delivered while an alert is showing We need to block at least on this issue. I'm not sure there are other cases where we re-enter JS during the alerts, it may not be a regression that we need to block on.
blocking2.0: ? → betaN+
(In reply to comment #11) > * XHR results should not be delivered while an alert is showing I think we actually do guarantee that at the moment - comment 4's "imagine" makes that seem like a theoretical concern.
(In reply to comment #12) > (In reply to comment #11) > > * XHR results should not be delivered while an alert is showing > > I think we actually do guarantee that at the moment See link from comment 2
Gadjo: I don't understand comment 13. Are you saying that the XHR *can* finish while the alert is showing?
Enter the delay and press the "Click me" button to see the result. On my comp when the delay < 200 two alerts show together, with longer delay (like 500) there it's necessary to close the first alert to see the second one. Script shows some debug info in console
Jonas - I was saying it, but I've realised that I was wrong as the script was loading other scripts by adding <script> element into DOM (JSONP), not the XHR. So the mentioned problem is not referring to XHR, if I find more time I'll try to write the XHR testcase.
Fix attachment to work in 3.6 as well.
Attachment #498086 - Attachment is obsolete: true
I'd definitely like to see a XHR testcase as well. Note that I think that we've always had XHR and other loads finish and fire load events while alerts() are open. However it might have been that we used to be better at not opening a new alert while another alert() was showing. So I'm still not convinced that there are any important regressions here. Would love to see a testcase which shows otherwise.
This testcase checks if we fire XHR loads while alerts are open. As I suspected, both Firefox 3.6 and Firefox 4 can fire XHR loads while alerts are open. I think this is how we've behaved for a long time. It's not ideal but it's not new, I suspect this bug is a dupe.
(In reply to comment #19) > Created attachment 498170 [details] > Testcase showing xhr behavior > > This testcase checks if we fire XHR loads while alerts are open. As I > suspected, both Firefox 3.6 and Firefox 4 can fire XHR loads while alerts are > open. I think this is how we've behaved for a long time. > > It's not ideal but it's not new, I suspect this bug is a dupe. On Trunk I get this: sending xhr about to show alert xhr finished. alertIsOpen is true alert no longer open On 3.6 I get this: sending xhr about to show alert alert no longer open xhr finished. alertIsOpen is false Clearly there is a difference/regression...
With Alice's testcase behavior is actually somewhat problematic. On trunk the alert is dismissed when the new page loads while on 3.6 the new page load does not dismiss the alert...
3.6 actually might be worse off. In the double alert example in 3.6 the bottom alert is non-modal. Once the top alert is dismissed, the bottom alert does not restrict interaction with the page or the application... The alert does remain on top of the window though...
> On 3.6 I get this: > > sending xhr > about to show alert > alert no longer open > xhr finished. alertIsOpen is false This is not the behavior I'm seeing on 3.6 on OSX. What platform are you on?
Ah, indeed, on my WindowsXP box the alert seems to prevent the load from firing on 3.6.
Could someone please file a separate bug on the XHR issue as it is a different problem from what is described in the summary of this bug, and what is discussed in most comments in this bug. It would help a lot to have a focused bug on that problem. Please cc me on the new bug.
I don't think there's any other UI feedback needed here except for making sure that two tab-modal dialog boxes shouldn't be possible at once. They should just be sequential. Let me know if I've misunderstood the issue. :)
Keywords: uiwanted
I saw this using mkaply's testcase in bug 127903 before it was fixed: https://bug127903.bugzilla.mozilla.org/attachment.cgi?id=162703 I don't know if studying that testcase will lead to more examples of how to reproduce this bug. You can tell when it has happened because the background fade effect is applied twice, making the webpage darker than usual.
Whiteboard: [soft blocker]
Assignee: nobody → dolske
Whiteboard: [soft blocker] → [softblocker]
Justin, if you think you're not going to work on this bug in the next few days, I'll be glad to write a patch including an automated test case, during this week-end. I refer to the issue described in the current bug title, "Multiple modal windows should not be able to open on top of each other", which is actually different from the one described in comment 0. There are two slightly different approaches for ensuring that two tab-modal dialogs can't overlap. The difference lies in what to do when we receive more than one request to display other prompts while one is showing. Actually I don't think it's such an important difference after all, since this can be considered an edge case, but maybe you have reasons to prefer one method over the other. An aspect common to both is that, for each synchronous modal prompt call, we unavoidably start an inner event loop, and no action can be taken in response to the prompt until we have exited from (1) this event loop, and (2) all the other event loops started by other callers (in any window or tab) while this event loop is active. Another point I take for granted is that, when the user closes one prompt, it should disappear immediately from the screen. At this point, however, the original inner event loop might still be spinning, waiting for a nested event loop to terminate, even though the dialog has disappeared. This condition is guaranteed if, while we were waiting for the response, we received a request to display another modal prompt in the same tab. The implementation can be written in such a way that all pending requests are put in a queue and, as soon as the user confirms one dialog, we display the dialog that was put in the queue first, chronologically. With this approach, however, we're sure that no action can be taken by any caller until the last prompt for the window is closed. At this point, all actions are executed one after the other, but in a *reverse* order. The other approach is that we always display the dialog that was put in the queue later. With this approach, the order of execution of the actions would be the same as the order of the dialog responses, except for the action associated with the very first dialog that was displayed, that is always executed after all the others, unavoidably. The third option, not mentioned above, is to throw an exception if a modal dialog is already displayed in the tab, similarly to what happens when the user chooses the option to prevent the page from showing many prompts. This solution has a higher website breakage potential, however. The last point to consider is that the checkbox to prevent the page from showing additional dialogs should be included with the second dialog that is displayed, regardless of the order they are invoked.
Prompts with multiple nested event loops is a known hard problem. There aren't any great solutions, but thankfully it seems to seldom happen. Not exactly the current subject of this bug anyway. :) Queuing doesn't help, because you unavoidably have to spin a new event loop for each attempted prompt call. I think we may want to just immediately throw if another prompt is attempted (your "option 3" above), although we should really deal with this issue in another bug. There are already a few filed, since this scenario (multiple prompts from a tab) is already possible with Firefox 3.6 and earlier. I'd recommend just filing a new bug and doing the work there, if you want to hack on this. I'm going to WONTFIX this bug, since it's meandered over a multiple issues... - The original issue (wanting to keep prompt after page navigates under it) is a WONTFIX per comment 6 - Delivering XHR events while a modal prompt is being displayed is intentional and not a regression (see bug 619765 comment 25). Changing to blocking-. - Preventing multiple modal dialogs for a tab is bug 31889 (!). Also found related bugs 112294, 134293, 427332, 444442, and likely others.
Status: NEW → RESOLVED
blocking2.0: betaN+ → -
Closed: 14 years ago
Keywords: regression
Resolution: --- → WONTFIX
Whiteboard: [softblocker]
(In reply to comment #30) > Queuing doesn't help, because you unavoidably have to spin a new event loop > for each attempted prompt call. Queuing ensures that every "alert" or similar call results in a prompt being shown to the user sooner or later (unless the tab is closed or navigated away, of course), but right, it doesn't help with regard to the order in which we can return from such calls. > I think we may want to just immediately throw if another prompt is attempted > (your "option 3" above), although we should really deal with this issue in > another bug. Throwing is technically great because it puts a sane limit on the number of nested event loops that we can enter :-) It is also trivial to implement. My concern is that, in a generic web application, more important prompts might be obscured by less important ones. There are workarounds but would need a special implementation in the web page: evangelism required. Before starting to work on this solution (I can do that in bug 31889), whom should I ask to understand if this is really the desired behavior?
(In reply to comment #30) I think this bug should just cover not doubling the tint effect if it is already in place. So multiple prompts can display above each other but all use the same tint. Worth it to REOPEN for that?
It's a different issue - I've filed bug 626442
(In reply to comment #32) > I think this bug should just cover not doubling the tint effect if it is > already in place. So multiple prompts can display above each other but all use > the same tint. That's basically the "reverse queueing" approach described in comment 29, with the difference that, in that proposal, the current prompt was never overridden by a new one until the user clicked one of the buttons. That's my interpretation of Limi's user interface feedback, with which I agree: (In reply to comment #27) > I don't think there's any other UI feedback needed here except for making sure > that two tab-modal dialog boxes shouldn't be possible at once. They should just > be sequential. However a new "just throw" approach was also proposed. Although it may be an edge case, I see it as a small web platform change related to the work on tab-modal dialogs, and I think it should be made before the last FF4 beta or delayed after the next major version. Directions welcome!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: