471640 - Cookie confirmation dialog can be hidden by main window

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Tom Link]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

It seems to me the behaviour of the accept cookie dialog has changed with 3.0.5 to be non-modal. Maybe this is related to https://bugzilla.mozilla.org/show_bug.cgi?id=405239

Now it sometimes happens (a matter of bad timing) that I click on the webpage which causes the accept cookie dialog being opened behind the ff window. It then looks like the web page isn't loaded because ff waits for confirmation of that dialog.

Is there a way to make that dialog modal so that it is never opened behind the window?

I use ff 3.0.5 on win xp/sp3.

Reproducible: Always

Steps to Reproduce:
1.Set "Accept cookie" to "Ask every time"
2.Open a few pages that demand setting cookies
3.Click in the main window while the pages are loading
Actual Results:  
The "Accept Cookie" dialog is opened in the background. If you don't look carefully, it looks as if ff would hang and wouldn't load the page.

Expected Results:  
The confirmation dialog should always be in the foreground. I think it would be best to "embed" it in the window like the allow-popup dialog.

This seems to be a consequence of
https://bugzilla.mozilla.org/show_bug.cgi?id=405239

Comment 1

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

Probably what we could do is to parent the dialog against the toplevel chrome docshell instead of null or current docshell.

Comment 2

[Dave]

Experienced the same thing ... didn't happen with previous versions.  Annoying when window won't load because dialog box is in the background.  Only way to rectify it at this point is to minimize the main window or click on the button in the task bar numerous times to bring it front again.

Thanks to whoever figures out how to fix this.

Comment 3

[K. Adams]

Strange, but I have never encountered this behaviour in Firefox 3.0.5 on Linux; the cookie dialog boxes always come in on top of the main Firefox window.

However, when I visit a page that is very "cookie heavy" - i.e., it sends tens of cookie requests in rapid succession - sometimes the "current/blocking" cookie request dialog box is buried somewhere toward the bottom (from a Z-axis perspective) of the cookie dialog box "deck" (as in a "deck of cards" - I didn't want to use the word "stack" for obvious reasons).

For example, given a "deck" of cookie dialog boxes as shown (please view this posting in a monospace font for best results):

  +--------------------------+
  |  Confirm setting cookie  |       <--+
  |                          |--+       +-- These request
  |                          |  |    <--+   boxes are
  |                          |  |--+        "blocked" until
  | Allow - Session - Cancel |  |  |        a "lower-but-
  +--------------------------+  |  |        later" request
     | Allow - Session - Cancel |  |        box is answered.
     +--------------------------+  |
        | Allow - Session - Cancel | <----- FF 3.0.5 is
        +--------------------------+  |     waiting for
           | Allow - Session - Cancel |     an answer to
           +--------------------------+     the third cookie
                                            request box.

the Linux version of Firefox 3.0.5 often waits for an answer to a dialog box near the bottom of the "deck", even though it may have actually been dispatched **later** than the "earlier" dialog boxes above it.

My work-around is basically to keep tapping the [Esc] key so I don't have to shift 30-something non-modal dialog boxes to different parts of the screen in order to get to the box waiting for an answer.

(This of course presumes that a cookie dialog box will have "focus", regardless of its Z-axis position on the screen, and thus will be sent the keystroke.)

I am running Firefox 3.0.5 on Ubuntu Hardy 8.04 LTS.  Here is the User Agent string:

  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5)
    Gecko/2008121621 Ubuntu/8.04 (hardy) Firefox/3.0.5

This effect can be seen when visiting a web page like this one:

  http://www.wpxi.com/news/18396954/detail.html

Comment 4

[Tom Link]

It might be worth mentioning that I observed this problem when diverting newly opened pages to background tabs, i.e. open new pages in tabs + open tabs in background.

@K. Adams
Pressing ESC can stop loading the page though.

IMHO there is another problem involved in that the "Remember preference for this site" option isn't relevant when many pages from the same domain request setting a cookie (or many cookies). IMHO only one confirmation window should be visible so that the "Remember preference" option can take effect for subsequent cookies. IMHO it should never happen that two or more confirmation dialogs are opened. The second one should be opened only after the first one was closed. (BTW the same is true for the master password dialog when restoring a session.)

Comment 5

[K. Adams]

@Jonas:

Wouldn't making it modal and hooking it to the top-level chrome docshell inhibit page loading on other tabs while the cookie-requesting tab is waiting for an answer to the cookie request dialog?

It would seem to me that attaching a modal cookie request dialog box to the chrome's top-most level would cause events from all tabs to queue-up behind the waiting dialog.

Comment 6

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

(In reply to comment #5)
> @Jonas:
> 
> Wouldn't making it modal and hooking it to the top-level chrome docshell
> inhibit page loading on other tabs while the cookie-requesting tab is waiting
> for an answer to the cookie request dialog?

No, we continue loading while the popup is open. However you can't click on anything else in the window while the modal dialog is open.

This is how things always worked, even in FF2.

Bug 470356 should have fixed this one, so marking FIXED.