Open Bug 515521 Opened 15 years ago Updated 8 months ago

All pending cookie popups for a given domain should be handled when one of them is in the cookie confirmation dialog

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

People

(Reporter: mozilla_bugs_peep, Unassigned)

References

(
URL
)

Details

(Keywords: polish)

Attachments

(4 files)

The two cookies referenced in recent comments
79.54 KB, image/png
Details
A MOV of abberant cookie pop-up behavior
3.82 MB, application/octet-stream
Details
My cookie prefs - with "ask every time"
79.23 KB, image/png
Details
Example of the annoying behavior
173.93 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

When browsing to some sites with cookie preferences set to "ask", if multiple cookies are requested from the same site, the confirmations dialogs will pile up.  If you have "Apply this choice to all cookies from this site" checked, then all other pending cookie popup dialogs for that site should be dismissed.

For instance, if I were to go to foo.com and it's main page tried to set the following cookies:

foo.com[CookieA]
foo.com[CookieB]
adseller.com[CookieZ]
foo.com[CookieC]

Say the first popup appears asking about what I want to do with foo.com's 1st cookie.  If I applied-to-all blocking cookies from that site, I should only get one more popup (for adseller.com[CookieZ]).

Reproducible: Always
Here's an example website:

http://www.guardian.co.uk/business/blog/2008/oct/09/economics.useconomy

Right now it tries to set 5 cookies for "sitelife.guardian.co.uk".
URL: http://www.guardian.co.uk/business/bl...
By the way, this is a real regression bug to older major releases, most notably the FF2 series which would not open a bunch of modal dialogs at the same time, but step through the cookies one by one, applying the selections of previous dialogs. It's an instance of the overall broken modal dialog handling in the FF3 series. See e.g. bug 59314 for an actual exploit of other modal dialogs.
Can I bump this one? It is very annoying. Some sites will pop a dozen dialogs asking about the same domain, and you have to do them all before you can do anything else. Firefox should pop ONE dialog per domain: If one's pending, don't pop another one.
It becomes even more annoying when broken window managers (KDE, I'm looking at you!) mix up the stacking of the modal dialogs and you end up having to sort through 15 cookie popups trying to find the "topmost" active one.
yes, Bug 420155 complains about the stacking of modal dialogs - I didn't realise it was made worse by KDE's window manager (which I use too.) Whatever the reason, opening all those cookie dialogs at once is stupid, because as this bug describes you can't make your choice apply to all cookies for a domain if additional dialogs are already open for more cookies
hum now that master password popup storm bug #499233  has been solved - it would be also time to solve this one.
Blocks: 95397
This is my observation in Firefox 4: The sample URL shows about 10 cookie confirmations. Not all are displayed at once, but they were presented one after another. However there where times where 2 dialogs were shown at once. When that happened, those 2 dialogs were showing the same site (www.guardian.co.uk), but the Domain and Host fields of the cookies were a bit different. When the fields were the same the dialogs were shown one after another. I did not click "Apply this choice to all cookies from this site".
So it seems there already is a mechanism to queue the dialogs if they are for the same host/domain? Do we need more?
I can update the status of this bug and promote it to NEW, but I am not sure it is still valid. Please test with FF4.
Keywords: polish
Version: unspecified → Trunk
I don't quite know what you mean about "Domain and Host", but I've never really gotten to know cookies at a low level.

I just went to the example URL again and got two dialogs for "ad-emea.doubleclick.net" at the same time.  (Don't forget to turn off your ad blocker when testing this one! <grin>)

I'm using:

User Agent  Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110308 Firefox/4.0b13pre

I'd say this is still an issue.
When you click "Show details" in the dialog, you see various fields and values for the cookie. There are the Domain: and Host: fields, not necessarily both in each dialog. I do not know exactly what they mean, I just observe they are different in those 2 dialogs I see shown simultaneously. It is possible FF is treating them as from (or for) different domains. Whereas the bug title says specifically about "...cookie popups for a given domain...".
The same bug reported several times, and no response. It a shame that the privacy concious users have to suffer for this buggy firefox behaviour. See bug 430006, 420512, 420155, 430006, 426114
Summary: All pending cookie popups for the a given domain should be handled when one of them is in the cookie confirmation dialog → All pending cookie popups for a given domain should be handled when one of them is in the cookie confirmation dialog
The behaviour is true for Firefox 3.6 as are all those old bugs. However, I see it no longer happening in FF4. Please tell us how you can reproduce it in FF4.
Sorry, I've only tried with 3.6.13.
1.)  Make sure ad-emea.doubleclick.net is not in your cookie exceptions
(Preferences)
2.)  Disable any ad blocking software if you use any
3.)  Make sure you're set to ask for cookies
3.)  Go to
http://www.guardian.co.uk/business/blog/2008/oct/09/economics.useconomy
4.)  See cookie dialogs pop up.


Note: The ad-emea.doubleclick.net is working for me right now on that URL
consistently, but I don't know if/when the Guardian might switch to a different
ad system, but the idea remains the same.
And as a footnote, closing one of them does nothing for the other one.  They both have to be closed.  And in my case, close means clicking "deny" with the "Use choice for all cookies" checkbox checked.

And in case it got glossed over: I'm using Firefox 4.0-beta13-pre.
Ok, I see it now at http://technet.idnes.cz/cesky-vynalez-otackomer-ktery-vas-nauci-setrit-motor-pdy-/veda.asp?c=A110303_132303_veda_mla . I get 2 dialogs where the site and Domain field are the same. That is also shown in your screenshot. I can't reproduce with guardian.co.uk but it may be the ad system is providing me different or no ads (even though I am in EMEA :)) So I confirm the bug. This is with

Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can reproduce the annoying behavior with Firefox 5.0 for https://trac.torproject.org/projects/tor/report/14 after clearing my browser cache.

Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0
Hi, I've encountered this problem, specifically with a site that seems to attempt to set *thousands* of cookies.  It's obviously impractical to close that many pop-up dialog boxes, so this is pretty serious in that it requires a "force quit" (on Mac OS) of FireFox.  This behavior seems to be different compared to when clicking on links not in firefox vs. clicking on links in firefox, ... obviously, in the first, ff steals focus with the pop-ups and puts each right over the other.  I've certainly seen multiple pop-ups attached to the upper part of the browser after clicking a link in ff, but it doesn't seem to spawn thousands like this case here.  The best way to see and reproduce the version of this behavior I've seen is to either read my blog post:

https://josephhall.org/nqb2/index.php/fffgck

or watch the MOV I took while reproducing this behavior:

https://josephhall.org/misc/ff-cookie-fail.mov
I reported this as Bug 687114. As mentioned there: I was able to reproduce the behaviour with the site 
http://photography.nationalgeographic.com/photography/photo-of-the-day/camel-thorn-trees-namibia/
running Firefox (v.6.0.2) on my Windows-7 box.

Marking Bug 687114 as a duplicate of this one now.
This bug is still valid in Firefox 8.0 (on Linux). I just visited a site and got 10+ identical cookie confirmation popups.
Active popup got buried on Debian/LXDE, FFox 10 - 20+ unresponsive popups over the active one
please set as major - it forces you to kill ffox.

see also 
 bug 427184 replace pop-up cookie prompt dialog with use of information bar
 bug 434971 Multiple cookie "confirmations" requested for same site with "ask me every time" 
 
 bug 515521 – All pending cookie popups for a given domain should be handled when one of them is in the cookie confirmation dialog
 bug 616843 A number of modal prompts should be made tab-modal
 bug 633763 Cookie confirmation dialogs should be tab-modal
See links for bugs in comment #10:
 bug 426114 comment #2 – Multiple accept popups for the same cookie. 50+! 
 bug 420155 Large number of cookies come in and the active dialog does not always have the focus 
 bug 420512 The Cookie LEARN option cannot be stopped at once and begs many times until website stops setting cookies
 bug 430006 – Infinite dialog loop for cookie permission
The problem is that Firefox keeps popping dialog for every element on a page before it has a chance to honour your selection of "use this choice for all cookies from this domain". Even worse, the dialog windows often get interleaved and you cannot click the button in the topmost window because one of the lower located windows insist on being served first (and there is no way to tell which one of them).

I believe that from usability standpoint, for every one page, only one cookie prompt dialogue should be open at a time. The following requests should wait till the first one is answered, then it will be possible for the rest of the requests to use the result of the first one.

One particularly bad example here:
http://www.metroxpress.dk/nyheder/storbrand-i-valby-er-ude-af-kontrol/KOblaE!ICHCUsaD4svws/

The problem is still here in FF 11.
@Eugene: You might want to edit that last comment on this bug to have an explicit warning about how that link really sucks (i.e., as a particularly bad example of this behavior).  I clicked on it and wasted about 5 minutes of my life hitting ESC. ::)
Well, I guess you saw just how annoying it can be, @Joseph.
I generally love open source projects, FF in particular, and try to support them when possible. 

But bugs like this one, which have been around for 2 1/2 years (not counting the multiple dupes reported in Comment 23) make me despair. 

This behaviour crops up so often it makes me want to switch browsers.

You would think that something that forced you to kill FF would be flagged with importance major not minor.

Is anyone planning to fix this or should we assume this bug will be here until the end of time? If the latter, I'm definitely switching ....
I agree. I'm not capable of fixing it, so I know it's whiny to post here, but this problem has been ongoing for so long and across so many Firefox versions - I still get this with Firefox 12 (and probably 13).

I hit the problem recently here:
http://asianwiki.com/Lie_to_Me_%28Korean_Drama%29
The fact that there's no "cancel" option makes it especially annoying.

I assume the problem is that even though you hit 'deny', the browser hasn't retrieved the saved setting - once you've saved 'deny' for a site and then go to it again, the problem doesn't come up.

It would also be great to allow blocking of *.example.com for domains like tubemogul.com which use lots of different subdomains to set cookies (either as a tracking technique, or just because they use different cookie domains for each backend server).

    
    

    
  
Marking bug 434971 as duplicate of bug 515521 has the effect of downgrading the importance of the bug, as bug 434971 is marked as a major bug and bug 515521 is marked as a minor bug.

    
    

    
  
"All pending cookie popups for a given domain should be handled when one of them is in the cookie confirmation dialog" could also be "Wait for the current modal dialog to be processed before determining whether a second modal dialog should be displayed."

That is, in the case of 

foo.com[CookieA]
foo.com[CookieB]
adseller.com[CookieZ]
foo.com[CookieC]

the current logic for ask for cookies every time appears to be 
1. Are there user rules for all cookies in the downloaded page?
2. If no, queue all unresolved cookie requests.
3. Display the first cookie request as a dialog box.

where I believe the simpler-to-implement logic would be
1. Are there user rules for the first cookie in the downloaded page?
2. If no, display the first cookie request as a dialog box.
3. If there is another cookie request, go to step 1 and process the next cookie based on the rule set as revised in step 2.

    
    

    
  
(In reply to Chas Belov from comment #32)
> Marking bug 434971 as duplicate of bug 515521 has the effect of downgrading
> the importance of the bug, as bug 434971 is marked as a major bug and bug
> 515521 is marked as a minor bug.

The importance field has little or no practical impact for values between "trivial" and "major", but I'll change it anyway. I don't think it could be major, as there's an easy workaround which is not to use the rather broken "ask" setting.
Severity: minor → normal

    
    

    
  
Related to bug 546746 which is explicitly referenced in nsCookieService::SetCookieInternal, which refers to CanSetCookie, which is found in nsCookiePermission.cpp

    
    

    
  
It appears one or both of the following is a workaround for those of us who want to continue to use "ask every time":

In about:config, set the value of each of the following to 1

network.http.pipelining.maxrequests (instead of 4)
network.websocket.max-connections (instead of 200)

I'm guessing this will cause a performance hit but that might be less of an annoyance than the multiple dialogues.  I just tried it, and it is certainly less annoying to me.

    
    

    
  
(In reply to Michael Lefevre from comment #34)
> major, as there's an easy workaround which is not to use the rather broken
> "ask" setting.

And manually delete all the cookies I don't want every few days?
Or install some add-on to decide which cookies I do and don't want?

Why can't I just decide whether or not to accept cookies when they arrive?  If the feature is broken it should be fixed, not avoided.

    
    

    
  
It's been avoided for over 1,012 days.

    
    

    
  
I withdraw the workaround; it doesn't work.  http://www.apple.com still sets multiple cookies for images.apple.com via multiple stacked dialogues.

I would have expected that setting all of the following preferences to 1 would have worked around the problem by preventing multiple cookie requests from coming in at the same time but it doesn't:

network.http.max-connections
network.http.max-connections-per-server
network.http.max-persistent-connections-per-proxy
network.http.max-persistent-connections-per-server
network.http.pipelining.maxrequests 
network.websocket.max-connections

    
    

    
  
(In reply to Michael Lefevre from comment #34)
> I don't think it could be major, as there's an easy workaround which is not
> to use the rather broken "ask" setting.

Downgrading the severity of a bug because its about a feature which is buggy.  Brilliant!!!1!

    
    

    
  
I find it incredible that Firefox has gone through thirteen major versions since I first experienced this bug and it has yet to be addressed.

    
    

    
  
Still here in Ffox17

    
    

    
  
Yes - please, please do something!  I've created this account just to urge action on this bug, which has intermittently caught me out for years and years.  I've just visited a site on an Ubuntu machine (17.0.1) which took me more than 15 minutes going round and round a screen full of about 25 popups, dragging them into lines and trying to dismiss them one by one.  At least with KDE there was a serial number in the window banner so you could see which was the dismissable popup; in Ubuntu there is no such thing so there is no alternative but to click on EVERY SINGLE ONE again and again, gradually reducing the pile until they're all gone.  It's obvious that no developer with the ability to solve this problem has ever had it because they would have been immediately struck by how ridiculous it is, and as far as I can make out, how easy it would be to change the logic to fix it.

    
    

    
  
Is it possible this bug is fixed in FF19? 

I tried the links in comments 16, 20 and 24 and got a single popup which was dismissed with a single deny .... ?

    
    

    
  
This page produces two pop-ups for cookies from the same site in 19.0.2:

http://www.businessinsider.com/fipel-lighting-technology-david-carroll-wake-forrest-2013-1

    
    

    
  
I just tried the link in comment 20 and I still had a dozen+ dialogs for the same site popup.  I'm running Mac 19.0.2.

Mike: Do you have "images.nationalgeographic.com" in your exceptions list?  Or are you running an ad blocking plugin?

    
    

    
  
I do have an ad blocking plugin (Ad Block PLus), maybe that is blocking some images which are generating some of the cookie requests.

I guess these should really be tested with a new profile with no add-ons.

    
    

    
  
Please please fix this problem! It's extremely annoying to have to respond to many series, and this frequently causes FF to freeze completely and require a force quit.

    
    

    
  
Up to Firefox version 26.0 ... this bug is still here 4 years, 4 months after first reported (Sept 2009). Meanwhile, in other news, Chrome continues to gain market share at the expense of Firefox.

    
    

    
  
The Mac App Store just DOS'd my computer thanks to 75+ cookies that screwed Firefox for 5 minutes while I played whack-a-mole with the Escape and Alt-Tab keys (because the cookies don't even get focus right, so you have to find the right one to kill next)

    
    

    
  
I recommend installing the Self-Destructing Cookies add-on instead.  Not only will your problem go away, but you will never have any more cookie pop-ups to deal with and you will get the satisfaction of seeing endless notifications about the number of cookies, trackers etc which "self-destruct" when you close a tab.

    
    

    
  
(In reply to Matthew Marks from comment #51)
> I recommend installing the Self-Destructing Cookies add-on instead.  Not
> only will your problem go away, but you will never have any more cookie
> pop-ups to deal with and you will get the satisfaction of seeing endless
> notifications about the number of cookies, trackers etc which
> "self-destruct" when you close a tab.

Well, this does something different than I want: I would like to have permanent cookies for carefully selected sites, and temporary or disabled cookies otherwise. If I understand you correctly, the Self-Destructing Cookies add-on does only one of the three options (all cookies are temporary).

    
    

    
  
No, Self-Destructing cookies is not limited in that way.  By default, all cookies, local storage etc (it does more than cookies!) are deleted when you close the tab, but if you click on the red symbol you get two other options: keep until the browser is closed, or keep forever.  So, for your carefully selected sites, you merely change the mode with two clicks.  Believe me, it's a revelation compared with Firefox's clumsy dialogue-for-every-cookie mechanism.

    
    

    
  
This is still happening in FF30.0 on Mac OS X and Linux... and is really irritating.

    
    

    
  
This bug caused my FF31 in Ubuntu 14.04 to hang, requiring a forcible process termination.  Here's how. The UX geniuses have removed the title bar from the cookie handling dialog popups.  Now, it's not possible to reposition these popups.  When multiples for the same site open at the same time, occasionally they do not sit on top of each other in the order they were created by FF.  FF does require that they dialog boxes be dismissed in the opposite order they were raised, most recent first.  So, when the cookie dialog needing to be addressed by the user is buried underneath another, you are stuck.  You can't get to it.  Up the creek without a paddle.  So, this bug now cause FF to become unresponsive to user input.  It should be escalated.

    
    

    
  
Brilliant!

But here's a paddle: in most window-managers, you can also move windows by holding Alt and pressing left mouse button within *anywhere* in the window, and then dragging around. Handy for windows whose title bar is obscured, or off the top of the screen. (Hopefully) this trick also works in situations where the title bar is missing altogether (unless the KDE/Gnome/whatever "geniuses" have specifically disabled it for this situation...)

Apart from that, nowadays, I'm using the "self-destructing cookies" add-on to prevent the madness in the first place: https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/

    
    

    
  
This bug really gives a poor impression of Firefox to privacy-conscious first-time users. On some pages the huge number of popups is laughable; for example try going to
http://www.fragrantica.com/perfume/Yardley/Lily-of-the-Valley-9012.html

The user will wonder how on earth the Firefox devs could have not spotted something so jarring to the user experience.

    
    

    
  
This has become a serious issue. Until all cookie permissions boxes can be dismissed (theoretically a bad site could send hundreds of cookie requests) the browser is hijacked by the dialog. You cannot change tabs, and quitting (at least in recent builds on Mac) causes the browser to crash.

    
    

    
  
Review time. Substantial changes since 2015 …

    
    

    
      
  

    
  
Severity: normal → S3

    
    

    
  
The severity field for this bug is relatively low, S3. However, the bug has 32 votes.

:mossop, could you consider increasing the bug severity?


For more information, please visit auto_nag documentation.


Flags: needinfo?(dtownsend)

    
    

    
  
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.


Flags: needinfo?(dtownsend)

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  
Flags: needinfo?(mp3musicportalmedia)

    
    

    
  
Restricting commenting here for the time being due to this bug being a target for spammers. I think this bug is well understood at this point anyway.


Restrict Comments: true

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: