Firefox cookie interface is not reversible; the interface actions to undo are not the reverse of the "do" steps.




8 years ago
7 years ago


(Reporter: kop, Unassigned)


Firefox Tracking Flags

(Not tracked)




8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110323 Iceweasel/3.5.16 (like Firefox/3.5.16)
Build Identifier: Mozilla Firefox 4.2a1pre (output of "firefox -v", downloaded about Thu Mar 24 22:12:34 UTC 2011 from


When I click a series of checkboxes I expect that when I want to
return the configuration to it's original state that I should go
back to the interface and uncheck the boxes I checked.  I do not
expect the interface to change when I come back to the configuration
interface to reverse the changes I made, but the firefox's cookie
preference settings do just this.  If I go to the cookie page and 
choose "Use custom settings for history" everything works as expected,
unless you check all of:

 Remember my browsing history for at least X days
 Remember download history
 Remember search and form history
 Accept cookies from sites
 Accept third-party cookies

but check none of the remaining checkboxs.  In this case the next time
you go back to your cookie preferences the interface looks completely
different.  There are no checkboxes and in their place there's a string
that looks (something) like: 

 "Firefox will remember your browsing, download, form and search
  history and keep cookies from Web sites you visit.
  You may want to _clear_your_recent_history_, or _remove_individual_cookies_."

(Exact text from firefox 3.5.  Sorry, I didn't bother to copy the text
from the 4.2prealpha build I re-tested on.)

To restore the checkboxes and undo the configuration changes you just
made you must re-select "Use custom settings for history" from the menu.

What seems to be happening is that when the set of checkboxes 
you chose matches the default behaviour for "Remember history" 
then the cookie preferences interface changes and switches
the menu and the interface back to "Remember history" when you 
come back to the pref box.  There is no way to know this is going
to happen ahead of time and no way to know exactly what the "Remember
history" menu preferences really are.

What should happen instead is that the interface should remember that
you chose "Use custom settings for history" and retain that interface
until you chose another setting from the menu.  This will avoid surprises
when you come back to the interface and find you can't, seemingly,
undo the changes you made because the checkboxes you checked no
longer exist in the interface.

Reproducible: Always

Steps to Reproduce:
See above.
Actual Results:  
Got a new user interface.

Expected Results:  
I would be able to use the interface in which I made the changes to undo the changes.

Old HCI axiom: If the user can't find it, it isn't there.  You're
also violating the principle of least surprise.  I took an hour
to notice that the menu had changed back to one of the defaults.
Meanwhile I was concerned of the security implications of allowing
cookies globally.

This is the second time I've spent non-trivial amounts of time before
I noticed that the drop down menu had changed and I was no longer
in the "Use custom settings for history" interface.  It happened to
me once before -- I think many years ago.  (Not that it matters,
but the problem is made worse because it's a drop-down menu and 
you can't see at a glance all the available choices.)

If it's happening here it's probably happening elsewhere in firefox.
Just because the custom configuration happens to be the same as one of the 
menu options does not mean it's ok to switch the interface.  When would it be ok?  Should it happen instantly, after a few seconds delay, after you close
the interface dialog/window and re-open it, after program restart?  If
you are going to change the interface it's best that it changes as soon as
possible, say after a few seconds, so at least the user has some feedback.
(The user could always then immediately go back to the menu and choose
"custom" if he wants to make further edits.)


Thanks for your time and the software.

See also Debian bug #619509:

Comment 1

8 years ago
FYI.  This problem did not exist in Firefox 3.0.6.

Comment 2

8 years ago
Karl, thank you for the report. Can you please provide clearer steps to reproduce the issue that you are encountering in order to verify it also?

Comment 3

8 years ago

Start Firefox for the very first time without any prior preferences.  You may need to delete or move your ~/.mozilla directory.


History: Firefox will:  Use custom preferences for history

Uncheck all checkboxes.  
Check "Remember my browsing history for at least...."
Check "Remember download history"
Check "Remember search and form history"

Close preference dialog.

Open preference dialog.  Note that the dialog is as you left it
when you closed the dialog.

Check "Accept cookies from sites"
Check "Accept third-party cookies"
Keep until: "they expire"

Close preferences dialog.

Open preferences dialog.  Note that dialog has changed, the checkboxes
no longer appear on the screen.  You cannot uncheck them and return
your preferences to the state before last edit, instead you must
first change the "History: Firefox will:" menu.

I did this on 3.5, but had previously done it on 4.2a1pre and will
re-download and re-run the test on that to be sure the of reporting
the exact text of the checkbox labels if you're still having problems
reproducing the issue.

Comment 4

8 years ago
Now that I clearly understand the issue that you have reported I was able to follow your steps and reproduce the testing conditions.

In my opinion this the intended behavior of the browser. Once all the check-boxes are selected, then, the dialogue automatically changes to "Remember history".

The exact same behavior can be observed in Firefox 3.6.16 and 3.5.18.

Comment 5

8 years ago
Yes.  It is clearly intended behavior.  But that just means it's a bad flaw in the design of the interface, for the reasons described in the original bug report.  See particularly the last paragraph.  And yes, it's a longstanding problem that's was introduced at least as far back as 3.5.

My bug report describes a design flaw, not a programming bug.  If you're not going to fix it yourself please confirm that the described behavior exists and pass it on to someone responsible for interface design to decide whether they consider it a problem that needs fixing.

>In my opinion this the intended behavior of the browser. Once all the
>check-boxes are selected, then, the dialogue automatically changes to "Remember

yep, this is by design
Last Resolved: 8 years ago
Resolution: --- → INVALID

Comment 7

7 years ago
(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #6)
> >In my opinion this the intended behavior of the browser. Once all the
> >check-boxes are selected, then, the dialogue automatically changes to "Remember
> >history".
> yep, this is by design

This is actually a very serious bug.  I cannot set Iceweasel to NOT accept cookies and close the dialogue without it defaulting back to Remember History.  If I want to browse without accepting cookies, I have to leave the dialogue open for the entire browsing session. 

I should be able to close the dialogue and if I have to go to a site where I need cookies, the dialogue should come back with my settings not accepting cookies until I change it.  Not with the browser defaulting itself to settings I don't want.

Comment 8

7 years ago
> stephen <> changed:

> This is actually a very serious bug. 

It's not _very_ serious, because you can make firefox/iceweasel
behave as desired -- it's just extremely confusing as to how
to do so.  (You don't _have_ to leave the dialog open.
You can close it and then use the menu to choose 
'custom settings' and then revert your changes
to your regular settings.)

After quite some conversation with the bug triage
people for firefox, and the user interface design
mailing list, it's clear that the only way this is
going to get fixed is if somebody submits a patch
and advocates for it's application with the developers.
The bug triage group says it's not a bug because it's
operating as the programmers intended, and the
user interface design list does not care enough
to advocate with the bug group to get it classified
as a bug.  So, no developer is going to see this
as an outstanding bug and it's left to somebody
who cares to push code that fixes the problem.

Comment 9

7 years ago
(I would agree that it's a very serious bug in the user interface _design_.)
You need to log in before you can comment on or make changes to this bug.