Community
Participate
Working Groups
build I20040420-1300 - In a java editor, select a method and press Ctrl+Shift+G - the Search view appears active but does not have focus - the first toolbar button (New) has focus This makes search almost unusable by keyboard. I at first thought this was a problem in the workbench, but choosing Window > Show View > Search works OK (whether or not the view is open yet).
I can't reproduce this on I-Build 2004-04-20-13:00
This only occurs if "Run user actions in background where possible" is unchecked. Apparently the dialog that pops up throws off focus.
This is part of a general set of checks we need to do w.r.t parenting of dialogs.
There seems to be a race condition here between the dialog closing and the search view switching between showing its progress page and the results page. The flow of control looks something like: - search action is run - it shows the search view, giving its search results table focus - the search job is started - the workbench reacts and opens the progress dialog - the search view reacts and switches to showing the "Searching..." page - the search job completes - the workbench reacts and closes the progress dialog - in doing so, SWT tries to restore focus to the results table - but it is not visible so this fails - SWT sets focus to the shell's first control: the toolbar - the search view reacts and switches back to showing the results page - focus is left on the toolbar This doesn't always occur because the workbench starts separate workbench jobs to open and close the dialog, so the search view's reaction to job completion sometimes runs first and makes the results table visible again before SWT tries to restore focus to it. Some options we can try: - the search view could avoid switching pages and thereby avoid changing the visibility of controls - the search view could explicitly set focus on the new page if the old page had focus - this could probably be done in PageBook itself - alternatively, PageBook could be changed to not change the visibility of the page controls, but just bring the current one to the top and allow it to hide the others - this is a little bit scary as there's a risk that obscured controls will keep focus - the progress support could be changed so that it brings down the dialog only after the search jobs have fully completed - Thomas, what are all the jobs involved here?
The problem here is more general than just the specific problem with search. Any user job that changes the visibility of controls that previously had focus will have the same problem.
Note that this problem is unrelated to the parenting of the shell (which is currently null).
Nick and I have gone through potential ideas with the workbench and we won't be able to do anything at the workbench level without potenitally breaking other views that are relying on the focus behaviour. It is not a good idea for us to force focus on anything ourselves as this could change explicit setFocus () calls elsewhere. This can happen potentially even switching to a different application which a search is ongoing. If the focus is returned to the window with the search view after the previous focus widget is no longer visible then you will get this behaviour. It is more pronounced when progress dialogs are involved of course which is why it is noticeable. We recommend that Search switch to the widget that is going to be visible at the end of the search before it starts the search job so as not to lose focus.
More simply, just avoid switching pages in the search view while the job is running. Even if the same control will have focus at beginning and end, you don't want to switch in the middle either.
Unfortunately, that's not an option. (the user wants to see the search results when they're available). I think the idea of explicitly changeing the focus when we switch off the "searching" widget is the right way to go. Not a general solution, of course.
I think resetting the focus control will be blocked by bug 56113
*** Bug 60098 has been marked as a duplicate of this bug. ***
We need either the blocking SWT PR fixed or to change our behaviour. I vote for the first option, of course.
setting to remind until bug 56124 changes
*** Bug 153005 has been marked as a duplicate of this bug. ***
.
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.
As of Bug 297510, restoring of focus is changed. i.e., focus is propagated to composite children. Cannot reproduce the issue anymore, assuming this is fixed now.
