Extremely Long URLs Cause Problematic Behavior in history dropdown



18 years ago
5 months ago


(Reporter: dbrodale, Unassigned)


Windows NT

Firefox Tracking Flags

(Not tracked)





18 years ago
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.


dbrodale@bigfootinteractive.com - 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?


Comment 3

18 years ago
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?

Comment 4

18 years ago
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

Comment 7

18 years ago
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

Comment 9

18 years ago
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. 
Keywords: nsbeta1-

Comment 11

18 years ago
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


17 years ago
Target Milestone: mozilla1.0.1 → Future

Comment 13

15 years ago
worksforme on 1.7b, url length 2077.
I think that 
is not more, too.

Comment 14

15 years ago
waterson left the building
Assignee: waterson → nobody
QA Contact: claudius → core.rdf


5 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.