http://bugs.winehq.org/show_bug.cgi?id=13374
Summary: ComboBoxEx list get selected on mouse button down and release Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs@winehq.org ReportedBy: dylan.ah.smith@gmail.com
Created an attachment (id=13272) --> (http://bugs.winehq.org/attachment.cgi?id=13272) comctl32: Added tests to show a ComboBoxEx bug caused by incorrect focus change
The quickest way to see the error is to use Wine's clone of wordpad. There are two dropdown lists (ComboBoxEx controls) that are on the toolbar. Click the button to drop down the list, then left click on an item in the list. You will probably notice that the wrong item is selected, and if you do it slowly (i.e. hold down the mouse button for a second then release it), then you will notice that the selection is made and the list disappears when the mouse button is pressed, and when it is released another selection is made even though the list has disappeared.
I ran wordpad on Windows XP SP2, and noticed that the correct behavior is the item is only selected when the mouse button is released.
Note that there are two other separate bugs that you might notice: - The font size is 0 to start with (richedit bug) - Selecting a new font size will give you an "Invalid number format" error when the control loses control (wordpad bug) - The selected items from the list are not applied until the combobox loses focus (wordpad bug)
I have submitted patches that fix these other bugs to the wine-patches mailing list.
I have done some created tests that show the bug is in ComboBoxEx from the comctl32 and not in ComboBox from the user32 dll. I have attached the patch that adds these, and will submit it to the wine-patches mailing list after I get the bug number to mention in the commit message.
I did some debugging, and to my suprise it was a call to SetFocus was rolling up the ComboBoxEx's list. Digging deeper I found it was actually the WM_KILLFOCUS call to the window that previously had focus, which was the ComboBox (a child of ComboBoxEx). The ComboBox saw that it was losing focus, and what was losing focus it didn't recognize as itself, it's edit control, or its list control, so it incorrectly decided to roll the dropdown up. It turns out that what was losing focus was an edit control that ComboBoxEx and child ComboBox control didn't know about created since, oddly enough, native Windows does not use the child ComboBox's edit control.
My tests for ComboBox and ComboBoxEx show what had focus before and after pressing the dropdown button, and selecting an item in the dropdown list. In both causes the top level (main) window had intial focus. With ComboBox the focus was correctly on the edit control after each of the mouse button up/down messages are sent. For ComboBoxEx the focus was supposed to be on ComboBox when the list is dropped down then on the edit control after it's rolled up, according to my crosstests, but instead it was on the edit control after the list is dropped down. Some debugging found that the focus was being changed to the ComboBox, but each time it did that, the ComboBoxEx was notified with a CBN_SETFOCUS command message, which had no case for it in the COMBOEX_Command function, so the default case was used. The default case contains two lines that sets the focus back to the edit control, thus causing the bug, however taking out those lines caused missing notifications of the change.
Hopefully this is enough information for someone else more familiar with the code to properly fix the problem.