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)
Firefox
Settings UI
Tracking
()
RESOLVED
INVALID
People
(Reporter: standsongrace, Unassigned)
References
Details
(Whiteboard: [needs new patch])
Attachments
(1 file, 1 obsolete file)
2.75 KB,
patch
|
Gavin
:
review-
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.0?
Comment 2•20 years ago
|
||
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.
Updated•20 years ago
|
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?
Comment 4•20 years ago
|
||
dupe of bug 102519 ?
Comment 5•20 years ago
|
||
*** This bug has been marked as a duplicate of 242207 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Comment 6•20 years ago
|
||
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 → ---
Updated•20 years ago
|
Summary: If history length too large, no history is kept → If history length (days) too large, no history is kept
Comment 7•19 years ago
|
||
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
Reporter | ||
Comment 8•19 years ago
|
||
Can someone confirm this on a recent build?
Comment 9•19 years ago
|
||
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.
Comment 10•19 years ago
|
||
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
Updated•19 years ago
|
Assignee: firefox → nobody
QA Contact: mozilla → history
Comment 11•18 years ago
|
||
dupe of bug 202051?
Comment 12•18 years ago
|
||
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.
Comment 13•18 years ago
|
||
*** Bug 362463 has been marked as a duplicate of this bug. ***
Comment 16•17 years ago
|
||
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
Reporter | ||
Updated•17 years ago
|
OS: Windows ME → All
Hardware: PC → All
Comment 17•17 years ago
|
||
Not sure what the minimum/maximum values should be on these numberboxes, I just used a value based on the existing size attribute.
Updated•17 years ago
|
Target Milestone: --- → Firefox 3
Comment 20•17 years ago
|
||
Attachment #261686 -
Attachment is obsolete: true
Attachment #281807 -
Flags: review?(gavin.sharp)
Attachment #261686 -
Flags: review?(gavin.sharp)
Comment 21•17 years ago
|
||
(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>
Comment 22•17 years ago
|
||
(In reply to comment #21) > The value getter takes care of that: Err, setter. And the preferences stuff should interact only with the value.
Comment 23•16 years ago
|
||
(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
Updated•16 years ago
|
Assignee: enndeakin → dao
Updated•16 years ago
|
Assignee: dao → nobody
Status: ASSIGNED → NEW
Updated•16 years ago
|
Target Milestone: Firefox 3 → ---
Comment 24•16 years ago
|
||
Gavin - plan on reviewing this anytime soon?
Component: Bookmarks & History → Preferences
QA Contact: bookmarks → preferences
Version: unspecified → Trunk
Comment 25•16 years ago
|
||
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-
Updated•16 years ago
|
Whiteboard: [has patch] [needs review gavin] → [needs new patch]
Comment 26•13 years ago
|
||
I think this bug is no longer relevant/valid?
Comment 27•13 years ago
|
||
yeah
Status: NEW → RESOLVED
Closed: 20 years ago → 13 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•