<AWT Dev> Fwd: Your Report (Review ID: 1570033) - Shift+Tab no longer generates a KEY_TYPED event; used to with JRE 1.5
Peter Arrenbrecht
peter.arrenbrecht at gmail.com
Mon Aug 17 22:49:16 PDT 2009
On Thu, Jul 30, 2009 at 1:40 PM, Anton V. Tarasov<Anton.Tarasov at sun.com> 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: IncidentDaemon at sun.com <IncidentDaemon at sun.com>
>>> 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: peter.arrenbrecht at gmail.com
>>>
>>>
>>> ************************************************
>>> 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: peter.arrenbrecht at gmail.com
>>> 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 -
>>> peter.arrenbrecht at gmail.com)
>
More information about the awt-dev
mailing list