Closed Bug 393281 Opened 17 years ago Closed 17 years ago

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

Categories

(Core :: DOM: HTML Parser, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: fta+bugzilla, Unassigned)

References

()

Details

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.
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.
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → parser
Version: unspecified → Trunk
The part that View Source highlights in red is a, um, red herring ;)
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Blocks: 305873
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%3Chead%3E%3Cmeta%20HTTP-EQUIV%3D%22Reply-to%22CONTENT%3D%22Lonzac@voila.fr%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.
I don't think we're going to change that.  See bug 226495 comment 7 and bug 226495 comment 9.
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.
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.
"
I have to admit, I'm nervous about changing behavior that we've had since 1999.
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)
(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.
You need to log in before you can comment on or make changes to this bug.