Community
Participate
Working Groups
Build Identifier: M20100211-1343 The setFocus() method is not called on a detached view when the user clicks outside of the client area (view "frame", tab, and title bar area). The setFocus() method is called as expected when the user clicks anywhere in the client area. When attached, the setFocus() methods is called as expected when clicking on the view's tab. Reproducible: Always Steps to Reproduce: 1. Open two views. 2. Detach one view. 3. Set a breakpoint on setFocus() for each view and alternately click on each and observe if the breakpoint is hit.
Yes, it seems if I click on the folder's area where the toolbars are inserted, setFocus() is not getting called. I can reproduce this on Windows 7 with I20100429-1549.
Yep, good one. Likely the reason that this hasn't been reported is that the focus does actually end up in the control even in the scenarios where 'setFocus' isn't explicitly called. For most views this is sufficient but could cause issues in complex views that have, for example, a 'search/filter' edit control that should have gotten the focus. I suspect that the current behavior is just restoring the KB's focus to where ever it was last time the shell was active. Perhaps the fix is to call 'setFocus' from within the 'activate' code ?
(In reply to comment #2) Hi Mike a I are on the same team and we were discussing your comment. I'm not sure about the KB focus on restart but as soon as Mike pointed this bug out it occurred to me that one workaround option we have is to trigger off of Part Activation events which we already have code for and manually call setFocus. Our Team Lead Paul Gramann suggested that might be what you meant when you mentioned "activation". Is this also the fix you were suggesting for Eclipse or was the suggestion only for us to use as a workaround. Are there any drawbacks you can think of to using Part Activation events?
Hi Eric, Any estimate on the timeframe to evaluate Dilton's proposed workaround or a possible fix? Thanks.
Mike, thanks for the ping. I don't see a particular downside to having a part listener directly call 'setFocus' as a workaround but I haven't checked to ensure that in the case that's failing you actually get the event... As far as a fix time frame we're too late in the cycle to fix this for 3.6 (we're in RC3 now which means only 'stop ship' fixes are accepted). I've marked this defect for work in 3.7, if the suggested workaround fails for some reason ping back on the defect and I'll see if I can figure something out...
Eric, thanks for the response. Instead of calling setFocus() directly, as a workaround we decided to move the code we had in setFocus() to it's own method and call that from partActivated(). It seems this is working for us.
I've just spent some time tracking down the issue here... There's an optimization in the PartPane#setFocus() method that checks whether the focus is already set using SWTUtils.isFocusAncestor. Unfortunately in the scenario here clicking on the 'empty' area in the tab causes the DW to go active which forces the focus to the first control that can take it so this will always return true (meaning that we don't call the Part's setFocus). The obvious fix is to remove the optimization but doing so results in 3 calls to the part's setFocus method: 1) Thread [main] (Suspended (breakpoint at line 188 in SampleView)) SampleView.setFocus() line: 188 ViewPane(PartPane).setFocus() line: 331 WorkbenchPage$3.run() line: 629 SafeRunner.run(ISafeRunnable) line: 42 Platform.run(ISafeRunnable) line: 888 WorkbenchPage.activatePart(IWorkbenchPart) line: 624 WorkbenchPage.setActivePart(IWorkbenchPart, boolean) line: 3533 WorkbenchPage.requestActivation(IWorkbenchPart) line: 3077 ViewPane(PartPane).requestActivation() line: 278 ViewPane(PartPane).setFocus() line: 324 ViewStack(PartStack).presentationSelectionChanged(IPresentablePart) line: 837 PartStack.access$1(PartStack, IPresentablePart) line: 823 PartStack$1.selectPart(IPresentablePart) line: 137 TabbedStackPresentation$1.handleEvent(TabFolderEvent) line: 133 (The original click) 2) Thread [main] (Suspended (breakpoint at line 188 in SampleView)) SampleView.setFocus() line: 188 ViewPane(PartPane).setFocus() line: 331 ViewStack(PartStack).presentationSelectionChanged(IPresentablePart) line: 837 PartStack.access$1(PartStack, IPresentablePart) line: 823 PartStack$1.selectPart(IPresentablePart) line: 137 TabbedStackPresentation$1.handleEvent(TabFolderEvent) line: 133 DefaultTabFolder(AbstractTabFolder).fireEvent(TabFolderEvent) line: 269 DefaultTabFolder(AbstractTabFolder).fireEvent(int, AbstractTabItem) line: 278 DefaultTabFolder.access$1(DefaultTabFolder, int, AbstractTabItem) line: 1 DefaultTabFolder$2.handleEvent(Event) line: 88 (CTF Selection event) 3) Thread [main] (Suspended (breakpoint at line 188 in SampleView)) SampleView.setFocus() line: 188 ViewPane(PartPane).setFocus() line: 331 PresentablePart.setFocus() line: 190 TabbedStackPresentation$1.handleEvent(TabFolderEvent) line: 94 DefaultTabFolder(AbstractTabFolder).fireEvent(TabFolderEvent) line: 269 DefaultTabFolder(AbstractTabFolder).fireEvent(int) line: 274 DefaultTabFolder(AbstractTabFolder).handleMouseDown(Point, MouseEvent) line: 344 AbstractTabFolder$3.mouseDown(MouseEvent) line: 78 (Mouse Down on CTF) A proper fix for this defect would require a non-SWT-based mechanism to prevent the different attempts to call 'setFocus' on the part but this may be quite complex to do... Unless we get a DUP of this defect I'd prefer to leave the behavior as is rather than opening potential regressions. Adjusting milestone... <sigh>, I tried...
Hi Eric, We have a good work-around, so leaving this this is-as for now is OK with us. Thanks much for looking into this. Mike
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
