Bug 42644 - HTML5 tree builder should restore form state
Summary: HTML5 tree builder should restore form state
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other OS X 10.5
: P2 Normal
Assignee: Adam Barth
URL:
Keywords:
Depends on:
Blocks: 41123
  Show dependency treegraph
 
Reported: 2010-07-20 09:23 PDT by Adam Barth
Modified: 2010-07-20 11:28 PDT (History)
3 users (show)

See Also:


Attachments
Patch (2.14 KB, patch)
2010-07-20 09:25 PDT, Adam Barth
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2010-07-20 09:23:11 PDT
HTML5 tree builder should restore form state
Comment 1 Adam Barth 2010-07-20 09:25:37 PDT
Created attachment 62083 [details]
Patch
Comment 2 Darin Adler 2010-07-20 09:29:40 PDT
Comment on attachment 62083 [details]
Patch

r=me

I think it would be good to add some sort of debug assertion that every element gets a finishParsingChildren call before some later point in time, so we could see more directly, rather than indirectly, that every element gets it.
Comment 3 Adam Barth 2010-07-20 09:31:10 PDT
> I think it would be good to add some sort of debug assertion that every element gets a finishParsingChildren call before some later point in time, so we could see more directly, rather than indirectly, that every element gets it.

That sounds like a good idea.  When should we fire that ASSERT?
Comment 4 Eric Seidel (no email) 2010-07-20 09:36:54 PDT
Comment on attachment 62083 [details]
Patch

LGTM too.
Comment 5 Darin Adler 2010-07-20 09:37:24 PDT
(In reply to comment #3)
> That sounds like a good idea.  When should we fire that ASSERT?

One possibility is to walk the whole just-parsed tree and perhaps even the whole document as well firing that assert any time the parser finishes parsing.

Another possibility is to fire the assertion at element destructor time.

I think there are other possible times as well that won’t necessarily be quite as good: One is event dispatch, but there are probably lots of others. Anything that doesn’t happen during parsing, but almost always happens later could fit the bill.
Comment 6 Eric Seidel (no email) 2010-07-20 09:39:52 PDT
It's unclear to me if "finishedParsingChildren" will be required in the end.  It's part of the old parser's logic, but we might need an equivalent in the new parser too.
Comment 7 Darin Adler 2010-07-20 09:40:27 PDT
(In reply to comment #6)
> It's unclear to me if "finishedParsingChildren" will be required in the end.  It's part of the old parser's logic, but we might need an equivalent in the new parser too.

I’m pretty sure that this or the equivalent will be needed. We removed it from the old parser at one point, and then had to add it back.
Comment 8 Adam Barth 2010-07-20 09:42:00 PDT
Does it only get called for parser-inserted elements?  I guess I could look in the debugger.
Comment 9 Darin Adler 2010-07-20 09:54:40 PDT
(In reply to comment #8)
> Does it only get called for parser-inserted elements?  I guess I could look in the debugger.

It goes hand in hand with a "created by parser" flag passed when the element is created.
Comment 10 WebKit Commit Bot 2010-07-20 11:28:44 PDT
Comment on attachment 62083 [details]
Patch

Clearing flags on attachment: 62083

Committed r63760: <http://trac.webkit.org/changeset/63760>
Comment 11 WebKit Commit Bot 2010-07-20 11:28:49 PDT
All reviewed patches have been landed.  Closing bug.