Closed Bug 192176 Opened 17 years ago Closed 4 years ago
Statusbar-based cookie controls
sounds almost similar to the way popup blocking works. say you get a cookie icon in the status bar when cookies are blocked. then you could say click on that to inspect the cookies that the site wanted to set. you could imagine manipulating your cookie blocking rules from that dialog. or something like that. -> future
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Just have to watch out for sites that go into an infinite redirect loop when cookies are blocked...
alphawolf: I tried to make the summary more searchable... let me know if this was not what you intended.
QA Contact: tever → benc
Summary: New, easy to use approach to cookie management and privacy. → Toolbar based cookie controls
That sounds like a good idea. Or there could be a checkmark like toggle in the cookie control properties to switch between keep for session, or block completely. Although the UI they have in mind isn't quite as good as the one I have in mind IMHO :)
*** This bug has been marked as a duplicate of 75915 ***
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
whitelist support is effectively in thanks to bug 184059. This is really a separate concept from a whitelist, although it would logically be dependent on whitelist support. Reopening based on that, I expect to have a patch for this in time for 1.6a.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Okay, no patch until the backend gives a sane cookie notification that includes the site for the blocked cookie. dwitte said he needs to do this, but he doesn't know when it'll be done. As a note, 217199 is the Firebird equivalent since the XUL work won't quite be the same. I will do both patches once the backend is implemented.
-> me -> removing dependency -> depends on 221185
we need an icon, someone gave me one a while back, but I think I lost it
Idealy, the dialog should provide a way to actually accept the cookie that was already recieved, not just add the site to the white/blacklist, and then having to reload to actually have it set. This is also true for the popup notification. Idealy you should be able to click 'show' instead of allow, to see what it tried to pop up, without having to accept all future popups from the domain, or reload to see the popup, then enter prefs are remove the site if it's just an ad. Is there a technical reason why this can't be done for cookies? Is the cookie code syncronous in that say, img=/foo.png may depend on the cookie from '/' already being set? Regardless, Mike's current work would be a great start. I know accepting the cookie in "real-time" would be (much?) more difficult to implement, I just want to make sure everyone has their eyes on the right goal, even if it's another year away.
yes. that's entirely a different bug, and entirely a different goal.
Well, couldn't we just "session-only" every cookie thats received unless told otherwise by the user? In this case, the website can't malfunction due to a missing cookie, since all cookies *will* be present, and at the same time, accomplishing our goal. Also, to prevent the website from detecting that we are doing this (in case the website malfunctions because of any expiration date anomalies,) store the cookies exactly as the website specifies (e.g, expiration date remains intact,) only we don't actually treat the cookie as the website instructs, by deleting it at the end of the session.
another separate bug, see bug 216743
new files: mozilla/extensions/cookies/locale/en-US/cookie/cookieBlockedList.dtd mozilla/extensions/cookie/content/cookie/cookieBlockedList.xul mozilla/extensions/cookie/content/cookie/cookieBlockedList.js and copy the png to both of mozilla/themes/classic/skin/classic/navigator/icons/cookie-blocked.png and mozilla/themes/modern/skin/modern/navigator/icons/cookie-blocked.png this icon sucks, we need artwork :)
This is a bit tricky because what you really want is to toggle the cookies for all the sites on the *page*, not necessarily the site in the URL bar. This can be different because images and other included content may come from different sites and have different cookies. Often times ads on a page will have their own cookies that you want to block, and while you're on 'www.asite.com' the cookie you want to allow is from 'asite.com' or 'login.asite.com'. Ideally, IMHO, the current statusbar icon for 'view cookie controls' would bring up the list of cookies and sites associated with the current page.
And what do you think the screenshot shows?
Is this still a moz1.6/fb0.8 contender? This could be another killer feature for power users. I'm happy to test the heck out of it, but incapable of building. Is there time to get a review and checkin for the beta timeframe?
this isn't ready, the notifications code isn't quite giving me enough info to do this effectively. 1.7/0.9 is my expected target
Scott, I believe we could easily solve that problem by allowing the user to enable *.domain.com wildcards. In fact, I think the current cookie whitelisting feature could use a wildcard option as well...
cookie whitelisting already works that way.
*** Bug 203586 has been marked as a duplicate of this bug. ***
Not going to be working on any Seamonkey UI bugs for the foreseeable future. You can filter on "danlikesgoats" to delete this spam.
Assignee: mconnor → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
Target Milestone: Future → ---
Status: NEW → RESOLVED
Closed: 17 years ago → 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.