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)
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.
Comment 1•17 years ago
|
||
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
Comment 2•17 years ago
|
||
The part that View Source highlights in red is a, um, red herring ;)
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Comment 3•17 years ago
|
||
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.
Comment 4•17 years ago
|
||
I don't think we're going to change that. See bug 226495 comment 7 and bug 226495 comment 9.
Comment 5•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
I have to admit, I'm nervous about changing behavior that we've had since 1999.
Reporter | ||
Comment 8•17 years ago
|
||
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•17 years ago
|
||
(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.
Description
•