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)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: ytpete, Assigned: martijn.martijn)

Details

Attachments

(2 files, 1 obsolete file)

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)
Attached file Testcase
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.
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
(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>
Attached patch wrong patch (obsolete) — Splinter Review
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.
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.
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?
> 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.
I'm all in favor of nixing this too, esp. if editor's OK with that.
(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.
I only rebuild parser/htmlparser/ (in case that's relevant).
(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.
Attached patch patch2Splinter Review
Ok, that makes it work.
There was also some code in editor that needed to be removed.
Attachment #207188 - Attachment is obsolete: true
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
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>?
Flags: blocking1.9a1?
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 on attachment 207210 [details] [diff] [review]
patch2

sr=jst
Attachment #207210 - Flags: superreview?(jst) → superreview+
Checked in on trunk.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: