This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | A11Y: Tab key is consumed by Explorer | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jaromir Uhrik <juhrik> |
| Component: | Window System | Assignee: | Milos Kleint <mkleint> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | CC: | saubrecht |
| Priority: | P2 | Keywords: | A11Y, FOCUS |
| Version: | 4.x | ||
| Hardware: | PC | ||
| OS: | Windows ME/2000 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | alternative fix | ||
|
Description
Jaromir Uhrik
2005-02-01 10:13:30 UTC
I think it should be fixed directly in explorer like components, Swing's focus cycle traversals should be properly defined and then Tab will be switching among components in focus cycle traversal (or do nothing). The tab key is not consumed by the explorer. It correctly lets the framework pass the focus along. The next thing in the chain is (according to the focus lost event) the tab control: Focus event: java.awt.event.FocusEvent[FOCUS_LOST,permanent,opposite=org.netbeans.core.windows.view.ui.tabcontrol.TabbedAdapter[,0,0,330x488,layout=java.awt.BorderLayout,alignmentX=null,alignmentY=null,border=javax.swing.border.LineBorder@13f7cd2,flags=320,maximumSize=,minimumSize=,preferredSize=]] on org.openide.explorer.view.TreeView$ExplorerTree[,0,0,328x465,alignmentX=null,alignmentY=null,border=javax.swing.border.EmptyBorder@1b277f0,flags=360,maximumSize=,minimumSize=,preferredSize=,editable=true,invokesStopCellEditing=false,largeModel=false,rootVisible=false,rowHeight=18,scrollsOnExpand=true,showsRootHandles=true,toggleClickCount=0,visibleRowCount=20] TabbedAdapter.setFocusable(false) seems to cure the problem. (at leat on macosx) Dafe, any idea if this could be harmful? I'm always kind of defensive when dealing with focus. it's not ok. it seems the that focus cycle gets out of the TabbedAdapter component onto the whole window and that assigns it to the first component in it.. usually it's the topleft explorer. that's wrong. fix by copy&modify of LayoutFocusTraversalPolicy. Create a focus cycle within a TabbedContainer, never allowing the focus to leave the active TopComponent. The fix seems to work with the most common components in the IDE desktop, but there could be special cases that could fail. Therefore I would prefer not to integrate into beta1, but give it more testing beforehand.. Checking in swing/tabcontrol/src/org/netbeans/swing/tabcontrol/TabbedContainer.java; /cvs/core/swing/tabcontrol/src/org/netbeans/swing/tabcontrol/TabbedContainer.java,v <-- TabbedContainer.java new revision: 1.12; previous revision: 1.11 I have tested the use tab in most of IDE components and it seems to be fine. Verified in dev build #200502241900; jdk1.5.0_02-b07 Created attachment 26832 [details]
alternative fix
i'm fixing issue 61092 and found out that the problem is in TabbedContainer. when it's used in a standalone dialog window (e.g. properties dialog) it somehow consumes the focus and it's not possible to navigate the properties dialog with a tab key without a mouse-click first. after some experiments i discovered that both issues (54264 and 61092) are fixed just by removing 'setFocusable( true )' from the TabbedContainer (compare to revision 1.11). then the focus works as expected both in the properties dialog and main window modes as well. milos, what do you think? how come the tabbedcontainer is used in dialogs? i have no problem with it, but please test extensively, I remember this bug to be somewhat esoteric in nature.. the property sheet uses tab control and the property sheet can be embedded in a dialog window. tested on winxp, jdk 1.4-1.6 Checking in TabbedContainer.java; /cvs/core/swing/tabcontrol/src/org/netbeans/swing/tabcontrol/TabbedContainer.java,v <-- TabbedContainer.java new revision: 1.16; previous revision: 1.15 done |