[FIXr]XUL error reporting broken

RESOLVED FIXED in mozilla1.8beta2

Status

()

P1
normal
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Tracking

Trunk
mozilla1.8beta2
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

It broke when we switched to the new expat version... the XML sink was updated,
but not the XUL one.
Created attachment 179975 [details] [diff] [review]
Just sync to the XML sink code
Attachment #179975 - Flags: superreview?(jst)
Attachment #179975 - Flags: review?(jst)
Priority: -- → P1
Summary: XUL error reporting broken → [FIX]XUL error reporting broken
Target Milestone: --- → mozilla1.8beta2
Comment on attachment 179975 [details] [diff] [review]
Just sync to the XML sink code

Bz, I don't think this is the right patch for this bug.
Created attachment 181051 [details] [diff] [review]
The right patch

Doh.  :(  Too many diffs in flight.  :(
Attachment #181051 - Flags: superreview?(peterv)
Attachment #181051 - Flags: review?(peterv)
Attachment #179975 - Attachment is obsolete: true
Attachment #179975 - Flags: superreview?(jst)
Attachment #179975 - Flags: superreview-
Attachment #179975 - Flags: review?(jst)
Attachment #179975 - Flags: review-
Comment on attachment 181051 [details] [diff] [review]
The right patch

Thanks for cleaning up my mess.
Attachment #181051 - Flags: superreview?(peterv)
Attachment #181051 - Flags: superreview+
Attachment #181051 - Flags: review?(peterv)
Attachment #181051 - Flags: review+
Comment on attachment 181051 [details] [diff] [review]
The right patch

Requesting approval for 1.8b for this fix.  This just fixes the error document
created for malformed XUL to use the "parseerror" namespace again, so it gets
styled like we want it to be.
Attachment #181051 - Flags: approval1.8b2?
Summary: [FIX]XUL error reporting broken → [FIXr]XUL error reporting broken
Comment on attachment 181051 [details] [diff] [review]
The right patch

a=dbaron, but dare I ask what's with the magical 0xFFFF ?
Attachment #181051 - Flags: approval1.8b2? → approval1.8b2+
The API expat uses to report the namespace URI, prefix, and localname to the
application (content sink) reports them as a single string with a separator char
of the application's choice.  See
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsContentUtils.cpp#1737
for something like docs on this.

We're using 0xFFFF as the separator because that's not a valid char in XML, so
it shouldn't actually appear in namespace URIs, prefixes, or localnames.
Fixed.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.