BuildID: 2000080712 prefs.js can only accomodate URLs of up to 1996 chars. before line: user_pref ("browser.history.last_page_visited") corrupts. lengthy URLs (uncertain threshhold, try ~2047 characters) will often generate error conditions on exit. Reproducible: Always Steps to Reproduce: (1) Enter URL of 1998+ chars. into address field (to use above URL, add (n-38) chars. after the '?' to form URL of n chars. in length); (2) Hit return; (3) Using provided URL, note page displays numerical value equal to (n-38), where n = length of entire URL. Provided sample can handle URLs of up to 8196 chars.; (4) Exit Moz; (5) Locate prefs.js file, look for line beginning w/ user_pref ("browser.history.last_page_visited" ... (~line 11) -- note that URL last entered will be truncated at character 2047 of entire line and will not end with the customary parenthesis/semicolon; (6) Start Moz; (7) JS Pref. Warning should appear: "An error occurred reading the startup configuration file [...]"; (8) Click "OK"; (9) Warning should appear: "Error in preference file (prefs.js). Default preferences will be used." Moz should handle (in all aspects) any URL that can be entered and safely transmitted. One possible solution is to openly "cap" URL length with a warning to users (e.g. Opera 4.02, which warns/prevents URLs >4094 chars. in length) who attempt URLs of lengths greater than safety threshhold. Moz can transmit >8196-char URLs well, it just can't handle pref storage of them well at all.
coudl you perhaps get a newer build? your's is pretty old
I can't reproduce this behaviour because Mozilla 2000-10-12 doesn't seem to want to write the last_url_visited pref. I've looked at the code, and it does seem that the constant 2048 is all over prefapi.c, but they check every pref and return an error if it's too long - or so it seems. There have been no checkins to this file recently. <shrug> firstname.lastname@example.org - can you shed any light on a) how to turn on use of this pref, or b) whether this still happens to you with current installer builds off the trunk? Gerv
OK, updated to latest milestone (Build ID 2000101014) and the original problem (prefs.js corrupting) has gone away, and Mozilla now seems happy with URLs of up to (possibly beyond) 8196 characters -- no random crashes on shutdown, prefs.js is no longer corrupted, as it now seems to throw things into history.dat (browser.history.last_page_visited seems to no longer exist within prefs.js). HOWEVER, I am getting odd behavior on very long URLs in the location bar drop- down box, URLs of great length are appearing within the drop-down on multiple lines, such that URLs >4096 characters are "chopped up" into units of 4096 characters or less, each resulting unit being treated as a separate (and possibly malformed) entry within the drop-down. I have posted a screenshot and some verbiage here: http://www.dungeoncrawl.org/moz/mozgoofy.html Since I do not use the nightlies, I do not know whether this remains a problem in the latest builds. HOW TO REPRODUCE: (1) Enter a URL >4096 characters (I'm using 8196 characters, but 4097 characters is sufficient to test this) into the location bar; (2) Hit return to request URL (wait for load); (3) Quit Mozilla; (4) Restart Mozilla; (5) Check the Location Bar history by pressing the downward-pointing arrow; (6) Note that the super-lengthy URL is now broken over multiple lines. Anyone else seeing this?
Just tried nightly build 2000101520, same situation.
I can't see this in 2000-10-14 :-( Any URL length is just one line. Shifting to History. Gerv
Assignee: asa → radha
Component: Browser-General → History
QA Contact: doronr → claudius
Summary: Extremely Long URLs Cause Problematic Behavior in prefs.js and/or upon exit → Extremely Long URLs Cause Problematic Behavior in history dropdown
Downgrading severity. Gerv
Severity: critical → normal
Confirming the breakup of URL into multiple lines after a restart 110204 mozilla trunk build on NT. In the future, please do not morph bugs from one issue to another (it is better for verification and regression tracking to resolve the original and file a new one). Setting bug status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The problem could be with the way RDF writes these extremely long urls in to the localstore. If you look at the urlbar menu before quitting, you see only one entry. But after restarting there are 2 entries. So, my guess is, the in-memory copy that RDF may be maintaining at runtime is OK, but at shutdown, when the entries actually get written to disk, there is a problem.
Assignee: radha → waterson
This may be a dupe of http://bugzilla.mozilla.org/show_bug.cgi?id=51363 with regard to the 4k chunking.
nav triage team: looked at this bug, it is not a beta stopper. bulk update of several such bugs.
Probably a bug in the RDF parser.
Status: NEW → ASSIGNED
Component: History: Session → RDF
Target Milestone: --- → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
worksforme on 1.7b, url length 2077. I think that browser.history.last_page_visited is not more, too.
waterson left the building
Assignee: waterson → nobody
Status: ASSIGNED → NEW
QA Contact: claudius → core.rdf
You need to log in before you can comment on or make changes to this bug.