Content within <server> tag invisible (not treated as an unknown tag)

RESOLVED FIXED

Status

()

Core
HTML: Parser
--
minor
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Peter Flynn (Oracle), Assigned: Martijn Wargers (dead))

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

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

12 years ago
Created attachment 207156 [details]
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

Comment 3

12 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

12 years ago
Created attachment 207188 [details] [diff] [review]
wrong patch

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

12 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.
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.
(Assignee)

Comment 9

12 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

12 years ago
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.
(Assignee)

Comment 12

12 years ago
Created attachment 207210 [details] [diff] [review]
patch2

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

Comment 14

12 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

12 years ago
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
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

11 years ago
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.