Bogus URL's added to urlbar history will corrupt localstore.rdf

VERIFIED FIXED in mozilla0.9.6

Status

SeaMonkey
Location Bar
P4
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: John Morrison, Assigned: Joe Hewitt (gone))

Tracking

Trunk
mozilla0.9.6

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
This bug comes out of bug 96221, and addresses one thing that should be fixed
in the urlbar's handling of url history entries.

If a user were, for example, to do a 'Copy Link Location' on a link like the
one below ..

    http://www.mozilla.org

... and then paste that into the urlbar and hit Enter, then that bogus URL
will be added to the history. That URL contains two '^C' characters which are
illegal in URL's and also illegal in XML.

This is a problem because that string will be serialized to localstore.rdf
and since it is an illegal character in XML, then that file can no longer be
parsed without getting a well-formedness error. Bye, bye to the future use of
that persisted information. The next time the user starts the browser, all
the user customizations that were stored in localstore.rdf.

[And, even worse, that file is not deleted when it is corrupt, so the user
can never again persist any settings to that profile. But that's another bug
which I will file.]

This bug is about preventing that corruption. Simply, a URL should be checked
for invalid characters before adding that URL to the history. The set of
characters that MUST NOT appear in an XML file are, in hex notation:

  #x0-#x8 | #xB-#xC | #xE-#x1F

or, other words, no ASCII below 'space' except for 'tab', 'carriage return'
and 'linefeed'. See <http://www.w3.org/TR/REC-xml#charsets>. (Note also that
the ascii control characters #x00-#x1F are specifically disallowed in any 
URL, so there is no point in storing these in %nn encoded form. So maybe 
just test for any character below #x20, and don't store it if the URL has 
one of those characters).

Comment 1

17 years ago
What a sucky bug.

(That's my engineering analysis.)
(Reporter)

Comment 2

17 years ago
Define sucky.
(Reporter)

Comment 3

17 years ago
Created attachment 48991 [details] [diff] [review]
sucky is as sucky does

Comment 4

17 years ago
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla0.9.6

Comment 5

17 years ago
Comment on attachment 48991 [details] [diff] [review]
sucky is as sucky does

r=jag
Attachment #48991 - Flags: review+
(Assignee)

Comment 6

17 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.