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.
Steps to reproduce: 1. Select a node in the filesystems tab of explorer 2. Shift-F10 to bring up context menu 3. right arrow on "new" 4. use up and down arrows to select different components: the IDE locks up and you can no longer navigate via keyboard, using the mouse will unlock everything
Peter : a11y is a module, and your desribed pottential bug is in the core !!!!!!!!! Forte vs. NetBeans? build number ? jdk version ? Without additional information we cannot resolve this one. closed as INVALID. Please add additional information. Thanks in advance.
x
Reopening this bug: please do not close bugs filed by QA if they contain insufficient information, but rather tell us what information is needed and allow QA to close as necessary. This is a P1 bug, it can _not_ be closed or it might slip through the cracks. the additional information that was requested is 1) This bug was found in FFJ 2) this was found in the orion trunk build from May 3, 2002 3) under JDK 1.4
version -> FFJ 4.0 ea I cannot reproduce on [orion](020501_1) CE/EE & [jdk1.4](fcs) & Solaris 5.8(CDE). Is it reproducible ? Attach thread-dump, ASAP !!!
> This is a P1 bug, it can _not_ be closed or it might slip through > the cracks. this is _not_ P1 bug. The IDE does not lock, only that the keyboard navigation stops working. Don't abuse the priority. P1 is reserved for real deadlock, crash, dataloss types of bugs.
> Reopening this bug: > please do not close bugs filed by QA if they contain insufficient > information, but rather tell us what information is needed and allow > QA to close as necessary. the process we use is different. If the bug report is missing basic information like the build number, JDK version, OS version and we are not able to reproduce, then it will be closed as INVALID. Not that the bug is INVALID but the report is. Whoever filed the report then can add the needed information and reopen the issue. We are receiving a lot of bug reports from all over the world every day. There is not enough time and energy to teach _everybody_ how to file a good bug report.
Peter, Info is still insufficient for us. We tried to reproduce both on Solaris, Windows, with several latest ffj trunk builds, still everything works ok for us. I'm marking as worksforme now, please attach more info, about your OS window manager, its version, any special window manager settings? Please try to reproduce under various window managers if you can, also tell us if you're able to see the bug every time or only sometimes using steps you described. Thanks.
Here is some more information to help reproduce this: 1) I think what is happening is that for some reason focus is changing from the open context menu back to the explorer window. So, as I hit the arrow keys, the item selected is changing but since the context menu is still open (in front of the the explorer window) I didn't see it. 2) I am running Solaris 9 in 64-bit mode. I have reproduced this using both the 32-bit and 64-bit JDK. 3) I'm using CDE, the version which is installed by default w/ Sol9. 4) the latest build with which I have reproduced this is the FFJ Orion trunk kit (EE) from May 6, 2002, installed using ZIP file, not installer. (*update: I just reproduced it on a collegue's Sol9 box, configured the same as mine and using the May 7th build) I can consistently reproduce it on my machine and on another Sol9 machine. I just tried it on a Sol8 (also 64-bit mode) machine and I could not reproduce it, so the only clue I can give you is that it might be Sol9 specific. Additionally, I'm not going to argue about whether it should be P1 or P2, since either way it will most likely get dealt with, but my reason for filing it as P1 is that from an accessibility standpoint having a keyboard-deadlock is the same for the handicapped user as a complete deadlock. One last thing, I'd like to apologize for taking an adversarial tone in my earlier post. I don't want to annoy anyone, I just want to ship a quality FFJ/Netbeans.
> One last thing, I'd like to apologize for taking an adversarial tone > in my earlier post. No problem. I am not the one with the finest manner either. Back to the problem: it looks like something unexpected is going on on CDE version installed in Solaris 9. I see this problems happen from time to time and it's really hard to fix it in NB because the root cause lies somewhere between the JVM and the window manager. What's we are doing in NB Core code is - ask Swing if any menu popup is active - if it says yes, then route all keyboard events to that popup Looks like Swing does not report the active popup to NB code.
I finally got access to Solaris 9 machine. At the moment when the user cannot drive the popup using keyboard, NB code does not see any key events from JVM. Thus it cannot drive the popup at all.
It's reproducible on Solaris 9 & [jdk1.4](fcs) but it isn't reproducible with [jdk1.4.1](build 10).
added FFJ40_WAV_APPROVED keyword
More evaluation: - this bug does not occur in NB 3.4-dev on Sol9/JDK 1.4.0 - this bug does not occur in FFJ 4.0/NB 3.3.x on Sol9/JDK 1.4.1-b11 In FFJ 4.0/NB 3.3.x and before we recreate the submenu after it's being displayed. Besides the fact that this causes flickers it seems that this coding technique triggers a bug in JDK 1.4.0/Sol9 which does not happen on JDK 1.4.1 beta. In NB 3.4-dev we rewrite the menu code to avoid recreation of menu contents after it's being displayed. Therefore this bug does not happen even on JDK 1.4.0.
With the above evaluation I am closing this bug as FIXED in NB 3.4
*** Issue 23577 has been marked as a duplicate of this issue. ***
Due to last Trungs comment -> closed.