655487 - Minor HTML syntax error now not corrected

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Ian]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

My code had a small error:
<select name="foo"<option 1><option 2>...</select>
I.e. there was a missing >.
All browsers until 4.01 silently corrected this. Suddenly it causes the dropdown to be rendered wrongly (which nearly corrupted an accounts database). Option 1 is not in the dropdown at all.
I assume there has been some policy change about HTML leniency.
In a case like this, is it not possible for Firefox to report an error rather than just rendering the page wrongly?

Reproducible: Always

Steps to Reproduce:
1. Build web page with simple html form to include the select tag above.
2. Load the page.
3.

Actual Results:  
Dropdown starting with option 2.

Expected Results:  
EITHER: Silently correct the syntax error as done until now
OR (BETTER): Fail to load the page and report the syntax error.

If there has been a policy change on html syntax correction, there will probably be a lot of broken sites out there!

Comment 1

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

This change was made to match the HTML specification, [1] which in turn was based on IE's behaviour in this case. Note that recent versions of WebKit and preview versions of Opera implement the same algorithm, and that a page with that error will break in all browsers.

Error reporting is bug 512229. In any case, using a validator such as validator.nu will help you catch those errors easily.

[1] In particular, <http://www.whatwg.org/html/#after-attribute-value-(quoted)-state> and <http://www.whatwg.org/html/#before-attribute-name-state>.

Comment 2

[Boris Zbarsky [:bzbarsky]]

And note that the new parser has been turned on by default for a year now, and there have been very few broken sites; this is the second report of this particular behavior change since then, and the first one was broken in other browsers to start with.

Comment 3

[Ian]

Having now reverted to Fx 3.6.17, I tried again with the faulty HTML code. I can confirm that the missing select closer is automatically forgiven in 3.6.17.
So on this machine the behaviour definitely changed when I used Fx 4 for the first time yesterday.
If the new behaviour had been occurring unnoticed for a year my accounts would be full of errors by now!
Perhaps this change is somehow specific to select?

I'm not familiar with whatwg. If it does not say that a parse error should cause processing to be aborted, I think it should! Instead, under Fx 4, we have a faulty rendering that looks ok, with potentially disastrous results. (And, of course, browsers should never have tolerated errors in the first place...)

Comment 4

[Ian]

Just had a thought. The HTML in question is inserted via JavaScript with no page reload. So perhaps the same parser is not used. 
This doesn't change the fact that something corrects the error in Fx 3 but not 4.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ian, the point is that this was an intentional change.  The new behavior matches that of IE, current WebKit, and Opera.  And yes, it did change from 3.6 to 4.0.  _You_ used Firefox 4 for the first time yesterday, but others have been using betas and final versions of it with this behavior since last May; that's what I was talking about in comment 2.

This really is invalid, unless you convince the HTML working group to change parsing behavior for HTML5.

Comment 6

[Ian]

Boris - I don't dispute there should be a parser error. But is it desirable that rendering should continue, as it does now?
This seems neither one thing nor the other. The error is recognised, but ignored rather than corrected.
Wouldn't it be safer if the browser just stopped, with or without a report?
I couldn't follow whatwg enough to see what that says should happen, and I don't know if that's the supreme authority anyway.

(It's not just a case of a missing option 1 in my example - the missing one should have been selected as default, so the user probably does not notice that the wrong option 2 is selected; unsuspected database corruption results. User mystified. I was just lucky - I saw the wrong selection and suspected the cause straight away.)

Comment 7

[Boris Zbarsky [:bzbarsky]]

> But is it desirable that rendering should continue

Unfortunately, yes.  If HTML parser errors were fatal then basically no web site would display.

> Wouldn't it be safer if the browser just stopped

If all browsers going back to 1992 had done that, maybe (though not definitely).  But they didn't, and this ship has long sailed.  Notice the failure of fatal XHTML parsing....

> I couldn't follow whatwg enough to see what that says should happen

Our current behavior is correct per the spec, yes.  It also matches other browsers.

> and I don't know if that's the supreme authority anyway.

At the moment, yes.  The whatwg and the w3c HTML working group are writing the spec together, effectively.