Closed Bug 644807 Opened 14 years ago Closed 14 years ago

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

Categories

(Firefox :: Settings UI, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: kop, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) 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 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-4.2a1pre.en-US.linux-i686.tar.bz2) Hi, 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.) /rant Thanks for your time and the software. See also Debian bug #619509: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619509
FYI. This problem did not exist in Firefox 3.0.6.
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?
Ok.... Start Firefox for the very first time without any prior preferences. You may need to delete or move your ~/.mozilla directory. Edit->Preferences->Privacy 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.
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.
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. Thanks.
>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
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
(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.
> stephen <esembe8@sbcglobal.net> 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.
(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.