129608 - parsererror should be in its own namespace

Status: RESOLVED FIXED

(Core :: XML, defect, P2)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Right now it is in no namespace or maybe XHTML namespace; wrong in any case.
Should be trivial fix, but needed since we have CSS style rules for these
elements in the ua.css...

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Fix error generator and stylesheet

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I also noticed we weren't cleaning up the document before adding the parser error.

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Remember XUL content sink too

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Harish, can you review?

I could remove nsExpatTokenizer.cpp while I check this in. Nobody should be
using it.

I am also wondering what are we doing with all the HTML tag / parsererror stuff?
See the LXR search: http://lxr.mozilla.org/mozilla/search?string=parsererror

Comment 5

[harishd]

Comment on attachment 73329 [details] [diff] [review]
Remember XUL content sink too

r=harishd (Could you also remove htmlparser/public/nsIExpatTokenizer.idl
htmlparser/src/nsWellFormedDTD.* ?
)

Comment 6

[harishd]

oops, there is no nsIExpatTokenzier.idl. Please remove nsIExpatTokenizer.h. Thanx.

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 73329 [details] [diff] [review]
Remember XUL content sink too

sr=jst

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 73329 [details] [diff] [review]
Remember XUL content sink too

a=roc+moz

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Checked in.