Closed
Bug 321877
Opened 19 years ago
Closed 18 years ago
Content within <server> tag invisible (not treated as an unknown tag)
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ytpete, Assigned: martijn.martijn)
Details
Attachments
(2 files, 1 obsolete file)
125 bytes,
text/html
|
Details | |
5.53 KB,
patch
|
mrbkap
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 (This occurs in FF1.5 but not 1.0) Any content within <server> tags is not rendered, whereas content in other unknown tags is rendered. This tag seems to get special treatment. I hit this in an email message where the real text contained "<server>" (improperly escaped). In FF1.5 the entire email body was truncated at that point. Reproducible: Always Steps to Reproduce: Open testcase Actual Results: Lines 1 and 3 are visible Expected Results: Lines 1, 2, and 3 are visible (as in FF1.0 and IE6)
Reporter | ||
Comment 1•19 years ago
|
||
The testcase source is simply: <html><body> Text line 1<br> <server>Text line 2<br></server> <someothertag>Text line 3<br></someothertag> </body></html> The 3rd line is rendered fine, but the 2nd is not.
Comment 2•19 years ago
|
||
Seems that <server> is not an unknown element. It gets handled much like <script> or <style>. As far as I can see the difference between 1.5 and 1.0 is that in 1.0 we used to drop the contents on the floor, and in 1.5 we now keep the contents in the DOM. This makes 1.0 _hide_ the contents, and 1.5 _show_ the contents (unparsed). We've handled <server> tags ever since the html parser existed, as far as I can tell. The question is, does the existing Web content that uses <server> depend on our not showing its contents, as in 1.0, or on our treating it as a visible CDATA block, as in 1.5, or on another behaviour? What does IE do? http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/parser/htmlparser/src/nsElementTable.cpp&rev=3.189#1027
Assignee: nobody → mrbkap
Status: UNCONFIRMED → NEW
Component: Layout → HTML: Parser
Ever confirmed: true
QA Contact: layout → parser
Comment 3•19 years ago
|
||
(In reply to comment #2) > What does IE do? displays: Text line 1 Text line 2 Text line 3 document.body.innerHTML Text line 1<BR><SERVER>Text line 2<BR></SERVER><SOMEOTHERTAG>Text line 3<BR></SOMEOTHERTAG>
Assignee | ||
Comment 4•19 years ago
|
||
I think server tag support can be removed. I don't think IE6 does anything special with it (and I couldn't find any info on msdn about it). It seems like server-tag support was added in bug 44178, to prevent a crash. I've tried this, but apparently it is incomplete, because I get strange assertions afterwards.
Reporter | ||
Comment 5•19 years ago
|
||
Hm, my recollection was that FF 1.0.7 actually *showed* the content inside <server> tags. But I don't have a copy installed anymore to check. Anyway, I agree that there's no reason to treat this as a special tag, esp since IE doesn't. Might as well simplify things.
Comment 6•19 years ago
|
||
From my testing, I see 1.0.x drop the contents of the <server> tag entirely (which is expected, I bet we even assert on <server></server><script></script> about not collecting all of the skipped content on that branch). I bet that we have <server> support in the parser to help buddy editor, so that we parse the contents of the server tag as editor expects -- as CDATA, not as regular text. The simple solution here would be to simply add: server { display: none; } to html.css. That said, I don't know if editor even cares about server support now. Martijn, what assertions did you get with your patch?
Comment 7•19 years ago
|
||
> It seems like server-tag support was added in bug 44178, to prevent a crash.
No, <server> was supported before then. Support for treating its contents as CDATA was added then, though.
I'm all for just dropping <server> support entirely.
Comment 8•19 years ago
|
||
I'm all in favor of nixing this too, esp. if editor's OK with that.
Assignee | ||
Comment 9•19 years ago
|
||
(In reply to comment #6) > Martijn, what assertions did you get with your patch? This one ###!!! ASSERTION: title not in head: 'mCurrentContext == mHeadContext', file c:/ mozilla/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 2962 I get it with nearly every page I visit. When visiting this bug's url, also the layout gets screwed up, and I get a wrong title.
Assignee | ||
Comment 10•19 years ago
|
||
I only rebuild parser/htmlparser/ (in case that's relevant).
Comment 11•19 years ago
|
||
(In reply to comment #10) > I only rebuild parser/htmlparser/ (in case that's relevant). It is. You're going to want to rebuild content/ (and layout/build) and editor/libeditor.
Assignee | ||
Comment 12•19 years ago
|
||
Ok, that makes it work. There was also some code in editor that needed to be removed.
Attachment #207188 -
Attachment is obsolete: true
Comment 13•19 years ago
|
||
The patch seems fine to me, but I'd really like an editor peer to comment on whether editor still wants us to respect this tag.
Assignee: mrbkap → martijn.martijn
Comment 14•19 years ago
|
||
I'm not sure why we have a special case for the <server> tag. Charley Manske may know some of the history. I did find out that the <server> tag is for LiveWire (an add-on for Netscape's web server). Does any server still support <server>?
Assignee | ||
Updated•18 years ago
|
Flags: blocking1.9a1?
Comment 15•18 years ago
|
||
Comment on attachment 207210 [details] [diff] [review] patch2 Let's go with this. We haven't even had a bug report on the fact that it was totally broken before this anyway.
Attachment #207210 -
Flags: superreview?(jst)
Attachment #207210 -
Flags: review+
Comment 16•18 years ago
|
||
Comment on attachment 207210 [details] [diff] [review] patch2 sr=jst
Attachment #207210 -
Flags: superreview?(jst) → superreview+
Comment 17•18 years ago
|
||
Checked in on trunk.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: blocking1.9a1?
You need to log in
before you can comment on or make changes to this bug.
Description
•