On Thu, Jul 30, 2009 at 1:40 PM, Anton V. Tarasov<[email protected]> wrote: > Peter, > > I've filed a bug - 6866784. It will be available at bugs.sun.com in a couple > of days. > > Thanks, > Anton.
Anton, I still cannot find this bug. And neither can I find the bug that seems to have been entered by the system on my behalf. To cite: <cite> We have determined that this report is a new bug and entered the bug into our internal bug tracking system under Bug Id: 6871299. You can monitor this bug on the Java Bug Database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6871299. </cite> Any ideas? -parren > Anton V. Tarasov wrote: >> >> Hi Peter, >> >> Peter Arrenbrecht wrote: >>> >>> Folks, >>> >>> I filed a bug about a missing KEY_TYPED event for Shift+Tab for JRE >>> 1.6 and up a while ago. Now I've found an additional case where it >>> manifests itself. If you have two text fields on a frame, the second >>> of which is setFocusTraversalKeysEnabled(false), then typing Shift+Tab >>> in the first field and then any letter will swallow that letter. This >>> is because the DefaultKeyboardFocusManager sets the >>> consumeNextKeyTyped flag on the Shift+Tab, which then suppresses the >>> next KEY_TYPED. Since the KEY_TYPED for Shift+Tab is missing, it >>> swallows the next normal key. >>> >> >> Indeed, this is a bug. >> >> You could file it via https://bugs.openjdk.java.net, or I may file it >> by myself via our internal bug tracker. What is the best for you? >> >>> While investigating this, I also wondered about the fix for bug >>> 6637607, which is mentioned in >>> DefaultKeyboardFocusManager.processKeyEvent(). It looks very >>> asymmetrical, the else only being present on the FORWARD case, but not >>> on the subsequent, basically copy-pasted blocks. Shouldn't one always >>> reset consumeNextKeyTyped right at the start of the if-block? Like so: >>> >>> if (focusedComponent.getFocusTraversalKeysEnabled() && >>> !e.isConsumed()) >>> { >>> consumeNextKeyTyped = false; >>> >>> or maybe like so: >>> >>> if (focusedComponent.getFocusTraversalKeysEnabled() && >>> !e.isConsumed()) >>> { >>> if (e.getID() == KeyEvent.KEY_PRESSED) consumeNextKeyTyped = >>> false; >>> >>> Thoughts? >>> -parren >>> >> >> You're right, the fix was not good enough. >> I think that consumeNextKeyTyped should be reset even higher, out of that >> block: >> >> if (e.getID() == KeyEvent.KEY_PRESSED) >> consumeNextKeyTyped = false; >> >> if (focusedComponent.getFocusTraversalKeysEnabled() && >> !e.isConsumed()) >> { >> >> It would fix the problem you've described above. >> >> Thanks, >> Anton. >> >> >> >>> >>> ---------- Forwarded message ---------- >>> From: [email protected] <[email protected]> >>> Date: Thu, Jul 23, 2009 at 5:33 PM >>> Subject: Your Report (Review ID: 1570033) - Shift+Tab no longer >>> generates a KEY_TYPED event; used to with JRE 1.5 >>> To: [email protected] >>> >>> >>> ************************************************ >>> Dear Java Developer, >>> >>> Thank you for your interest in improving the quality of Java Technology. >>> >>> Your report has been assigned an internal review ID of 1570033, which >>> is NOT visible on the Sun Developer Network (SDN). >>> >>> Please be aware that the large volume of reports we receive sometimes >>> prevents us from responding individually to each message. >>> >>> If the information is determined to be a new Bug or RFE, or a >>> duplicate of a known Bug or RFE, you will receive a followup email >>> containing a seven digit bug number. You may search for, view, or >>> vote for this bug in the Bug Database at http://bugs.sun.com/. >>> >>> If you just reported an issue that could have a major impact on your >>> project and require a timely response, please consider purchasing one >>> of the support offerings described at >>> http://developers.sun.com/services/. >>> >>> The Sun Developer Network (http://developers.sun.com) is a free >>> service that Sun offers. To join, visit >>> http://developers.sun.com/global/join_sdn.html. >>> >>> For a limited time, SDN members can obtain fully licensed Java IDEs >>> for web and enterprise development. More information is at >>> http://developers.sun.com/prodtech/javatools/free/. >>> >>> Thank you for using our bug submit page. >>> >>> Regards, >>> Java Developer Bug Report Review Team >>> >>> >>> >>> --------------------------------------------------------------- >>> >>> >>> Date Created: Thu Jul 23 09:33:33 MDT 2009 >>> Type: bug >>> Customer Name: Peter Arrenbrecht >>> Customer Email: [email protected] >>> SDN ID: >>> status: Waiting >>> Category: java >>> Subcategory: classes_awt >>> Company: codewise.ch >>> release: 6u10 >>> hardware: x64 >>> OSversion: ubuntu >>> priority: 4 >>> Synopsis: Shift+Tab no longer generates a KEY_TYPED event; used to >>> with JRE 1.5 >>> Description: >>> FULL PRODUCT VERSION : >>> java version "1.6.0_14" >>> Java(TM) SE Runtime Environment (build 1.6.0_14-b08) >>> Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode) >>> >>> >>> ADDITIONAL OS VERSION INFORMATION : >>> Linux sapient 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC >>> 2009 x86_64 GNU/Linux >>> >>> >>> A DESCRIPTION OF THE PROBLEM : >>> If I type Shift+Tab under JRE 1.5, I get a KEY_TYPED event. I do not >>> get it with JRE 1.6 and OpenJDK 7. >>> The KEY_TYPED event is only missing for Shift+Tab. Ctrl+Tab is OK, and >>> Shift+Enter is OK as well. >>> >>> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : >>> Run the app provided below. Then press Shift+Tab and watch stdout. >>> >>> EXPECTED VERSUS ACTUAL BEHAVIOR : >>> EXPECTED - >>> This is what JRE 1.5 emits when pressing Shift+Tab: >>> >>> PRESSED: code=16, char=65535, mods=1, action=false >>> PRESSED: code=9, char=9, mods=1, action=false >>> TYPED: code=0, char=9, mods=1, action=false >>> RELEASED: code=9, char=9, mods=1, action=false >>> RELEASED: code=16, char=65535, mods=0, action=false >>> >>> ACTUAL - >>> Under JRE 1.6 and a preview of OpenJDK 7, I get only: >>> >>> PRESSED: code=16, char=65535, mods=1, action=false >>> PRESSED: code=9, char=65535, mods=1, action=false >>> RELEASED: code=9, char=65535, mods=1, action=false >>> RELEASED: code=16, char=65535, mods=0, action=false >>> >>> The TYPED event is missing. >>> >>> REPRODUCIBILITY : >>> This bug can be reproduced always. >>> >>> ---------- BEGIN SOURCE ---------- >>> import java.awt.AWTEvent; >>> import java.awt.EventQueue; >>> import java.awt.Toolkit; >>> import java.awt.event.KeyEvent; >>> >>> import javax.swing.JFrame; >>> import javax.swing.JPanel; >>> import javax.swing.JTextField; >>> >>> public class KeyEvents >>> { >>> >>> public static void main( String[] args ) >>> { >>> EventQueue queue = new EventQueue() >>> { >>> @Override >>> protected void dispatchEvent( AWTEvent _event ) >>> { >>> if (_event instanceof KeyEvent) >>> log( (KeyEvent) _event ); >>> super.dispatchEvent( _event ); >>> } >>> }; >>> Toolkit.getDefaultToolkit().getSystemEventQueue().push( >>> queue ); >>> >>> JFrame frame = new JFrame( "KeyEvents" ); >>> JPanel panel = new JPanel(); >>> frame.add( panel ); >>> panel.add( new JTextField( 20 ) ); >>> panel.add( new JTextField( 20 ) ); >>> frame.pack(); >>> frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); >>> frame.setVisible( true ); >>> } >>> >>> protected static void log( KeyEvent _e ) >>> { >>> System.out.println( idText( _e.getID() ) + ": code=" + >>> _e.getKeyCode() + ", char=" + (int) _e.getKeyChar() >>> + ", mods=" + _e.getModifiers() + ", >>> action=" + _e.isActionKey() ); >>> } >>> >>> private static String idText( int _id ) >>> { >>> switch (_id) { >>> case KeyEvent.KEY_PRESSED: >>> return "PRESSED"; >>> case KeyEvent.KEY_TYPED: >>> return "TYPED"; >>> case KeyEvent.KEY_RELEASED: >>> return "RELEASED"; >>> default: >>> return Integer.toString( _id ); >>> } >>> } >>> >>> } >>> >>> ---------- END SOURCE ---------- >>> workaround: >>> comments: (company - codewise.ch , email - >>> [email protected]) >
