Closed Bug 434971 Opened 16 years ago Closed 12 years ago

Multiple cookie "confirmations" requested for same site with "ask me every time"

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 515521

People

(Reporter: jgxenite, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5

If you enable "Ask me every time" for your cookie in Firefox 3.0b5, and browse to a site where multiple cookies may be set for one domain, Firefox loads confirmation dialogs for each cookie instead of once for the site. 

This is a regression from Firefox 2, where Firefox would only load one dialog, and only re-request authentication for the site if you cancelled it or didn't say to apply it to all cookies from the site.

The given URL demonstrates this - one of the pages returns around 30 cookies, and almost crashes Firefox as you attempt to confirm every cookie. The page should only ask to confirm the first cookie, and subsequent ones given the case above.

Reproducible: Always

Steps to Reproduce:
1. Load a website with multiple cookies (example given)

Actual Results:  
Firefox requests confirmation for every cookie on the site at the same time

Expected Results:  
Firefox should only request confirmation for one cookie at a time (like Firefox 2 did) - at most, it should request confirmation for only the first instance of every site cookie.
This has just occurred to me on http://www.it247.com/ too - for the site "media.it247.com" I got around 40 confirmations for ASP.NET "session" cookies, which was extremely inconvenient.
Severity: normal → major
This is a duplicate of:
https://bugzilla.mozilla.org/show_bug.cgi?id=468888

Note that it mostly happens (to me) when images or other static/CDN/server-farm contents are being loaded, with cookies being sent for the static/CDN/server-farm content.
Well, I hesitate to confirm but I can't find a bug that covers this properly -  bug 420155 and bug 420512 are more specific issues, but basically this option is rather useless as it is and needs an overhaul.  See also https://wiki.mozilla.org/Cookies:prompting_ui
Status: UNCONFIRMED → NEW
Component: General → Preferences
Ever confirmed: true
OS: Linux → All
QA Contact: general → preferences
Hardware: PC → All
Flags: blocking-firefox3.1?
Perhaps it would be nice UI if the pages rendered with something not unlike the "image missing" place-holder for any content, and a list of cookies that are blocking it, with some options to deal with the cookies from that perspective.

This could be an addition to or replacement for the infobar proposed here:
https://wiki.mozilla.org/Cookies:prompting_ui

It also really does need to allow the user to wildcard accept by sub-domains, in today's world of CDN and sub-domain sharded server farms, imho.

E.g., allow the user to accept cookies from *.yahoo.com and stop bugging them about all the sub-domains for what they may perceive as a legitimate site/need.

A wild-card to block "ad.*" and "ads.*" would also save many users a lot of clicking. Note that the match is on a whole word/token. I.e., bad.examples.com would not match "ad*." but ad.example.com would.

I really love firefox and the control it gives me, and as a developer, I just leave this "ask every time" on so I can see what cookies my sites send, and what other sites are doing, as well as to give some degree of control over sites I suspect/presume are sharing my info willy-nilly.
In regards to Richard Lynch's comment, I would submit that the final two paragraphs SOLIDLY fall within AdBlock Plus territory, and not the core functionality of Firefox.  This extension already does this type of functionality VERY well, and so it shouldn't be "Rolled in" to the core functionality.

As for the "placeholder" functionality, I think that's impractical, as many pages don't even BEGIN to load until cookies are accepted, and not just a few images.  The infobar solution seems cleanest and most consistent to me, though I do agree that some type of sub-domain whitelist should also be allowed, rather than every incarnation of a site.  This is especially important with places like ImageShack, Photobucket, and a few others that literally have server##.domain.com with EVERY ONE needing to be put on the white/black-list, never knowing exactly which one you'll get each time.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Component: Preferences → Networking: Cookies
Flags: blocking-firefox3.1-
Product: Firefox → Core
QA Contact: preferences → networking.cookies
Version: unspecified → Trunk
I am getting this same problem with 3.6.8.  I have noticed it a lot lately on sites that set loads of cookies - shopping sites, oprah.com, cnn.com, and others.
Also happens in 3.6.10 when going to www.apple.com (multiple cookie dialogs for images.apple.com).  Adding myself to cc list.
I would guess this has been fixed in newer versions of Firefox, or that there will be bugs related to those versions (this bug is 4 years old now)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
4 years old and still hasn't been fixed...no clue why you marked this resolved.
I've marked this particular bug as RESOLVED WONTFIX because it's 4 years old, and I don't think Mozilla are going to fix a bug in Firefox 3.

There are newer bugs targeted at newer releases - it doesn't help anyone if this bug remains open.
So, we don't open duplicates because a report already exists...then you close it without fixing because its old.   Thats moronic.
This bug has had more recent activity so marking this is a duplicate of that.

I'm not a Firefox developer so I can't fix this.
Resolution: WONTFIX → DUPLICATE
Marking bug 434971 as duplicate 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 'major/minor' field is not really used at Mozilla (mostly because anyone can set it :)  

In some cases there have been issues with bugs with lots of votes being marked DUPE to a bug w/o as many votes, but the target bug this time actually has more votes than this.

Generally we try to fix the original bug rather than open new ones and DUPE them, but now that it's done, I hope we can move on to fixing the bug soon and hopefully not spending more time arguing about its Bugzilla status.
You need to log in before you can comment on or make changes to this bug.