Bug 14251 - onchange handler for select controls doesn't fire when changing via keyboard
Summary: onchange handler for select controls doesn't fire when changing via keyboard
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 523.x (Safari 3)
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL: http://bugs.webkit.org/attachment.cgi...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-20 16:47 PDT by Matt Perry
Modified: 2007-06-27 23:19 PDT (History)
2 users (show)

See Also:


Attachments
patch (2.82 KB, patch)
2007-06-20 17:47 PDT, Matt Perry
aroben: review-
Details | Formatted Diff | Diff
patch without casts (1.50 KB, patch)
2007-06-26 11:46 PDT, Matt Perry
aroben: review+
Details | Formatted Diff | Diff
remake of above patch (1.52 KB, patch)
2007-06-27 16:06 PDT, Matt Perry
aroben: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Perry 2007-06-20 16:47:37 PDT
I think the fix for 13857 causes this problem.  Repro steps:
1. Load the above URL in Safari for Windows (it's the test case for 13857).
2. Focus the select control, then type "t" and hit Enter.
3. The selection changes, but no message is displayed.  The onchange handler didn't fire.
4. If you change the selection with the mouse, or cause the popup to open, the onchange handler will fire.

What's happening is that saveLastSelection(); is getting called before firing the onchange event, which actually saves the *current* selection (it changes immediately when you type "t").  Immediately after that, there's a check in menuListOnChange to see if the current selection is the same as the one we just saved, which of course it is.

This doesn't happen in the mac port because there is platform-specific code guarded by ARROW_KEYS_POP_MENU that calls menuListOnChange before we get to the above code.
Comment 1 Matt Perry 2007-06-20 17:47:38 PDT
Created attachment 15151 [details]
patch

No regression test needed.  fast/forms/select-double-onchange.html was failing if ARROW_KEYS_POP_MENU = 0 in HTMLSelectElement.cpp (which it is on the Windows port).  This patch fixes that.
Comment 2 Darin Adler 2007-06-21 23:49:45 PDT
Comment on attachment 15151 [details]
patch

Needs a layout test. We require tests for bug fixes like this one so they don't regress in the future.

Fix itself looks pretty good, although the (size_t) casts don't see to be part of the fix (and so should be done separately).
Comment 3 Matt Perry 2007-06-22 11:10:43 PDT
I don't understand.  This is a bug fix for a broken layout test (which only fails if ARROW_KEYS_POP_MENU = 0).  fast/forms/select-double-onchange.html IS the layout test for this fix.
Comment 4 Darin Adler 2007-06-22 13:56:09 PDT
Comment on attachment 15151 [details]
patch

Oops, my mistake. Putting back up for review.
Comment 5 Adam Roben (:aroben) 2007-06-26 00:34:43 PDT
Comment on attachment 15151 [details]
patch

Remove the (size_t) casts and I think we have a winner.
Comment 6 Matt Perry 2007-06-26 11:46:25 PDT
Created attachment 15253 [details]
patch without casts

Same as above patch, but without the size_t casts.
Comment 7 Adam Roben (:aroben) 2007-06-26 12:43:55 PDT
Comment on attachment 15253 [details]
patch without casts

r=me
Comment 8 Mark Rowe (bdash) 2007-06-26 22:12:14 PDT
Hrm, svn-apply claims the patch is invalid?
Comment 9 Matt Perry 2007-06-27 16:06:01 PDT
Created attachment 15281 [details]
remake of above patch

This one should actually apply.
Comment 10 Adam Roben (:aroben) 2007-06-27 20:53:40 PDT
Comment on attachment 15281 [details]
remake of above patch

r=me
Comment 11 Mark Rowe (bdash) 2007-06-27 23:19:19 PDT
Landed in r23845.