http://trac.webkit.org/changeset/66482 made fast/forms/restore-to-non-edited-controls.html nonsense. We fix the test in this bug.
Created attachment 148481 [details] Patch
Comment on attachment 148481 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=148481&action=review > LayoutTests/ChangeLog:13 > + After HTML5 parser, we don't attach renderes during innerHTML Nit: renderes => renderers > LayoutTests/ChangeLog:15 > + built a form and the test haven't work since introducing HTML5 parser. Just a confirmation: What happens if innerHTML is used and <!DOCTYPE html> is omitted? I am asking this because I am not sure whether we should hide the difference by using document.write() (just like your patch) or we should test innerHTML for both <!DOCTYPE html> case and no-<!DOCTYPE html> case.
Comment on attachment 148481 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=148481&action=review >> LayoutTests/ChangeLog:15 >> + built a form and the test haven't work since introducing HTML5 parser. > > Just a confirmation: What happens if innerHTML is used and <!DOCTYPE html> is omitted? > > I am asking this because I am not sure whether we should hide the difference by using document.write() (just like your patch) or we should test innerHTML for both <!DOCTYPE html> case and no-<!DOCTYPE html> case. DOCTYPE doesn't matter. We always use HTML5 parser.
Created attachment 148487 [details] Patch 2 typo
Comment on attachment 148487 [details] Patch 2 Thanks for the clarification.
I'm confused. If we changed innerHTML behavior, was this a regression? Does our new innerHTML/form behavior match other browsers? It's good that we fixed the test, but there may be an underlying bug here that we're pasting over?
(In reply to comment #6) > I'm confused. If we changed innerHTML behavior, was this a regression? Does our new innerHTML/form behavior match other browsers? > > It's good that we fixed the test, but there may be an underlying bug here that we're pasting over? Yeah, HTML5 parser made a regression. We were able to restore form values for dynamically generated form with innerHTML, but now we can't. However I haven't seen bug reports for this regression. I guess this is not so important to users. I think there are no ways to observe whether a node is attached in Node::finishParsingChildren() in innerHTML case on other browsers, and this is not a compatibility issue. I have a plan to change the form restore timing. The regression will be resolved then.
(In reply to comment #7) > (In reply to comment #6) > I have a plan to change the form restore timing. The regression will be resolved then. Do we have a bug to track that change. Seems useful to relate here. Thanks!
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > I have a plan to change the form restore timing. The regression will be resolved then. > > Do we have a bug to track that change. Seems useful to relate here. Thanks! I explained the plan in https://bugs.webkit.org/show_bug.cgi?id=23346#c45 . I'll add a new blocker bug for the timing change to Bug 23346.
Committed r120796: <http://trac.webkit.org/changeset/120796>