289469 - [FIXr]XUL error reporting broken

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Boris Zbarsky [:bzbarsky]]

It broke when we switched to the new expat version... the XML sink was updated,
but not the XUL one.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Just sync to the XML sink code

Comment 2

[Peter Van der Beken [:peterv]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: The right patch

Doh.  :(  Too many diffs in flight.  :(

Comment 4

[Peter Van der Beken [:peterv]]

Comment on attachment 181051 [details] [diff] [review]
The right patch

Thanks for cleaning up my mess.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 181051 [details] [diff] [review]
The right patch

a=dbaron, but dare I ask what's with the magical 0xFFFF ?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Fixed.