499246 - <script/> in header causes no content to display

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Dietrich Ayala (:dietrich)]

works in firefox 2, breaks pages in firefox >=3.

Comment 1

[Michael Ryan]

Dupe of bug 203398?

Comment 2

[Mardeg]

Attachment: XHTML standards compliant example

Comment 3

[Mardeg]

XML-style self closing tags do not belong in text/html documents.

Comment 4

[Dietrich Ayala (:dietrich)]

seems like it should gracefully degrade. in this case, zero page content is displayed. it gracefully degraded in fx2.

Comment 5

[Dietrich Ayala (:dietrich)]

i read bug 162653, and this is not a duplicate of it.

bug 162653 is about xhtml, being served as text/html, instead of the proper mime type.

this bug is about html, being served as text/html, and a garbage tag *breaking* display of the rest of the page.

Comment 7

[Dietrich Ayala (:dietrich)]

afaict, bug 327796 is requesting that we treat <script/> as <script></script> in text/html pages.

this bug is about not breaking the rest of the page when encountering <script src="..."/> in text/html pages.

a far more web-friendly way to handle this would be to ignore the tag. instead, we ignore everything in the entire page, rendering nothing.

Comment 8

[Robert Longson [:longsonr]]

You could try taking it up with thos involved with bug 305873

Comment 9

[rglaue]

This is still a problem, sort of, with Firefox 3.5.2

If the example file "XHTML standards compliant example" is provided as Content-type: text/html then the Firefox web browser shows a blank page.

If this same example file is provided as Content-type: text/xhtml, then the content shows in the browser correctly.

So an easy test of this is same this file as "test1.html" and test2.xhtml" then do a file open in Firefox. test1.html will be blank, and teat2.xhtml will show the content.

Was this intended?

I will also report that the latest MSIE browser is experiencing this same issue.

-RG

Comment 10

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

INVALID according to HTML5.

Comment 11

[rglaue]

Yes it is invalid, but should not break the web page.
Google Chrome will display the HTML page without breaking. But Firefox 3.5.2 croaks on the page display.

When using XSLT, it is possible for a tag to be spit out as <tag/> if the XSLT template is missing content for the tag.

Just because <script/> is invalid does not mean it should cause the HTML page display to croak. And that is what this bug report is about. Other <tag/> tags do not cause Firefox to croak, Neither should <script/>.

Comment 12

[Henri Sivonen (:hsivonen)]

(In reply to comment #11)
> When using XSLT, it is possible for a tag to be spit out as <tag/> if the XSLT
> template is missing content for the tag.

You should never use the XML output modes of XSLT to generate text/html. If you use XSLT to generate text/html, you should use the HTML output mode or you should connect an HTML-aware serializer to the XSLT processor.

Comment 13

[rglaue]

The HTML 5 June 15 Draft Standard requires the closing tag for script, i.e. <script></script>. The Draft requires that the end tag "must not be omitted".
Tags identified as void elements allow self-closing start tags. The script tag is a raw text element requiring a closing tag. It is not a void element which allows self-closing start tags.

The question is, should Firefox croak on display when it encounters an invalid tag not described in the HTML standards?

If it does not croak on display, should it silently skip over the the invalid tag? And in this case NOT execute the <script> tag contents, e.g. <script src="file.js"/> ?  Users coding HTML will not understand that the <script/> tag is invalid, and is the reason why it is not executed.

Google Chrome is forgiving and will execute the invalid <script src="file.js"/> tag.
If Firefox is to be strictly adherent to the HTML 5 specification, should it give some alternate error indicator, or is the empty "croak on display" page the error indicator?

Unfortunately, it would seem that the "croak on display" error is the best error indicator for the HTML coder/programmer if Firefox is to be strictly adherent to the HTML 5 spec and not allow the script element in a void context, i.e. <script src"..."/>.

And in this later case, this report is not a bug, as resolved.

Comment 14

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Work(In reply to comment #13)
> The HTML 5 June 15 Draft Standard requires the closing tag for script, i.e.
> <script></script>. The Draft requires that the end tag "must not be omitted".
> Tags identified as void elements allow self-closing start tags. The script tag
> is a raw text element requiring a closing tag. It is not a void element which
> allows self-closing start tags.
> 

Correct. However, these are requirements for *authors*. HTML5 also contains very detailed requirements for *User Agents*, i.e., browsers.

> The question is, should Firefox croak on display when it encounters an invalid
> tag not described in the HTML standards?
> 

The answer is detailed in the HTML parsing section: <http://www.whatwg.org/html/#parsing>.

> If it does not croak on display, should it silently skip over the the invalid
> tag? And in this case NOT execute the <script> tag contents, e.g. <script
> src="file.js"/> ?  Users coding HTML will not understand that the <script/> tag
> is invalid, and is the reason why it is not executed.
> 
> Google Chrome is forgiving and will execute the invalid <script src="file.js"/>
> tag.

Work is ongoing to implement the HTML parsing algorithm in WebKit (which Chrome uses for HTML parsing); in a few months' time, Google Chrome will not execute the script.

> If Firefox is to be strictly adherent to the HTML 5 specification, should it
> give some alternate error indicator, or is the empty "croak on display" page
> the error indicator?
> 

Probably. Bug 512229 would cover that.

> Unfortunately, it would seem that the "croak on display" error is the best
> error indicator for the HTML coder/programmer if Firefox is to be strictly
> adherent to the HTML 5 spec and not allow the script element in a void context,
> i.e. <script src"..."/>.
> 
> And in this later case, this report is not a bug, as resolved.

Comment 15

[rglaue]

I posted a follow up to this issue in Bug 512229 regarding how to handle the error when Firefox encounters an invalid HTML tag during parsing. Should the issue described here be encountered, a parse error should be logged in the error console.

With the feature enhancement described in Bug 512229 , the issue described here will no longer be a concern as the HTML coder will receive an error message explaining why Firefox is displaying an empty page.

Focus regarding Bug 499246 should now be redirected to Bug 512229 .