bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

VERIFIED FIXED in M17

Status

()

Core
Serializers
P2
critical
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Charles Manske, Assigned: Akkana Peck)

Tracking

Trunk
All
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+][6/16])

(Reporter)

Description

19 years ago
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?
(Assignee)

Comment 1

19 years ago
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).
Status: NEW → ASSIGNED
Component: Editor → DOM to Text Conversion
Target Milestone: --- → M17
(Reporter)

Comment 2

19 years ago
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

19 years ago
Forgive me for being clueless, but how does stripping unknown tags break pages?
(Reporter)

Comment 4

19 years ago
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.
(Reporter)

Updated

18 years ago
Summary: Output HTML strips out unkown tags. → Output HTML strips out unknown ("userdefined") tags.
(Assignee)

Comment 5

18 years ago
We should fix this; it shouldn't be difficult.  Bumping priority up so the
milestone won't get moved down.
Priority: P3 → P2
(Assignee)

Comment 6

18 years ago
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.
Whiteboard: FIX IN HAND
(Assignee)

Comment 7

18 years ago
Nominating for beta2.  Easy, low-risk fix.
Keywords: nsbeta2

Comment 8

18 years ago
Putting on [nsbeta2+][6/16] radar
Whiteboard: FIX IN HAND → [nsbeta2+][6/16]FIX IN HAND
(Assignee)

Comment 9

18 years ago
Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+][6/16]FIX IN HAND → [nsbeta2+][6/16]

Comment 10

18 years ago
verified in 6/19 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.