393281 - blank page when visiting a page with a syntax error in it

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[Fabien Tassin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082119 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082119 Minefield/3.0a8pre

The URL above is shown blank in today's trunk, while Firefox 2 has no problem displaying it.

"view page source" shows the error in red in both cases.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jesse Ruderman]

The entire content of the page is inside an unclosed <style>.  IMO, Gecko is correct to not show anything.  Safari does the same thing.  cf bug 305873.

Comment 2

[Jesse Ruderman]

The part that View Source highlights in red is a, um, red herring ;)

Comment 3

[Martijn Wargers (dead)]

The meta tag has no ">".
IE swallows the next tag and makes it an attribute.
See: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Chtml%3E%3[e-mail]%22%3CSTYLE%3E%3C/head%3E%3Cbody%3E%3C/body%3E%3C/html%3E
So this is not necessarily an issue of the unclosed <style>.
It might be considered to do what IE is doing in this case.

Comment 4

[Jesse Ruderman]

I don't think we're going to change that.  See bug 226495 comment 7 and bug 226495 comment 9.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Really, we should just do what the HTML5 spec says, since it'll define parsing in detail in a way that is compatible with IE when possible and always safe.

Comment 6

[Martijn Wargers (dead)]

It seems to me the HTML spec does what IE does:
http://www.whatwg.org/specs/web-apps/current-work/#attributes0
"
Attributes have a name and a value. Attribute names must consist of one character other than the space characters, U+003E GREATER-THAN SIGN (>), and U+002F SOLIDUS (/), followed by zero or more characters other than the space characters, U+003E GREATER-THAN SIGN (>), U+002F SOLIDUS (/), and U+003D EQUALS SIGN (=). In the HTML syntax, attribute names may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the attribute's name; attribute names are case-insensitive.
"

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

I have to admit, I'm nervous about changing behavior that we've had since 1999.

Comment 8

[Fabien Tassin]

Guys, I just raised this to see if it was expected to have a different behavior between FF2 and FF3, or if it was a regression. I don't really mind about the wontfix tag but it's still not clear to me if that's an improvement or a regression.

(Blake: I don't get the "behavior that we've had since 1999" as it clearly changed)

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #8)
> (Blake: I don't get the "behavior that we've had since 1999" as it clearly
> changed)

Fabien, the behavior that changed changed for bug 305873. This means that given the document, "foo<style>bar", we used to display "foobar" and now we display "foo". The point that Martijn brings up is that the actual testcase here is "foo<meta <style>bar". Our interpretation of the "half tag" is to parse it as "foo<meta ><style>bar", leading to this bug. IE's interpretation is to parse it as "foo<meta .style>bar" where the . = <. This way, the style tag is interpreted as an attribute, not a tag, hiding the problem. The interpretation of the < in the middle of an attribute list is the 8 year-old behavior I was referring to.