Closed Bug 302596 Opened 19 years ago Closed 9 days ago

Accept cookie dialog (sheet) forces background tab to foreground (active)

Categories

(Camino Graveyard :: Tabbed Browsing, defect, P3)

PowerPC
macOS
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: terpstra, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050728 Camino/0.9a2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050728 Camino/0.9a2+

If a page in a background tab tries to set a cookie, and the user preferences
are set to ask whether or not to accept it, the cookie-setting tab becomes
active. This can be a real nuisance if you're doing something in another tab...
If a tab has been relegated to the background, it should STAY in the background
until the user activates it.

Reproducible: Always

Steps to Reproduce:
1. Set prefs to make new windows and tabs "load in the background"
2. Set prefs to "ask before setting each cookie"
3. Navigate to a page with links to pages which will try to set a cookie
(example: www.msn.com)  NOTE: make sure the linked page you will use isn't in
your exceptions list.
4. Cmd-click the link to the cookie-setting page (example: the "news" link ->
msnbc.com) in order to load it in a background tab.

Actual Results:  
Background (cookie-setting) tab becomes active, with cookie sheet visible. Tab
remains active after dialog has been dismissed.

Expected Results:  
Background tab remains in background.  Cookie-setting script pauses and an alert
icon appears on the tab.  When tab is activated, cookie sheet displays.  Once
cookie sheet has been dismissed, cookie-setting script execution continues.
This is fallout from the security fix in bug 298320; see comment 9 and after. 
There's no way to fix it right now, unfortunately.  It *should* be fixed, so I'm
confirming this bug, however.

Probably depends on bug 123908 or getting nsIPrompt to provide more detailed
info about what kind of dialogue.
Status: UNCONFIRMED → NEW
Depends on: 123908
Ever confirmed: true
Priority: -- → P3
This bug is really annoying, affects Mozilla, FireFox, and Camino, and has
existed for years.

I'd love it if the browser never used dialog boxes for prompts any more -- we
should be using chrome inside a specific tab, which works within the context of
the rest of the browser, and is more consistent.

*** Bug 324616 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I have encountered a similar bug.  When the page loading in the background is loading and I use the mouse to click-and-drag that tab to reorganize and then the cookie-setting dialogue pops up while I am click-and-dragging the dialogue box is unresponsive to the mouse.  I have found that the keyboard responds though (like Alt+D for deny).
(In reply to comment #2 and comment #4)
This is a Camino bug only; the fact that this happens in Camino is specific to Camino implementation (it has not existed for years in Camino--only since 2005-06-28, when the fix for bug 298320 landed) and any fix will likely be specific to Camino as well.  Issues with Firefox and Seamonkey need to be filed as seperate bugs against those components, even if the symptoms are the same.
Tweaking summary based on some recent dupes, fixing assignee/QA.
Assignee: mikepinkerton → nobody
QA Contact: tabbed.browsing
Summary: cookie accept dialog causes background tab to become active tab → Accept cookie dialog (sheet) forces background tab to foreground (active)
This switches us back to the original tab after the sheet is dismissed. Simon alluded to doing this back when the original patch landed, as it turns out, and I have no idea why we never did it; it makes this behavior *way* less annoying.
Attachment #278541 - Flags: superreview?(mikepinkerton)
Comment on attachment 278541 [details] [diff] [review]
half-fix [landed]

sr=pink
Attachment #278541 - Flags: superreview?(mikepinkerton) → superreview+
Comment on attachment 278541 [details] [diff] [review]
half-fix [landed]

Landed on trunk and MOZILLA_1_8_BRANCH. Per discussion with pink, I bullet-proofed it to handle the case where, somehow, the BrowserWrapper has gone away before we get the dismissal callback.
Attachment #278541 - Attachment description: half-fix → half-fix [landed]
The described behaviour also occurs in Firefox (whatever version, latest 3-RC still has it) so this bug report is also valid for Firefox. As to whether the cause is similar to that in Camino I do not know, but the annoying background->foreground transition for every site which wants to set a cookie (read: more than half of the web) makes opening tabs in the background quite an annoying exercise in futility. A mechanism similar to that for the extension installer (bar on top of browser window which asks for permission) would be much better, even if that meant the tab content would not load until the user made a choice wrt. the offending cookie.

If this is not implemented in the main browser it might make a good extension...
(In reply to comment #14)
> The described behaviour also occurs in Firefox (whatever version, latest 3-RC
> still has it) so this bug report is also valid for Firefox.

Firefox and Camino use totally different UI front-ends, so this bug report has nothing whatsoever to do with Firefox. Comment 5 is still quite accurate.
(In reply to comment #15)
> 
> Firefox and Camino use totally different UI front-ends, so this bug report has
> nothing whatsoever to do with Firefox.

See bug 405239 for the Firefox side of this issue.
I think this is no longer an issue in 2.0a. Camino now brings the relevant tab forward when showing the Cookie dialog, and then returns to the one that was watched earlier when the Cookie dialog is done.
(In reply to comment #17)
> I think this is no longer an issue in 2.0a. Camino now brings the relevant tab
> forward when showing the Cookie dialog

That is exactly the bug.

> and then returns to the one that was watched earlier when the Cookie
> dialog is done.

See comment 10.
I think another way to describe this bug is to say that the cookie prompt should be tab-modal. It should:

- allow one to switch tabs while the dialog is showing in one of them
- allow the tab to be closed with such a prompt
- not change the active tab to a foreground one

Blocking bug 616843.
Blocks: 616843
This is a Camino bug, and thus can't block a Firefox bug.
No longer blocks: 616843
Status: NEW → RESOLVED
Closed: 9 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: