Clear History button should be disabled if all entries have been deleted



18 years ago
13 years ago


(Reporter: bugzilla, Assigned: bugzilla)




Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)



18 years ago
Build ID: new trunk

Steps to Reproduce:

(1) Open the Preferences window
(2) Navigator > History
(3) Press the Clear History button

The button should be disabled any time there are no items in History (e.g. if 
you just haven't gone anywhere yet, if you just pressed Clear History, or if 
you manually deleted the History items from the window).  This would also be 
consistent with the "Clear Location Bar" button right below it, which is 
disabled when there are no entries in the Location bar history that can be 
hrm, should this go to Preferences or History? taking choice number #1... change
if needed, tho'!
Component: XP Apps: GUI Features → Preferences
Keywords: correctness
nav triage: not a beta stopper. 
Keywords: nsbeta1 → nsbeta1-

Comment 3

18 years ago
Created attachment 26370 [details] [diff] [review]
patch to get clear history button disabled

Comment 4

18 years ago
Created attachment 26373 [details] [diff] [review]
changing button.disabled = SHistory.count == 0; to button.disabled = true; after blake's comments

Comment 5

18 years ago
cc'ing alec for r=/sr=
Keywords: patch, review


18 years ago
OS: Windows 98 → All

Comment 6

18 years ago
I applied and tried the patch, and it disables as it should when I click the
button. But when I reopen the prefs, the button is still enabled.

Comment 7

18 years ago
don't confuse session and global history - session history is per-window... this
button deals with clearing global history, as I understand it.

I also don't like the idea of accessing specific UI elements in prefutilities.js
- prefutilities means that it could be used across pages. 

Comment 8

18 years ago
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future

Comment 9

18 years ago
walk84, can you update this patch?
Assignee: ben → walk84


17 years ago
Keywords: polish

Comment 10

17 years ago
Can anyone comment on how far in the future this bug is likely to be pushed?

Comment 11

17 years ago
*** Bug 110443 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
-> blake
Assignee: walk84 → blaker

Comment 13

17 years ago
Created attachment 67694 [details] [diff] [review]
Attachment #26370 - Attachment is obsolete: true
Attachment #26373 - Attachment is obsolete: true

Comment 14

17 years ago
Unfortunately, since pages can be hidden, it can look as if your history is
empty when it's not.

I don't really know if we want to fix this bug.  What is the benefit?  The risk
is that users won't understand why the button is disabled, because they won't
check and see that their history is empty first.  IE doesn't bother with this
subtle notification.

But I think nsIBrowserHistory could use a count attribute anyway....alec, can
you look at this?

Comment 15

17 years ago
If, as Blake says, "Unfortunately, since pages can be hidden, it can look as if
your history is empty when it's not," then would it not be even _more_ useful
for the user to be able to to tell (by the enabled/disabled state of the button)
when they have truly cleared their history?

The benefit, as Blake himself pointed out when he logged the bug, is that the
button would then be consistent with the "Clear Location Bar" button, and it
would give the user feedback that pressing the button had done something.

IMHO, good UI design calls for this feature.
Unfuturing (since the future milestone was set by a different assignee anyway).

Could we get a UI call on this bug?  Are we doing it or not?  If we're doing it,
let's not let the patch rot too much.  If we're not, let's wontfix this.
Target Milestone: Future → ---

Comment 17

17 years ago
I think nsIBrowserHistory could use a count attribute even if we don't do this. 
just needs sr from alec.

Comment 18

17 years ago
Comment on attachment 67694 [details] [diff] [review]

sr=alecf on the whole thing.. its worth being slightly confusing for "hidden"
Attachment #67694 - Flags: superreview+

Comment 19

17 years ago
oh, and on a side note - currently the only way a page can be "hidden" is by a
HTTP 304 redirect - which means that they're going to be redirected to ANOTHER
page which will probably end up in the history.
so it's VERY unlikely that people are going to have a history that looks empty,
but actually has nothing but hidden entries...

Comment 20

17 years ago
Well, actually, I seemed to have more hidden pages than I expected even after
clearing my history and visiting a few sites that didn't seem to have redirects.
 I wonder if some pages are getting hidden incorrectly...

Comment 21

17 years ago
I'm confused - how do you know you had hidden pages?

Also, redirects very often come in the form of banner ads - more and more often
I'm seeing sites that have an IFRAME with SRC=""
which immediately redirects to something like ""
- so if the sites in question have any kind of ad, then there's your hidden page.

Comment 22

17 years ago
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 23

17 years ago
Blake... when I click clear history, the button doesn't disable after it deletes
everything. If I do 'OK', then come back in to prefs, it's disabled.

It's important to disable it actively, for user feedback. Location bar history
works like this. Going to reopen.
Resolution: FIXED → ---

Comment 24

17 years ago
Yep, thanks. I noticed that last night. Fixed.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED


17 years ago
Keywords: mozilla1.0, oeone
the Clear History (and also the Clear Location Bar) button now become disabled
after clicking. vrfy'd fixed using 2002.03.13 comm bits on linux rh7.2, win2k
and mac 10.1.3.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.