JDK-6995891 : JAWS will occasionally stop speaking focused objects as user TABs -> problem with message queue
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.accessibility
  • Affected Version: 2.0.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: other
  • CPU: other
  • Submitted: 2010-10-28
  • Updated: 2014-02-12
  • Resolved: 2013-08-28
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 7 JDK 8
7u60Fixed 8 b110Fixed
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.
08-12-2013
Re 7u60-critical-request, please refer to the discussion at JDK-8028531.
07-12-2013
The environment for this is any supported Windows version.
01-10-2013
Need to change this from closed to fixed
28-08-2013
Somehow this fix didn't get in JAB 2.0.2. It will be in JDK 8.
13-08-2013
EVALUATION See Suggested Fix.
19-11-2010
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");
28-10-2010