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

Status: RESOLVED WONTFIX

(Toolkit :: General, defect)

Description

[Stanley Chan]

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

Comment 1

[Alice0775 White]

Attachment: Testcase( possibility ?)

Comment 2

[gadjo]

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

Comment 3

[Dave Townsend [:mossop]]

Edge case, not going to block the release unless there is a common use case that this breaks.

Comment 4

[gadjo]

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.

Comment 5

[Stanley Chan]

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.

Comment 6

[Frank Yan (:fryn)]

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.

Comment 7

[Dave Townsend [:mossop]]

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.

Comment 8

[Frank Yan (:fryn)]

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

Comment 9

[gadjo]

(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

Comment 10

[gadjo]

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.

Comment 11

[Benjamin Smedberg]

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.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

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

Comment 13

[gadjo]

(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

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Gadjo: I don't understand comment 13. Are you saying that the XHR *can* finish while the alert is showing?

Comment 15

[gadjo]

Attachment: Testcase for comment 2 with debugging info

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

Comment 16

[gadjo]

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.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Testcase for comment 2 with debugging info

Fix attachment to work in 3.6 as well.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: 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.

Comment 20

[Nochum Sossonko [:Natch]]

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

Comment 21

[Nochum Sossonko [:Natch]]

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

Comment 22

[Nochum Sossonko [:Natch]]

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

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

> 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?

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ah, indeed, on my WindowsXP box the alert seems to prevent the load from firing on 3.6.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 26

[Nochum Sossonko [:Natch]]

Bug 619765 filed.

Comment 27

[Alex Limi (:limi) — Firefox UX Team]

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. :)

Comment 28

[Daniel C]

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.

Comment 29

[:Paolo Amadini]

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.

Comment 30

[Justin Dolske [:Dolske]]

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.

Comment 31

[:Paolo Amadini]

(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?

Comment 32

[Nochum Sossonko [:Natch]]

(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?

Comment 33

[gadjo]

It's a different issue - I've filed bug 626442

Comment 34

[:Paolo Amadini]

(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!