BUILD: 2001-01-05 nightly STEPS TO REPRODUCE: 1) Load http://www.bettycrocker.com/recipes.aspx/russian-tea-cakes/3af8664b-6c3e-4022-b686-cd961521e59b 2) Note that there are two copies of the "save/print/e-mail/share" toolbar and that the actual recipe is off in the weeds below the ad on the left. 3) Disable the HTML5 parser and watch the problem go away. I saved the page "complete" while not using the HTML5 parser, and the saved version shows similar problems, even in offline mode (so seems to not depend on network resources). Might be easier to debug with that...

Is this confirmed to be a problem with the parser, and not poor coding which contradicts the new HTML5 specs parsing rules? In that case, this is a case for the evangelism team, but anyhow, a reduced test case would be good, so that we can find out what is causing it.

It's not confirmed to be anything other than a case in which the HTML5 parser breaks a webpage. It might be a bug in our HTML5 parser code, it might be a bug in the HTML5 parsing spec, or it might be something we have to evangelize. Since the spec wants to be web-compatible, this last is least likely. You are of course free to work on reducing the attached testcase...

It seems this problem is related to the site doing: document.write("<noscript>");

Guess: Tokenizer state migration doesn't work right when it comes to copying the name of the current element.

Bug 538754 looks like it might be related to this one. This also has document.write (or similar) combined with <noscript>. Inspecting with Firebug shows some odd things.

Pushed: http://hg.mozilla.org/mozilla-central/rev/606c6a340c3f A reftest directory for the parser would be good to have in order to add tests for document.write(), since document.write() isn't covered by the html5lib test suite.

Please feel free to add a parser reftest directory as desired!

I can confirm that the changeset in comment 9 fixes the site.