Bug 55120

Summary: <input value="type=submit"> throws a warning (“HTML parse error”)
Product: WebKit Reporter: Mathias Bynens <mathias>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ahmad.saleem792, ap, eoconnor, eric, mathias, priyajeet.hora, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: OS X 10.6   
URL: data:text/html,<form><input value="type=submit"></form>
Attachments:
Description Flags
Patch
none
Patch none

Mathias Bynens
Reported 2011-02-24 00:45:13 PST
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.
Attachments
Patch (1.42 KB, patch)
2011-02-24 19:00 PST, Adam Barth 		no flags
DetailsFormatted DiffDiff
Patch (1.67 KB, patch)
2011-02-26 22:13 PST, Adam Barth 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Mathias Bynens
Comment 1 2011-02-24 00:49:33 PST
Same goes for data:text/html,<form><input name="action|method|enctype"></form>
Alexey Proskuryakov
Comment 2 2011-02-24 13:39:13 PST
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.
Adam Barth
Comment 3 2011-02-24 14:11:40 PST
Please feel free to remove the warnings. I added them because folks complained about the warnings being missing.
Mathias Bynens
Comment 4 2011-02-24 14:58:32 PST
(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.
Adam Barth
Comment 5 2011-02-24 15:01:34 PST
Surely you need <html>, <head>, and <body> tags somewhere.
Theresa O'Connor
Comment 6 2011-02-24 15:09:18 PST
Adam: no, Mathias is right; adding the doctype and <title> will do the trick. <html>, <head>, and <body> have optional start and end tags.
Adam Barth
Comment 7 2011-02-24 15:14:06 PST
Ah, ok.
Alexey Proskuryakov
Comment 8 2011-02-24 15:44:33 PST
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).
Adam Barth
Comment 9 2011-02-24 15:46:46 PST
> 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.
Alexey Proskuryakov
Comment 10 2011-02-24 16:04:37 PST
> 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.
Adam Barth
Comment 11 2011-02-24 18:55:53 PST
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.
Adam Barth
Comment 12 2011-02-24 18:56:31 PST
The bug appears to be that we incorrect omit the "Otherwise" in the spec.
Adam Barth
Comment 13 2011-02-24 19:00:20 PST
Created attachment 83760 [details] Patch
Adam Barth
Comment 14 2011-02-24 19:02:25 PST
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.
Adam Barth
Comment 15 2011-02-26 22:13:29 PST
Created attachment 83965 [details] Patch
Adam Barth
Comment 16 2011-02-26 22:14:09 PST
These parse error messages aren't ready for prime time. This patch just nukes them from obit.
Eric Seidel (no email)
Comment 17 2011-02-26 22:33:44 PST
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.
WebKit Commit Bot
Comment 18 2011-02-26 22:53:37 PST
Comment on attachment 83965 [details] Patch Clearing flags on attachment: 83965 Committed r79816: <http://trac.webkit.org/changeset/79816>
Ahmad Saleem
Comment 19 2022-08-06 07:45:05 PDT
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!
Radar WebKit Bug Importer
Comment 20 2022-08-06 07:46:16 PDT
<rdar://problem/98242250>
Note You need to log in before you can comment on or make changes to this bug.