Bug 36314 - Text field "onchange" event is triggered if actual value unchanged
Summary: Text field "onchange" event is triggered if actual value unchanged
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Emil A Eklund
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-18 11:47 PDT by Ivo Krab
Modified: 2011-03-25 12:16 PDT (History)
7 users (show)

See Also:


Attachments
Patch (8.20 KB, patch)
2011-03-07 11:01 PST, Emil A Eklund
no flags Details | Formatted Diff | Diff
Patch (11.28 KB, patch)
2011-03-24 18:33 PDT, Emil A Eklund
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivo Krab 2010-03-18 11:47:28 PDT
When the user types into a text field (input type="text" or textarea) something that does not actually change the value of the field (i.e. the typed value is identical to the original value), blurring the field triggers the "onchange" event anyway.

This is unintuitive behavior and inconsistent with other browsers (FireFox, IE, although Opera behaves the same).

"onchange" should only be triggered if the new value is different from the original one.

In the attached test case, for comparison there is also a <select>: if one goes through the list and ends up seleting the same value as before, no onchange is triggered, only if the value actually changed.

For the text input and textarea, though, typing an "l" over the last letter "l" results in an "onchange" after moving the focus away.

Confirmed on r56152.
Comment 1 Emil A Eklund 2011-03-07 11:01:43 PST
Created attachment 84957 [details]
Patch
Comment 2 Dimitri Glazkov (Google) 2011-03-16 11:58:41 PDT
Emil, I wonder if we can keep the machinery of comparing text value in the InputType? Storing Strings in a RenderObject just seems... suboptimal.
Comment 3 Emil A Eklund 2011-03-16 12:04:23 PDT
Yeah, it seems a bit. I didn't want to change the code too much but moving logic into InputType makes sense. I'll update the patch.
Comment 4 Emil A Eklund 2011-03-24 18:33:10 PDT
Created attachment 86864 [details]
Patch

This was a bit tricker than I first though, added tests for some of the tricker cases and made sure it works with input types other than text (checkbox, radio, password, search, number, range).
Comment 5 Dimitri Glazkov (Google) 2011-03-25 10:53:58 PDT
Comment on attachment 86864 [details]
Patch

ok.
Comment 6 WebKit Commit Bot 2011-03-25 12:08:49 PDT
Comment on attachment 86864 [details]
Patch

Clearing flags on attachment: 86864

Committed r81978: <http://trac.webkit.org/changeset/81978>
Comment 7 WebKit Commit Bot 2011-03-25 12:08:52 PDT
All reviewed patches have been landed.  Closing bug.
Comment 8 WebKit Review Bot 2011-03-25 12:16:24 PDT
http://trac.webkit.org/changeset/81978 might have broken Chromium Linux Release and EFL Linux Release (Build)