Bug 19396 - [CCombo] CCombo dropdown causes Shell to lose Focus
Summary: [CCombo] CCombo dropdown causes Shell to lose Focus
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 major with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: Lakshmi P Shanmugam CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-06-05 14:52 EDT by Randy Hudson CLA
Modified: 2019-09-06 16:05 EDT (History)
10 users (show)

See Also:


Attachments
Sample technique without flashing (4.69 KB, text/plain)
2005-05-25 14:57 EDT, Chris Gross CLA
no flags Details
patch (5.93 KB, patch)
2006-07-20 14:09 EDT, Kevin Barnes CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Randy Hudson CLA 2002-06-05 14:52:03 EDT
Dropping down a CCombo causes the owning Shell to lose focus.  This is *very* 
distracting to the user, since the titlebar color changes (and the Active 
ViewPart), and CCombos are often found on the Toolbar adjacent the titlebar.  
Also, there can be other unintended side effects if the hosting control is 
paying attention to focus, and doesn't anticipate its shell to lose foucs.
Comment 1 Mike Wilson CLA 2002-06-05 14:58:48 EDT
It's not likely that we will be able to do anything about this for R2.0.
Comment 2 Chris Gross CLA 2005-05-25 12:12:39 EDT
Could a technique similar to the one thats used for the HoverHelp example be 
used here?  In the HoverHelp example, the popup window is never open()-ed, 
just set visible.  Therefore it never gains focus.  I've played around with it 
a little and the only problem I can see right now, is that if you do give the 
window focus (i.e. click on it, like the user will have to click on an item in 
the CCombo's list), then for whatever reason, the window will actually receive 
focus the next time its setVisible(true).  This is on winXP.  
Comment 3 Chris Gross CLA 2005-05-25 12:30:57 EDT
I've found that if I setActive() the parent shell, the focus will not return 
to the popup shell when it is again made visible.  So basically the popup 
shell only recieves focus for a split second to actually process the user's 
click, then the parent is made active and it is made invisible.  The result is 
a very very minor flash when the user clicks.
Comment 4 Chris Gross CLA 2005-05-25 14:57:20 EDT
Created attachment 21766 [details]
Sample technique without flashing

I'm attaching a small sample that I wrote.  It shows the basic concept.  It
works rather well on XP.  I believe the concept itself is portable but I'm not
sure if there are quirks on the other platform that might need to be accounted
for (probably).
Comment 5 Veronika Irvine CLA 2005-05-31 07:58:19 EDT
Chris, thanks for the suggestion.  However, if the list does not have focus 
when it becomes visible, the user can not use the keyboard (up and down arrows 
or typing first letter of match) to select an item from the list.  This breaks 
accessibility and is inconsistent with the behaviour of the native Combo 
widget.
Comment 6 Kevin Barnes CLA 2006-07-20 14:09:52 EDT
Created attachment 46591 [details]
patch

I started looking at this yesterday. It's possible to leave the focus in the Text and forward the events to the list. Of course if the user clicks on the list it will be given focus, but I don't know of a work around for that.
Comment 7 lembas CLA 2010-10-06 10:52:29 EDT
Is it possible to implement CCombo without using Shell?
Comment 8 lembas CLA 2010-10-07 07:41:26 EDT
I tried it on Eclipse 3.6.1 / Ubuntu 10.04. The main shell does not lose the focus but the ViewPart containing the CCombo still loses the focus. 

In ideal case, CCombo should never capture the focus but at least it can behave like the content assist shell in Eclipse. It captures keyboard events and also mouse wheel without getting the focus from the EditorPart. EditorPart does not lose focus until you clicked in the content assist shell.
Comment 9 Eclipse Webmaster CLA 2019-09-06 16:05:56 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.