United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6995891 : JAWS will occasionally stop speaking focused objects as user TABs -> problem with message queue

Details
Type:
Bug
Submit Date:
2010-10-28
Status:
Closed
Updated Date:
2014-02-12
Project Name:
JDK
Resolved Date:
2013-08-28
Component:
client-libs
OS:
other
Sub-Component:
javax.accessibility
CPU:
other
Priority:
P2
Resolution:
Fixed
Affected Versions:
2.0.1
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

Description
Occasionally JAWS would get into a state where it would cease to speak new objects that gain focus as the user navigates through the Java application using the Tab key.  Debugging report from Freedom Scientific notes that JAWS was still receiving events from the Java Access Bridge but the events being received were behind what was actually happening in the Java Swing application.  For example, JAWS would receive a Focus Gained event but the event was not for the object that actually had focus, instead the event was for the object that just lost focus.

                                    

Comments
SQE is ok to take the fix in 7u60.
                                     
2013-12-08
Re 7u60-critical-request, please refer to the discussion at JDK-8028531.
                                     
2013-12-07
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43de418f1345
User:  lana
Date:  2013-10-01 17:37:37 +0000

                                     
2013-10-01
The environment for this is any supported Windows version.
                                     
2013-10-01
URL:   http://hg.openjdk.java.net/jdk8/awt/jdk/rev/43de418f1345
User:  art
Date:  2013-08-28 13:28:52 +0000

                                     
2013-08-28
Need to change this from closed to fixed
                                     
2013-08-28
Somehow this fix didn't get in JAB 2.0.2.  It will be in JDK 8.
                                     
2013-08-13
EVALUATION

See Suggested Fix.
                                     
2010-11-19
SUGGESTED FIX

The problem is believed to be in the function WinAccessBridge::receiveAQueuedPackage in WinAccessBridge.cpp.  In every case in which the bug occurs (according to the Freedom Scientific engineer), the function messageQueue->getRemoveLockSetting returns TRUE instead of FALSE. When this happens, the first message in the queue is not processed.  Since the function WinAccessBridge::receiveAQueuedPackage does not post the AB_MESSAGE_QUEUED message again, once this happens, the message queue will always be at least one message behind what is actually happening since the number of AB_MESSAGE_QUEUED messages received will always be less than the number of messages in the queue.

Recommendation is to add the line:
  PostMessage(dialogWindow, AB_MESSAGE_QUEUED, (WPARAM) 0, (LPARAM) 0);
to the "else" clause of the "if" statement
  if (messageQueue->getRemoveLockSetting() == FALSE) {
-> specifically right after the line:
  PrintDebugString("  unable to dequeue message; remove lock is set");
                                     
2010-10-28



Hardware and Software, Engineered to Work Together