Open data:text/html,<form><input value="type=submit"></form> and open the Web Inspector Console. You’ll find that there’s a warning message: “HTML parse error (recovered gracefully)”. There’s nothing wrong with this markup though, so it shouldn’t throw a warning. This used to work fine. The latest stable Safari release, for example (version 5.0.3 / 6533.19.4) didn’t have this problem.
Same goes for data:text/html,<form><input name="action|method|enctype"></form>
This document obviously isn't valid HTML, but I cannot tell what exactly the parser complains about. The warning printed to Web Inspector console is not helpful.
Please feel free to remove the warnings. I added them because folks complained about the warnings being missing.
(In reply to comment #2) > This document obviously isn't valid HTML, but I cannot tell what exactly the parser complains about. The warning printed to Web Inspector console is not helpful. If you prefix them with <!doctype html><title></title> both documents are perfectly valid.
Surely you need <html>, <head>, and <body> tags somewhere.
Adam: no, Mathias is right; adding the doctype and <title> will do the trick. <html>, <head>, and <body> have optional start and end tags.
Ah, ok.
I think that there are two issues here: 1) What error does our parser think that it sees? No amount of boilerplate around this example seem to make the error go away. 2) The warning message should be improved or removed - it seems unlikely that it can help anyone in its current state (the only bit of information it has is a line number, which doesn't seem sufficient).
> 1) What error does our parser think that it sees? No amount of boilerplate around this example seem to make the error go away. If you set a breakpoint in HTMLTreeBuilder::parseError, you'll see the stack that generates the message. From the stack, you can look at the spec to see the instruction to emit a parse error. That will let us diagnose whether the bug is in the spec or in the code. > 2) The warning message should be improved or removed - it seems unlikely that it can help anyone in its current state (the only bit of information it has is a line number, which doesn't seem sufficient). I definitely agree.
> If you set a breakpoint in HTMLTreeBuilder::parseError, you'll see the stack that generates the message. The stack is: #0 0x1038072c3 in WebCore::HTMLTreeBuilder::parseError at HTMLTreeBuilder.cpp:2809 #1 0x103808345 in WebCore::HTMLTreeBuilder::processAnyOtherEndTagForInBody at HTMLTreeBuilder.cpp:1563 #2 0x103811e93 in WebCore::HTMLTreeBuilder::processEndTagForInBody at HTMLTreeBuilder.cpp:1991 #3 0x10380eb79 in WebCore::HTMLTreeBuilder::processEndTag at HTMLTreeBuilder.cpp:2103 #4 0x10380e551 in WebCore::HTMLTreeBuilder::processToken at HTMLTreeBuilder.cpp:472 #5 0x103813108 in WebCore::HTMLTreeBuilder::constructTreeFromAtomicToken at HTMLTreeBuilder.cpp:450 #6 0x1038134a2 in WebCore::HTMLTreeBuilder::constructTreeFromToken at HTMLTreeBuilder.cpp:445 #7 0x103796c9e in WebCore::HTMLDocumentParser::pumpTokenizer at HTMLDocumentParser.cpp:269 The node in question is a <body>. It is not easy enough for me to read the spec to see if the code follows it here.
That code should match up with <http://www.whatwg.org/specs/web-apps/current-work/#parsing-main-inbody> under "Any other end tag." Specifically: "Otherwise, if node is in the special category, then this is a parse error; ignore the token, and abort these steps." if (isSpecialNode(node)) { parseError(token); return; } From this list <http://www.whatwg.org/specs/web-apps/current-work/#special>, body is a special tag.
The bug appears to be that we incorrect omit the "Otherwise" in the spec.
Created attachment 83760 [details] Patch
Comment on attachment 83760 [details] Patch Nope. That's not it. There's no control flow from the previous if-block that reaches that line.
Created attachment 83965 [details] Patch
These parse error messages aren't ready for prime time. This patch just nukes them from obit.
Comment on attachment 83965 [details] Patch Someone recently posted a patch which plumbed all console messages up to the client. That would make these testable.
Comment on attachment 83965 [details] Patch Clearing flags on attachment: 83965 Committed r79816: <http://trac.webkit.org/changeset/79816>
This was landed as per Comment 18 and never backed-out, I checked by typing bug number in Webkit Github repo. I am going to mark this as "RESOLVED FIXED", if I am incorrect, please mark it accordingly with updated comments. Thanks!
<rdar://problem/98242250>