Bug 36314

Summary:

Text field "onchange" event is triggered if actual value unchanged

Product:

WebKit

Reporter:

Ivo Krab <ivo.krab>

Component:

WebCore Misc.

Assignee:

Emil A Eklund <eae>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

abarth, ap, commit-queue, darin, dglazkov, eric, webkit.review.bot

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
Patch	none
Patch	none

Ivo Krab

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

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

Emil A Eklund

Comment 1 2011-03-07 11:01:43 PST

Created attachment 84957 [details] Patch

Dimitri Glazkov (Google)

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

Emil A Eklund

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

Emil A Eklund

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

Dimitri Glazkov (Google)

Comment 5 2011-03-25 10:53:58 PDT

Comment on attachment 86864 [details] Patch ok.

WebKit Commit Bot

Comment 6 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>

WebKit Commit Bot

Comment 7 2011-03-25 12:08:52 PDT

All reviewed patches have been landed. Closing bug.

WebKit Review Bot

Comment 8 2011-03-25 12:16:24 PDT

http://trac.webkit.org/changeset/81978 might have broken Chromium Linux Release and EFL Linux Release (Build)

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