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.

Bug 17449 - [core] Arrows navigation in tabbed top components container is awkward
Summary: [core] Arrows navigation in tabbed top components container is awkward
Status: CLOSED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: David Simonek
URL:
Keywords: A11Y
: 16402 17182 17183 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-11-09 10:09 UTC by jrojcek
Modified: 2008-12-23 09:33 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jrojcek 2001-11-09 10:09:57 UTC
When tabbed pane of top components is focused and left/right arrow is pressed
then expected behavior is that tabbed pane is switched to previous/next tab and
the tab is focused so that user can use arrows again.

But sometimes (in editor) after switching tabs focus moves to top component so
that it is not possible to switch too tabs in a row.

This was reported against explorer and fixed in NbMainExplorer
(http://openide.netbeans.org/issues/show_bug.cgi?id=16192). But it should be
fixed on tabbed top components container level.
Comment 1 David Simonek 2001-11-09 10:58:08 UTC
long time ago this was implemented as a feature I think, coming from
nbui  discussion :-)
Comment 2 David Simonek 2001-11-14 13:00:52 UTC
I think this is as designed, because shortcuts Alt+arrows serve for
that purpose (to cycle between tabs) and it is working ok for me here.
Comment 3 jrojcek 2001-11-15 10:32:15 UTC
Yes, Alt+Arrows serve the purpose. But when tabbed pane is focused it
is possible with screen reader to read tab names and that is why it is
better to navigate in tabbed pane tabs when the tabbed pane is focused.

So when a tabbed TC container is focused then arrows should allow to
switch more tabs in a row. In current state it sometimes moves focus
to TC and sometimes doesn't. Try to open different TCs (source editor,
image viewer, bundle properties table) in editor window and use arrows
in focused tabbed pane. It seems that whether focus is moved or not
depends on TC. It should not.

Moving focus to TC after selecting new tab by mouse click is right,
but doing that when using keyboard arrows is not.
Comment 4 jrojcek 2001-11-19 14:17:03 UTC
*** Issue 16402 has been marked as a duplicate of this issue. ***
Comment 5 jrojcek 2001-11-19 14:24:00 UTC
*** Issue 17182 has been marked as a duplicate of this issue. ***
Comment 6 jrojcek 2001-11-19 14:26:58 UTC
*** Issue 17183 has been marked as a duplicate of this issue. ***
Comment 7 dpavlica 2001-11-22 13:54:23 UTC
Increase priority a bit. Its important because of accessibility. This 
bug could be really bewildering too for that case, where user has 
explorer & property view docked together.
Comment 8 _ ttran 2001-11-22 15:25:34 UTC
> So when a tabbed TC container is focused then arrows should allow to
> switch more tabs in a row. In current state it sometimes moves focus
> to TC and sometimes doesn't..

the focus is moved to the top component if the component declares that
it accepts focus.  Editor does, image doesn't.  That's the difference.

> Moving focus to TC after selecting new tab by mouse click is right,
> but doing that when using keyboard arrows is not.

Unfortunately it's very likely that it's impossible to distinguish
these two cases.  You must make the choice, eithera11y compliance or
usability.  (Irony intended :-(


Comment 9 Jan Chalupa 2001-11-27 11:51:42 UTC
Target milestone -> 3.3.1.
Comment 10 Jan Chalupa 2001-11-27 11:55:12 UTC
Target milestone -> 3.3.1.
Comment 11 David Simonek 2001-12-18 10:36:12 UTC
raising priority, should be tried to be adressed to 3.3.1
Comment 12 _ ttran 2001-12-18 23:50:21 UTC
before anyone's going to fix this bug, please take a look at bug 17958.
We have to decide if accessibility really requires tab handles to be
focusable.  If the answer is yes, then bug 17958 is probably
unavoidable (not only in Explorer as it is now).
Comment 13 David Simonek 2001-12-19 15:25:14 UTC
I'm not able to fix this bug, at least for now (for 3.3.1). As Trung
correctly pointed out, there is no good way how to distinguish between
mouse and keyboard triggered tab handler change.
I'm marking this as later, because correct solution exist I believe -
to write whole TabbedPaneUI ourselves (we already have one - for
example ArrowsTabbedPaneUI - however needs to be refactored for jdk
1.4) and handle transferring of focus more flexibly.
Other chance may be to convince Swing to enhance API for JTabbedPane
to allow for knwing trigger of state change.
Comment 14 Lukas Hasik 2002-01-10 18:05:07 UTC
changing target milestone
Comment 15 David Simonek 2002-02-20 13:14:42 UTC
reopening..
Comment 16 David Simonek 2002-02-20 13:15:08 UTC
Re-evaluation: I don't know how this can be fixed on our side. Closing
as wontfix, without Swing support for distinguishing between mouse and
keyboard gestures we're lost.
Comment 17 Quality Engineering 2003-07-01 16:03:18 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified.

Comment 18 Quality Engineering 2003-07-01 16:43:27 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.