Bug 69095 - REGRESSION(r94274): cloned text input loses value
Summary: REGRESSION(r94274): cloned text input loses value
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Normal
Assignee: Ryosuke Niwa
URL: http://www.ptable.com/
Keywords: HasReduction, Regression
Depends on:
Blocks:
 
Reported: 2011-09-29 10:43 PDT by Michael Dayah
Modified: 2011-10-03 16:01 PDT (History)
7 users (show)

See Also:


Attachments
reduction (518 bytes, text/html)
2011-09-30 17:22 PDT, Ryosuke Niwa
no flags Details
somewhat refined reduction (830 bytes, text/html)
2011-09-30 17:28 PDT, Ryosuke Niwa
no flags Details
DRT test (558 bytes, text/html)
2011-09-30 18:43 PDT, Ryosuke Niwa
no flags Details
fixes the bug (3.76 KB, patch)
2011-10-03 15:20 PDT, Ryosuke Niwa
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Dayah 2011-09-29 10:43:48 PDT
Nightly Webkit and Chrome builds introduce a regression causing the temperature input box (left of Helium) on ptable.com to reset to 0. Site does some elaborate cloneNode operations to animate the slider and input box.

Bug does not occur in Safari 5.1 or Chrome 14. Initial load of the site should show "273" in input box rather than 0.
Comment 1 Michael Dayah 2011-09-29 16:20:48 PDT
Regression occurred between r94213 and r94287.
Comment 2 Alexey Proskuryakov 2011-09-29 22:03:25 PDT
Thanks for finding the regression range!

Not sure what change is the cause, maybe <http://trac.webkit.org/changeset/94252>?
Comment 3 Alexey Proskuryakov 2011-09-30 10:34:27 PDT
Further reduced to r94273-94287, so it's not r94252.

There aren't many suspicious changes in this range, the most related being <http://trac.webkit.org/changeset/94274>.
Comment 4 Ryosuke Niwa 2011-09-30 17:22:37 PDT
Created attachment 109379 [details]
reduction

Here's a reduction. The third text field has the value 999 on Chrome 14 but has 0 on ToT WebKit.
Comment 5 Ryosuke Niwa 2011-09-30 17:28:20 PDT
Created attachment 109381 [details]
somewhat refined reduction

In this version, you can see that the last input element has the value "999" but what's shown on the scree is "0".
Comment 6 Ryosuke Niwa 2011-09-30 17:28:54 PDT
Looking at the bug and the regression range, this is definitely a regression from r94274.
Comment 7 Ryosuke Niwa 2011-09-30 18:43:14 PDT
Created attachment 109390 [details]
DRT test

Here's a complete reduction.
Comment 8 Ryosuke Niwa 2011-09-30 19:34:53 PDT
The problem is that we're not copying the value stored separately from the value content attribute (default  value) in cloneNode(true).
Comment 9 Ryosuke Niwa 2011-10-03 14:58:17 PDT
(In reply to comment #8)
> The problem is that we're not copying the value stored separately from the value content attribute (default  value) in cloneNode(true).

Well, this isn't true. m_valueIfDirty is properly copied in copyNonAttributeProperties. The problem is that this function is not updating inner element text. Will upload a patch in a minute.
Comment 10 Ryosuke Niwa 2011-10-03 15:20:55 PDT
Created attachment 109539 [details]
fixes the bug
Comment 11 Ryosuke Niwa 2011-10-03 15:28:51 PDT
Wow, that was quick! Thanks for the review, Darin.
Comment 12 Ryosuke Niwa 2011-10-03 16:01:48 PDT
Committed r96552: <http://trac.webkit.org/changeset/96552>