Bug 69095

Summary:

REGRESSION(r94274): cloned text input loses value

Product:

WebKit

Reporter:

Michael Dayah <michael>

Component:

Forms

Assignee:

Ryosuke Niwa <rniwa>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

ap, darin, dglazkov, morrita, rniwa, rolandsteiner, tkent

Priority:

Keywords:

HasReduction, Regression

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

URL:

http://www.ptable.com/

Attachments:

Description	Flags
reduction	none
somewhat refined reduction	none
DRT test	none
fixes the bug	darin: review+

Michael Dayah

Reported 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.

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
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Michael Dayah

Comment 1 2011-09-29 16:20:48 PDT

Regression occurred between r94213 and r94287.

Alexey Proskuryakov

Comment 2 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>?

Alexey Proskuryakov

Comment 3 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>.

Ryosuke Niwa

Comment 4 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.

Ryosuke Niwa

Comment 5 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".

Ryosuke Niwa

Comment 6 2011-09-30 17:28:54 PDT

Looking at the bug and the regression range, this is definitely a regression from r94274.

Ryosuke Niwa

Comment 7 2011-09-30 18:43:14 PDT

Created attachment 109390 [details] DRT test Here's a complete reduction.

Ryosuke Niwa

Comment 8 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).

Ryosuke Niwa

Comment 9 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.

Ryosuke Niwa

Comment 10 2011-10-03 15:20:55 PDT

Created attachment 109539 [details] fixes the bug

Ryosuke Niwa

Comment 11 2011-10-03 15:28:51 PDT

Wow, that was quick! Thanks for the review, Darin.

Ryosuke Niwa

Comment 12 2011-10-03 16:01:48 PDT

Committed r96552: <http://trac.webkit.org/changeset/96552>

Note You need to log in before you can comment on or make changes to this bug.