Bug 53023

Summary: WebKit2: Type-to-select doesn't work in open <select> menu
Product: WebKit Reporter: Adam Roben (:aroben) <aroben>
Component: PlatformAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, glenn, jonlee, sam
Priority: P2 Keywords: InRadar, PlatformOnly
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows XP   
URL: data:text/html,%3Cselect%3E%3Coption%3Ea%3Coption%3Eb%3Coption%3Ec%3Coption%3Ed
Attachments:
Description Flags
Patch
darin: review-, darin: commit-queue-
Patch none

Description Adam Roben (:aroben) 2011-01-24 10:39:52 PST
To reproduce:

1. Go to data:text/html,%3Cselect%3E%3Coption%3Ea%3Coption%3Eb%3Coption%3Ec%3Coption%3Ed
2. Click on the <select>
3. Type 'c'

The selection in the popup menu doesn't change. Compare this to WebKit1, where the 'c' item is selected.
Comment 1 Jessie Berlin 2011-01-24 10:41:37 PST
<rdar://problem/8907678>
Comment 2 Jon Lee 2011-04-01 10:21:08 PDT
Created attachment 87878 [details]
Patch
Comment 3 Darin Adler 2011-04-01 11:59:07 PDT
Comment on attachment 87878 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=87878&action=review

review- because this breaks non-Mac builds

> Source/WebKit2/UIProcess/WebPopupMenuProxy.h:62
> +    virtual bool setFocusedIndex(int index, bool hotTracking = false) = 0;

By adding a new pure virtual function, you create the need to implement the function for all classes derived from it. That means Windows and Qt versions at least, in addition to the Mac version.

What is “hotTracking” for?

> Source/WebKit2/UIProcess/mac/WebPopupMenuProxyMac.mm:135
> +bool WebPopupMenuProxyMac::setFocusedIndex(int index, bool hotTracking)

Normally we omit the names of unused arguments. In WebCore we even have this set to warn, but it’s off in WebKit2 because it’s so hard to do for Objective-C methods.

I sugest omitting the argument names here.

> Source/WebKit2/UIProcess/mac/WebPopupMenuProxyMac.mm:139
> +}
>  } // namespace WebKit

Missing a blank line there.
Comment 4 Darin Adler 2011-04-01 12:07:43 PDT
Hmm, seems the Windows build works so maybe it’s only Qt that this breaks.
Comment 5 Jon Lee 2011-04-01 12:13:35 PDT
This is a Windows only bug, and it's because there was no connection being sent from Web to UI to update the popup menu.  So it should work on Windows, and I added the dummy impl for Mac.  I will look into getting it to compile for Qt.

(In reply to comment #4)
> Hmm, seems the Windows build works so maybe it’s only Qt that this breaks.
Comment 6 Jon Lee 2011-04-01 15:18:02 PDT
Created attachment 87926 [details]
Patch

Tried a different approach based on a suggestion from Anders: to use #ifdefs and targeting only Windows.  This way, we prevent needing to impl the pure virtual method on other platforms.
Comment 7 WebKit Commit Bot 2011-04-01 19:43:52 PDT
Comment on attachment 87926 [details]
Patch

Clearing flags on attachment: 87926

Committed r82763: <http://trac.webkit.org/changeset/82763>
Comment 8 Glenn Maynard 2012-02-04 08:24:40 PST
This isn't working correctly.

1. Open https://bugs.webkit.org/query.cgi
2. Click the Product combo box (currently showing "All").
3. Type "S", to select "Security".
4. Click the text box next to Words (or anywhere else).

The Product selection reverts to All.  It should remain on the user's selection, "Security".  This also happens if you tab to the next input instead of clicking.

This affects Chrome 16, and is a bit of a day-to-day headache.  I submitted forms with incorrect selections countless times until I figured out what was happening.  I still do it out of habit, since it's Firefox's behavior (as well as IE9's).
Comment 9 Adam Roben (:aroben) 2012-02-06 14:00:15 PST
(In reply to comment #8)
> This isn't working correctly.
> 
> 1. Open https://bugs.webkit.org/query.cgi
> 2. Click the Product combo box (currently showing "All").
> 3. Type "S", to select "Security".
> 4. Click the text box next to Words (or anywhere else).
> 
> The Product selection reverts to All.  It should remain on the user's selection, "Security".  This also happens if you tab to the next input instead of clicking.
> 
> This affects Chrome 16, and is a bit of a day-to-day headache.  I submitted forms with incorrect selections countless times until I figured out what was happening.  I still do it out of habit, since it's Firefox's behavior (as well as IE9's).

Chrome doesn't use WebKit2. I think it would be best for you to file a new bug.