160123 - Locked out of site due to poor cookie management

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[hacker formerly known as [e-mail]]

It is very easy to lock yourself out of any site which requires cookies to
function.  If you click answer "No" when asked if you want to enable cookies for
a particular site and "remember" is selected, then there's no way to re-enable
cookies for that site (unless you know about cookperm.txt).  At first I was
thinking about filing an RFE for a cookie manager but that's overkill for this
particular problem.  A pair of menu items "Block cookies from this site" or
"Unblock cookies from this site" would suffice for working around the lockout
issue.  This would fit nicely if there were a "Tools" menu (hint, hint).

Comment 1

[saari (gone)]

yeah, that'd be bad. Does toggling to enable all cookies and then back to
selective mode work?

Comment 2

[hacker formerly known as [e-mail]]

No, toggling the avaiable cookie options does not help.  Once the site is marked
as denied, there's no way to accept cookies again short of closing the browser,
modifying cookperm.txt and restarting.  I suspect that we have the same problem
if we wanted to start denying cookies to a single site that we've already
accepted cookies from as well.

Comment 3

[hacker formerly known as [e-mail]]

So, I was looking at the code and I think I know what I want to do here. 
Whenever a page is loaded, the Block/Unblock Cookie menu items should be grey'd
out appropriately and whenever they are clicked, the message is passed down to
the BrowserWindowController object which will make the appropriate cookie
manager calls.  I'm still trying to get my head wrapped around the code but it
doesn't look like CHBrowserView's onLoadingCompleted function is ever getting
called.  Either that or I haven't figured out how to get my printf()s & NSLog()s
to show up in a non-debug build. :-/  Is onLoadingCompleted the proper function
that should be called whenever a page is finished loading?

Comment 4

[hacker formerly known as [e-mail]]

Attachment: Hook up cookie block/unblock menu items

In addition to that patch, there are changes that are required to be made to at
least MainMenu.nib.

For MainMenu.nib, you will need to add a new menu, "Tools" between "Bookmarks"
& "Window".  The submenu will contain 2 items "Block Cookies from this Site" &
"Unblock Cookies from this Site".  The names need to be exact as the code uses
them to find the menus later when it toggles them on and off.  When you read
the modified MainController.h file into the MainMenu project, it should add the
following outlets and action items to the MainController class:

mBlockCookiesMenuItem
mUnblockCookiesMenuItem
mToolsMenu

blockCookies:
unblockCookies:

Hook them up as appropriate.

Comment 5

[Mike Pinkerton (not reading bugmail)]

there has got to be a better place to put these commands other than a Tools menu
with only 2 items.

Comment 6

[hacker formerly known as [e-mail]]

Attachment: single menuitem under View

Not sure if this counts as "better" but it puts a single menuitem under "View"
for toggling blocking.	The same caveats apply for making MainNib changes but
just a single outlet (mToggleCookieBlockingMenuItem) & a single action item
(toggleCookieBlocking) are required to be hooked up.  I also switched to using
menu tags so the "View" menu should be tagged as 3 and the toggle menu item
should be tagged as 13.

Comment 7

[Garret Huntress]

Maybe this should go under an RFE, but with just a "toggle Cookie Blocking"
menu, there should be some sort of visual cue as to the state of cookies in the
current window.  A little chocolate chip cookie incon in the lower right corner
of the window if the site has cookies that chimera is accepting?  Chocolate
chip cookie with a big red circle-cross if chimera is blocking cookies?

Thoughts?

Comment 8

[hacker formerly known as [e-mail]]

Separate RFE please.  Cookies are not so vital to the end user that they need a
visual representation of when they are being blocked, especially, since they'll
only be blocked if the user flips a pref for it.   Rumor has it that most users
don't even know what a cookie is much less why they'll have this pizza icon on
their browser.

Comment 9

[hacker formerly known as [e-mail]]

Attachment: everybody to the front of the bus

Comment 10

[Winnie Lam]

regarding the original problem.  would the "clear stored cookies" button in the
privacy pref panel get rid of this problem?

Comment 11

[hacker formerly known as [e-mail]]

Nope.  That button only clears out the stored cookies not the stored cookie
permissions.  And I'd hate to loose all of my stored cookies *and* blocked ad
sites just because I changed my mind about how to handle a single site.

Comment 12

[Greg K.]

*** Bug 161120 has been marked as a duplicate of this bug. ***

Comment 13

[Barbara Ballard]

I guess bug 161120 was marked as a duplicate of this one.  If this is the case,
I need to add my recommendations to this bug.  Specifically: 

1.  Preferences option:  Clear all cookies upon exit.  (high priority)  
2.  Preferences UI widget:  list all cookies and allow individual managment.
(high priority)   
3.  Add "always block" and "always accept" lists, which are independent of
automatically-managed cookies.  (low priority, since few browsers have this.)   
4.  When above done, will need a Cookies preferences pane. 


item 2 addresses the issues in this bug (preferences item instead of menubar
item).  the rest seem unrelated to me.  But I'm new here.

Comment 14

[hacker formerly known as [e-mail]]

I don't see why bug 161120 was marked as a dupe either as I already stated that
a full blown cookie manager was overkill for this particular problem.  Since,
afaik, we aren't leaning towards any manager as a solution for this bug, bug
161120 should be reopened.

Winnie, I thought about your suggestion again and while the "clear stored
cookies" button would be inappropriate for clearing cookie permissions, a "clear
blocked site permissions" button may be a quick-n-dirty(-n-less-visible)
solution to the problem.  I don't like the idea of loosing the per-site
granularity of the current patch but the button would serve the purpose of
resetting all of the site permissions and getting the user out of this bind.

Comment 15

[hacker formerly known as [e-mail]]

Attachment: Add 'clear blocked sites' button to prefs

This patch also requires the permission manager fix from bug 161952.

Comment 16

[Jørgen Nørgaard]

A perhaps related problem?


On http://www.versiontracker.com/moreinfo.fcgi?id=14326&db=mac I am unable to
login (unchecked 'save password'). Could be something with matching real path
against the cookie path?

I am able to login using Mozilla 1.1 (final)

Build: 2002090505

Comment 17

[Mike Pinkerton (not reading bugmail)]

*** Bug 161120 has been marked as a duplicate of this bug. ***

Comment 18

[Mike Pinkerton (not reading bugmail)]

added a panel to edit these in the privacy pref pane rather than the
block/unblock menu item (since a page generally has cookies from many other ad
sites, "unblock from this site" isn't all that useful).

the patch was appreicated though, it showed me how to do it ;)

(FWIW, nsIPermissionManager needs to be taken out back and shot. it's if not the
most terrible API in mozilla, it's close).

Comment 19

[Thomas F. O'Connell]

Am I imagining things, or did the Cookie Manager interface change in the
nightlies. As of 0.6, I could have sworn there was actually an Edit Cookies
interface somewhere that actually let you review individual cookies. Was I wrong
about this? If so, shouldn't one of the bugs that became a dupe of this be
re-opened?