i suspect this is a case where we aren't passing a nsIHttpChannel into the cookie service's SetCookieString method.
hrmmm, yeah. should we dupe this to 180983?
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 257716 has been marked as a duplicate of this bug. ***
Bug 149115 looks very similiar. There is a log for osnews.com attached.
This is interesting. I've never been a big believer in parent domain-based blocking, because the third party site could be entered as a subdomain (for example, doubleclick.mozilla.org). I'd be interested in hearing ideas on how severe a problem this might be.
*** Bug 262656 has been marked as a duplicate of this bug. ***
*** Bug 264011 has been marked as a duplicate of this bug. ***
*** Bug 290256 has been marked as a duplicate of this bug. ***
*** Bug 299160 has been marked as a duplicate of this bug. ***
I'm all for implementing third-party cookie blocking properly in Firefox. -> default owner
Assignee: darin → nobody
*** Bug 330277 has been marked as a duplicate of this bug. ***
If this bug cannot be readily fixed, then bug #257288 should be fixed to make locking cookie.txt as read-only a more effective (but partial) work-around. Re comment #12: This is a core bug, not a Firefox bug. Fixing this would not only fix it for Fireforx; it would also fix it for SeaMonkey once a new version of that uses the fixed Gecko core.
dwitte, did you happen to fix this as part of bug 421494?
yep, i'll bet a stack of pancakes that this is fixed. i don't have time to check, but if someone can verify that'd be great.
I will close his based on comment 18
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.