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 29195 - FileArrayEditor is keyboard unfriendly
Summary: FileArrayEditor is keyboard unfriendly
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Property Editors (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: _ tboudreau
URL:
Keywords: A11Y, JDK_SPECIFIC
: 25584 29336 30155 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-12-01 20:09 UTC by _ gtzabari
Modified: 2008-12-23 10:55 UTC (History)
4 users (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 _ gtzabari 2002-12-01 20:09:50 UTC
dev build 200211290100

Previously if I tried mounting a directory and
entered "c:\ <enter>" the GUI would display the
contents of the root directory. Now it just sits
there.

Expected behavior:

If I enter "c:\" and press ENTER, the file chooser
should display the contents of that directory.

If I press "FINISH" it should mount "c:\"

If, however, I selected a directory inside "c:\"
before selecting "FINISH" it should mount *that*
directory instead

   I think this behavior will satisfy both
keyboard and mouse users.
Comment 1 akemr 2002-12-02 13:16:20 UTC
TemplateWizard issue
Comment 2 Jiri Rechtacek 2002-12-04 09:34:44 UTC
*** Issue 25584 has been marked as a duplicate of this issue. ***
Comment 3 Jiri Rechtacek 2002-12-04 09:35:15 UTC
Open File System Wizard. Select some type of file system. Type path to
  filesystem in File edit field. Finish button is not enabled, etc. It
is necessary to add listener to edit field.
Comment 4 pzajac 2002-12-06 13:36:21 UTC
*** Issue 29336 has been marked as a duplicate of this issue. ***
Comment 5 Jaromir Uhrik 2003-01-06 11:23:03 UTC
Version changed: 4.0 dev -> S1S 4.2
Comment 6 pzajac 2003-01-15 09:19:08 UTC
*** Issue 30111 has been marked as a duplicate of this issue. ***
Comment 7 pzajac 2003-01-16 09:00:08 UTC
*** Issue 30155 has been marked as a duplicate of this issue. ***
Comment 8 pzajac 2003-01-16 09:01:39 UTC
priority incresed because there is many the same reports
Comment 9 Jiri Rechtacek 2003-01-16 16:40:33 UTC
There is a problem with keyboard usability of FileArrayEditor (it used
in Mount Wizard for select the root of local filesystem or jar
filesystem). The editor doesn't fire enough changes of selectedFile
property and cannot select a folder/file direct by keyboard. Note: the
defect persists from 3.3.2 and 3.4 too, I vote for decrease a priority
back.
Comment 10 _ tboudreau 2003-01-23 19:52:51 UTC
Just started digging into this - there's a bunch of weirdness going
on here.  On Solaris, type "/" and the directory immediately switches
to the fs root, *and* the JTextArea loses focus.  For some entries,
the selected directory randomly switches back to my home directory,
or displays one directory name in the text area, and a different
on in the table.  

My initial impression is that the core problems are in JFileChooser;
also, fixes to this issue could cause strange problems on different
look and feels that implement the dialog differently.
Comment 11 _ tboudreau 2003-01-24 14:36:16 UTC
I think the initial problem is that in Metal L&F, the directory
selection component gets the initial focus.  It does respond, for
example, to the / character, but it does not fire changes.

I've written a variation which goes so far as to iterate the
component tree of the JFileChooser and find the JTextArea of
the file chooser, but so far none of my efforts to force focus
to it are working.
Comment 12 _ tboudreau 2003-01-24 15:21:56 UTC
More info:  Apparently there is a hack in the Wizard infrastructure
to force focus to the first component in the main panel (to work 
around focus being set to the container or someplace else on JDK 1.3).
 This is what is forcing focus to the wrong place, causing 
keyboard navigation not to work right.  In a stand-alone JFileChooser
dialog, focus is correctly set to the JTextArea inside it.

Jano, David Strupl tells me probably you did the work on the
original focus hack.  I'll dig around for it, but it would save me 
much time if you could let me know what and where this it is.
Comment 13 _ tboudreau 2003-01-24 17:05:42 UTC
This issue is caused by the fix for issue 17794.  If I comment
out line 214 in NbPresenter.java, "requestFocusForJdk14(comp);"
it works correctly on 1.4.1.

I also cannot reproduce issue 17794 with this line commented out - 
all wizards and dialogs work as intended with focus set correctly.

I have disabled the hack for JDK 1.4.1 and above, and it works
correctly.  I'm marking this as fixed, 1.4.1 specific.  If someone
is not dissatisfied with this, please reopen - I have a few other
P2 bugs to attend to, so at least for the time being, it working
on 1.4.1 may need to suffice.
Comment 14 pzajac 2003-01-29 13:19:45 UTC
It doesn't work. 
Example on my linux:
"/" <enter> show "/" dir
"/mydir" <enter> doesn't show dir "/mydir"
etc. 
Comment 15 _ tboudreau 2003-01-30 10:08:23 UTC
Petr, could you tell me what component *does* get focus when you
initially get to the file editor page of the wizard?  It works 
correctly on 1.4.1/Solaris.
Comment 16 _ tboudreau 2003-02-03 20:29:46 UTC
I've added some additional work in the AbstractAction created by
FileEditor.hackJFileChooser(), which should take care of this problem.

Note that it does not eliminate *all* keyboard issues - there is some
weirdness in the way JFileChooser does things, at least for the case
of Metal L&F.  In particular, there are some cases where a 
legitimate file name is present, but the file chooser returns
the selected file as null, and offers no way to find out what
the user actually typed.

To solve it properly, without depending on impl details
of its UI really requires writing our own UI for it or firing
bugs/enh requests at the JDK team.
Comment 17 bht 2003-02-06 19:17:18 UTC
The bug parade search does not show any hits for JFileChooser.

JFileChooser: If a file name is typed whose parent exists but the file
itself does not yet exist then nothing is returned.

This is easy to reproduce and easy to understand. In comparison try
any InstallShield installation. It will let you do this and it asks
you whether the new directory you typed should be created.

I am writing an installer in Java and found no way to do this.

http://developer.java.sun.com/developer/bugParade/bugs/4031440.html
tells me that I cannot use the AWT dialog because of broken file type
filtering.

So if you have good connections to the swing team maybe you can
address this more generally. I am a bit hesitating still to raise a
bug at this stage.
Comment 18 _ tboudreau 2003-02-06 20:03:15 UTC
I know there is at least a Sun internal issue on keyboard navigation
of JFileChooser.  The main problem is really that the L&F encapsulates
the components and such a little too well - you can't even usefully
subclass the Metal UI, because all of the components used are private,
so there's no contract that they won't change.  

If you're willing to live dangerously, you could play with the patch
I posted on nbdev the other day - it allows completions & such, and
makes it more keyboard friendly (but it's a major hack).

We are trying to get the situation with JFileChooser improved.
Comment 19 Marian Mirilovic 2003-09-04 12:37:56 UTC
verified in [nb_dev](20030904)