Open Bug 56192 Opened 24 years ago Updated 5 years ago

Extremely Long URLs Cause Problematic Behavior in history dropdown


(Core Graveyard :: RDF, defect, P3)

Windows NT


(Not tracked)



(Reporter: dbrodale, Unassigned)




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 

(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 

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> - 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?

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 

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:

Since I do not use the nightlies, I do not know whether this remains a problem 
in the latest builds.

(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 

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.

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.
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
 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. 
Keywords: nsbeta1-
Probably a bug in the RDF parser.
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 
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → Future
worksforme on 1.7b, url length 2077.
I think that 
is not more, too.
waterson left the building
Assignee: waterson → nobody
QA Contact: claudius → core.rdf
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.