Closed Bug 245421 Opened 20 years ago Closed 13 years ago

If history length (days) too large, no history is kept

Categories

(Firefox :: Settings UI, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: standsongrace, Unassigned)

References

Details

(Whiteboard: [needs new patch])

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

If you set the history length to a very high number, Firefox acts as if you set
it to 0.

Reproducible: Always
Steps to Reproduce:
1. Set Options->Privacy->History->"Remember visited pages for the last ... days"
to 999999

Actual Results:  
History is not remembered at all (as if you had set it to 0).

Expected Results:  
Firefox should either remember the history for whatever value is entered, or
limit the range of enterable values.
Flags: blocking1.0?
Reporter,
Can you confirm this on a recent nightly build? 
Setting "Remember visited pages for the last n days" to a big number to causes
trouble on Firefox 1.0PR. I set it to 9999999999999999999999, which caused
history to not work. When I opened the Oprions dialog again, the number was
-1304428544.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
After entering 2^31 the number became -2^31, so it seems this pref is a signed
32bit integer in both Firefox 0.10.1 and Mozilla 1.8a4. Is this integer overflow
a security problem?

*** This bug has been marked as a duplicate of 242207 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
This is not a dupe of that bug. This is about the "keep history for x days"
number being improperly handled.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: If history length too large, no history is kept → If history length (days) too large, no history is kept
20050205 As a newbee I almost gave up on Firefox until I realised that the value
I flippantly inserted in no of days (4500) could be the cause of not being able
to have any history. After hours of searching for help unsuccessfully I wrote a
mail to let someone know at bugzilla and then on reviewing my mail realized that
the days number may have been the cause. Placed it at 45 and rebooted and since
then I am able to work with Firefox. 
Had I not found my solution I would have left FF as useless and returned to
Safari. Now I hope to contribute to what I see as "power to the people!"
I found this bug report and hence can confirm it on a mac.
This is an ancient posting - 8 months old 20040602! Hope you can sort it and
upgrade its importance - you almost lost one supporter.
using mac os10.2.8
Can someone confirm this on a recent build?
In Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050912 Firefox/1.4
ID:2005091205, when I tried to set it to 3000000000000, it was automatically set
to 2112827392 (2^31?). I tried again, and it was set to -1294967296. The latter
happens repeatedly, even after restarting Firefox. Restarting Firefox with it
set to that, history is cleared. (It seems old history entries being cleared out
is only done when Firefox is started, oddly enough. Well, not a hugely important
thing, and there's better performance if it's only done then. And I suppose it
allows people to not lose their history unless they restart if they accidentally
change it. But I digress.) So it still exists.

Someone should set OS and Hardware to All.
Kenneth, we thank you. I thank you.

But the things, at least from what I've seen, assigned to Blake Ross don't get very many replies/responses to them. I'm just saying! I know he's probably busy and all but it always seems if a bug is worth enough, or maybe a certain characteristic I'm overlooking, it goes to Blake. And I'm not too keen on his bug fixing prowness but I think he's been apart of fixing some major bugs back in the day but lately... Sorry, Blake. You just never really stood out for one reason or another. But certainly if you can help me, jog my memory, I'd be obliged. Otherwise, move to be reassigned to someone less "busy"?

On harder thought, I do remember a time when you were getting all the unassigned bugs b/c no one could handle them. Please tell me that's not the case? And I also believe you were getting a lot of the smoketest/blocker bugs last summer or played some role there.

I see Gavin, Asa, Peter V. & Asquella are all watching this. Anybody care to take over? Though I personally can't say I've seen this symptom. It does make me wonder does Firefox have a set, defined limit of days to keep history? And believe me when I say the more the better, b/c I like archiving my history but I couldn't produce enough browses even in, dare I say, 5 years to topple 1 GB in history which I believe is accounting for the wipe. FF might be thinking ahead based on a default time & size maximium [not readily accessible for the user to know what that is; nothing close in about:config] that could be acting prematurely even though none of the requirements HAVE actually been come to be met.

But I'm not familiar with FF's history anymore. Is it still complied using mork? B/c I remember talks about compressing space by using it but carrying an awful price tag as being virtually impossbile to parse. So with that in mind, does FF's history.dat have a natural cut off point in size to keep from being unrealistically large? As too large a history.dat could & will prove to be unmanagable once is it met. For me this problem is relative with the bug below. They have to be dependant on each other.

Mork (http://www.erys.org/resume/netscape/mork/what.html) provided courtesy of Martijn Coppoolse https://bugzilla.mozilla.org/show_bug.cgi?id=241438#c26
Assignee: firefox → nobody
QA Contact: mozilla → history
dupe of bug 202051?
At least one problem is the expiration code. If you have more than ~50K days (possibly 24K, I'm not sure about signedness), the computation will overflow since the number of seconds of expiration must fit into an unsigned integer: 

  PRTime expirationDate;
  PRInt64 microSecondsPerSecond, secondsInDays, microSecondsInExpireDays;
  
  LL_I2L(microSecondsPerSecond, PR_USEC_PER_SEC);
  LL_UI2L(secondsInDays, 60 * 60 * 24 * mExpireDays);
  LL_MUL(microSecondsInExpireDays, secondsInDays, microSecondsPerSecond);
  LL_SUB(expirationDate, GetNow(), microSecondsInExpireDays);

Even if you change this to 64-bit, you can overflow the 64-bits in microseconds later in the computation (we had this problem with places).

I'm not sure what happens if you put a number greater than an int in there as some people like Joonas did. Somehow this gets converted to an int, which might be the cause of some of these problems. I don't know why Kenneth's 4500 days didn't work.
*** Bug 362463 has been marked as a duplicate of this bug. ***
for firefox 3, neil suggests we fix this by using the new "number" type for the texbox.

<textbox type="number" min="1" max="20"/>

http://developer.mozilla.org/en/docs/XUL:textbox
OS: Windows ME → All
Hardware: PC → All
Not sure what the minimum/maximum values should be on these numberboxes, I just used a value based on the existing size attribute.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #261686 - Flags: review?(gavin.sharp)
Target Milestone: --- → Firefox 3
Depends on: 394426
Attachment #261686 - Attachment is obsolete: true
Attachment #281807 - Flags: review?(gavin.sharp)
Attachment #261686 - Flags: review?(gavin.sharp)
(In reply to bug 394426 comment #7)
> The only thing I was concerned about with
> the patch in bug 245421 was how it would deal with preferences that have values
> greater than the maxlength being added.

The value getter takes care of that:

> data:application/xml,<hbox xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" align="center"><textbox type="number" value="4" max="3"/></hbox>
(In reply to comment #21)
> The value getter takes care of that:

Err, setter. And the preferences stuff should interact only with the value.
(In reply to comment #20)
> Created an attachment (id=281807) [details]
> Enn's patch updated to trunk

1. why limiting 'cacheSize' too if this bug is about history only?
2. is '999' put randomly?

Whiteboard: [has patch] [needs review gavin]
Component: History → Bookmarks & History
QA Contact: history → bookmarks
Assignee: enndeakin → dao
Assignee: dao → nobody
Status: ASSIGNED → NEW
Target Milestone: Firefox 3 → ---
Gavin - plan on reviewing this anytime soon?
Component: Bookmarks & History → Preferences
QA Contact: bookmarks → preferences
Version: unspecified → Trunk
Comment on attachment 281807 [details] [diff] [review]
Enn's patch updated to trunk

> Err, setter. And the preferences stuff should interact only with the value.

Yeah, the value will be clamped on display, but the code that uses this pref would still be reading the actual pref value, which could be confusing. Perhaps we should reset the actual pref value onsyncfrompreference if it's larger than our maximum?

It looks like the actual maximum value for browser.cache.disk.capacity is 2097152 (nsCacheService's mDiskCacheCapacity is a PRInt32 in KiB, but the UI uses MiB). The max value for browser.history_expire_days is 106751991 (from nsNavHistoryExpire::GetExpirationTimeAgo, the only real user of PRInt32 mExpireDaysMax). I think we should use these actual maximums (with appropriate comments) rather than choosing arbitrary values (even if they might not make sense in practice).

I wonder whether the underlying code should deal with overflow better...
Attachment #281807 - Flags: review?(gavin.sharp) → review-
Whiteboard: [has patch] [needs review gavin] → [needs new patch]
I think this bug is no longer relevant/valid?
yeah
Status: NEW → RESOLVED
Closed: 20 years ago13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: