JDK-6404708 : b77 Reg: unable to enter directories in JFileChooser with "Focus Follows Mouse" gnome option
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,linux_2.6,solaris_10
  • CPU: generic,x86,sparc
  • Submitted: 2006-03-27
  • Updated: 2011-01-19
  • Resolved: 2006-04-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b81Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
In b77, on Solaris/Linux, run any application with JFileChooser (SwingSet2 
would do).
Open the file dialog. Try to enter into any directory by double-clicking.
Instead of entering the directory, its name will start to be edited instead.
Note that this is reproducible with all look and feels, only with Motif
L&F you just can't enter the directory (you can't edit a dir name in motif's 
file dialog). 

This is reproducible only with "Select windows when the mouse moves over them"
option selected in Gnome's System/Preferences/Windows dialog.

The bug was first mentioned on this thread:
  http://forums.java.net/jive/thread.jspa?messageID=97321&#97321

Since Swing didn't integrate into b77, and I've verified that it's not
reproducible on Swing's nightly builds prior to b77 sync with master,
I'm filing the bug against awt.

Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/mustang/6404708.1/
30-03-2006

EVALUATION Seem we have to skip non-NormalNotify events in XWindow as they causes us to skip mouse press state after the first press over any component when "focus follows mouse" model is used. But we have to check if some of them are Leave/Enter events and if so then use them to update cursor appropriately to keep 6242833 in fixed state.
30-03-2006

EVALUATION First I verified the component under the mouse isn't changing after a mouse press. Then tried "xev" with focus-follows-mouse and click-to-focus schemes and all crossing events are exactly the same: ButtonPress event, serial 25, synthetic NO, window 0x3e00001, root 0x48, subw 0x3e00002, time 78761246, (39,25), root:(202,147), state 0x10, button 1, same_screen YES EnterNotify event, serial 25, synthetic NO, window 0x3e00001, root 0x48, subw 0x0, time 78761246, (39,25), root:(202,147), mode NotifyGrab, detail NotifyInferior, same_screen YES, focus YES, state 272 KeymapNotify event, serial 25, synthetic NO, window 0x0, keys: 72 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ButtonRelease event, serial 25, synthetic NO, window 0x3e00001, root 0x48, subw 0x3e00002, time 78764011, (39,25), root:(202,147), state 0x110, button 1, same_screen YES LeaveNotify event, serial 25, synthetic NO, window 0x3e00001, root 0x48, subw 0x0, time 78764011, (39,25), root:(202,147), mode NotifyUngrab, detail NotifyInferior, same_screen YES, focus YES, state 16 But java (XWindow.handleCrossigEvent()) obtains extra crossing events with mode=NotifyGrab or mode=NotifyUngrab when focus-follows-mouse enabled. And that is why the second click in that double click sequence is treated as just a first click there and item name editing gets initiated. That's rather odd and seem java itself somewhere else filters non-Normal events because with click-to-focus scheme java doesn't receive these NotifyGrab/NotifyUngrab crossing events.
29-03-2006

EVALUATION Seem it regressed in b77 by the 6242833 fix. That fix was in passing every crossing event java obtain from Xsystem. But when the user presses mouse on item in FileChooser it initiates component exchange under the mouse. This is why XWindow recevieves a series of Enter/LeaveNotify from XContentWindow and XDialogPeer. As they now are transfering further java consider as mouse has been moved out the component (file name in this case) and then returned back. This results in visible single click on the file item.
28-03-2006