38154 - Output HTML strips out unknown ("userdefined") tags.

Status: VERIFIED FIXED

(Core :: DOM: Serializers, defect, P2)

Description

[Charles Manske]

Create an HTML file with an unknown tag (probably have to created or add to
an existing file in a text editor), e.g.:
<foo> this is a FOO tag</foo>
Open this file into Composer. Using Composer's Debug menu, Dump Content Tree,
you can see that the "foo" node exists and has the proper text content.
Use Debug menu, Output HTML and the see that the <foo> is completely removed,
and </foo> is changed to </>.
Obviously this is a "very bad thing"(tm).
BTY, is "editor" the proper component for output system bugs, given that
Akkana owns this even though it isn't technically editor code?

Comment 1

[Akkana Peck]

Sure 'nuff!  The correct component for stuff like this is "DOM to Text
Conversion" (I'm changing it, not that it matters much).

Is this really critical?  I'll let Beth rule on it.  Marking M17 for now, we can
move it up if it needs to be nsbeta2.  If the fix is just in the output sink, it
should be easy to fix; if it's in the parser, it might take longer.  It's not in
the XIF converter (the XIF output still has the foo tag).

Comment 2

[Charles Manske]

IMHO, if it doesn't seem to be a new "feature", it could be postponed to
bug fix phase, but it doesn mean we mangle "bad HTML" docs like MS Outlook 
mail (maybe not such a bad thing!)
I'm not sure what the effect of the "</>" would be.

Comment 3

[Jesse Ruderman]

Forgive me for being clueless, but how does stripping unknown tags break pages?

Comment 4

[Charles Manske]

Because they are only "unkown" to us in the DTD we are using. There's 2 
categories of "unknown": Published tags from other DTDs or proprietary, and 
those totally made up by a random author. The latter is probably safe to 
remove, but not the former.

Comment 5

[Akkana Peck]

We should fix this; it shouldn't be difficult.  Bumping priority up so the
milestone won't get moved down.

Comment 6

[Akkana Peck]

I have a very simple fix for this in my tree.  The sandwich now comes out as
<foo _moz-userdefined> </foo>.  The _moz_userdefined tag is not from the output
system; it's apparently coming from CNavDTD.

Comment 7

[Akkana Peck]

Nominating for beta2.  Easy, low-risk fix.

Comment 8

[leger]

Putting on [nsbeta2+][6/16] radar

Comment 9

[Akkana Peck]

Fixed.

Comment 10

[sujay]

verified in 6/19 build.