You noted that everything worked correctly with JavaFerret in your testing. To clarify, did you try tracking the focus with JavaFerret and did this work correctly? My hunch is that this is something to do with delivery of JAB events. I'll try to debug this further when I get a bit more time.

Related NVDA issue ticket: http://www.nvda-project.org/ticket/2870

(In reply to comment #1)
> To clarify, did you try tracking the focus with JavaFerret and did this work
> correctly?

James, you asked the right question. Appears I reported on JavaFerret incorrectly--notably regards the JavaEvents, Track Focus Events.

JavaMonkey-32 is displaying an identical tree and accessibility information for each active panel. But JavaFerret-32 is not tracking any JavaEvents or AccessibilityEvents with JRE 1.7, while the same document text generates both JavaEvents and AccessibilityEvents with JRE 1.6.

Stuart

I just inserted some test code right at the top of NVDA's JAB callbacks and tested with !LibreOffice 3.6.4 and JRE 1.7. We never receive any focus gained events, but we do receive active descendant change, state change and caret change events. Walking the tree works correctly. Note that we do receive focus gained events in Java applications such as the Java Control Panel.

As to how we get any interaction at all in LibreOffice without focus events, there are three reasons:
1. NVDA maps active descendant change events to focus events. This explains how we can access tree view items, list items, combo box items, etc.
2. NVDA maps some other events to focus events. For example, if a menu item or tab gets the focused or selected state (via a state change event), we map this to focus. This explains how we can access the menus.
3. When the foreground window changes such as opening a dialog, we receive a foreground win event (not via JAB). This explains how we can initially read dialogs when they appear.

Thanks so much for the detailed testing and bug reports here guys ! :-)
It is interesting that this is isolated to a change in the JDK version; no doubt the Java <-> UNO bridge for a11y is doing some suspect things - prolly we'll need a Java expert here too.

http://cgit.freedesktop.org/libreoffice/core/tree/accessibility/bridge/org/openoffice/java/accessibility/Component.java

searching for Focus - seems to suggest that we -should- emit lots of Focus events (as before) - which we do by queueing them:

                case AccessibleStateType.FOCUSED:
                    getEventQueue().postEvent(new java.awt.event.FocusEvent(
                        Component.this, enable ?
                        java.awt.event.FocusEvent.FOCUS_GAINED :
                        java.awt.event.FocusEvent.FOCUS_LOST));
                    break;

It would be interesting to instrument the client too - clearly if the events arrive in JDK<old> but not in JDK<new> something is going wrong with that flow.
We seem to push to:

bridge/org/openoffice/java/accessibility/Component.java-        return java.awt.Toolkit.getDefaultToolkit().getSystemEventQueue();

in each case. Is there any reason that in new JDK's that doesn't work ? :-)

The JDK's a11y code is in:

http://hg.openjdk.java.net/build-infra/jdk8/jdk/file/23878dff5b55/src/share/classes/javax/accessibility/

According to aph; the code for the windows bridge we didn't manage to find.

(In reply to comment #5)
> The JDK's a11y code is in:
> 
> http://hg.openjdk.java.net/build-infra/jdk8/jdk/file/23878dff5b55/src/share/
> classes/javax/accessibility/
> 
> According to aph; the code for the windows bridge we didn't manage to find.

I am sooooo confused, are we using jdk8 already for the LibreOffice builds?

Here is the Oracle Enhancement/Bug for jdk7 and jdk8
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166956
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000839

Doesn't show as complete for jdk8... so maybe that's why no jdk8 access bridge source yet from Oracle.

Anyhow, I think this dates to the JAB integration into the JRE at the SE 1.7u6 build. Don't know if those traces get us any further in identifying what has stopped working...

   http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/e15839c985d1

No documentation comments on on changes from v2.02 to v2.0.3 of the JAB API, can only find the v2.0.2 API details here

http://docs.oracle.com/javase/accessbridge/2.0.2/index.html

Add this approval thread for the 7166956 integration of made by Oracle's Kelly O'Hair, Dalibor Topic, Peter Brunet, Ragini Prasad, and approved by Edvard Wendelin.

http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003102.html

Maybe a discussion with one of them would uncover needed details.

editing the title remove rudundant Accessibility.

Also, remains an issue through JRE 1.7u17, could someone with Oracle ODN contract support give them a poke or submit a bug against the JDK 7 side, I can't.  And, while I think this is all on the JAAPI and Java Bridge code side, it IS possible that it is a deficiency on the LibreOffice side, but suspect no way to know unless we hear from the Oracle DEVs.

Meanwhile accessibility with JRE 1.6u43 and JAB 2.0.2 remains functional.

I mentioned this to a contact at Oracle, but there are no guarantees that this will have any effect.

Here is a thought, do we need to shift the build system's JDK forward to a 1.7.0_xx build and generate J2SE 7 bytecode to get the UAA <--> JAB v2.0.3 working correctly?

Through the 4.1.0.1 build we push only J2SE 5.0 bytecode. How well does the Java Accessibility API on Windows handle the old Accessibility bytecode being passed via JAB?

Has that been the problem?

David O. provided these historical refs related to an effort on his part to move forward with working with new Java JDK features, which notably should include handling the imbedded JAB v2.0.3 in JREs > 1.7u6 for Windows OS builds.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5c159626c6b3ace5becf03aad5ed9a1851065c15

https://gerrit.libreoffice.org/#/c/2884/

(In reply to comment #0)
> Apparent changes in Java SE JRE 1.7 are impacting fidelity of Java Access
> Bridge (JAB) v2.0.3 delivered UNO Accessibility API roles for AT users on
> Windows OS.
> 
> Simple test case:
> A: Action
> O: Outcome
> 
> A: Assistive Technology (AT) activated (NVDA or Jaws)
> A: Run the JAB test utility JavaMonkey-32
> 
> A: Open LibreOffice
> A: Enable LibreOffice AT Tools and JRE w/JAB
> A: create a new Writter doccument
> O: AT announce "document view"
> A: enter some text
> A: enter <alt><f4> to close document
> 
> O: "Save document" dialog opens -- AT will announce "Frame Save Document
> dialog"
> JavaMonkey File -> Refresh Tree will show untitled Writer [frame], and the
> Save document [alert] with roles: Save [push button], Close without saving
> [push button], Cancel [push button]...
> 
> A: enter <Tab>'s in the Save Document dialog, button will move from "Save"
> to "Close without Saving" to "Cancel".  AT does not announce button titles.
> 
> Expected: AT would correctly announce label of each push button object.
> 

testing similar scenario you are describing above but without LO involved at all:
Windows 7 64 bit
JDK 1.7 (update 25), with JAB 2.0.3 included
NVDA 2013.1
SwingTest2.jar as suggested on
http://docs.oracle.com/javase/accessbridge/2.0.2/javamonkey.htm
(Downloaded from https://java.net/downloads/ojt-accessibility/Demos/SwingSet2.jar
and started with java -jar SwingSet2.jar)

In SwingSet2 Windows activate JFileChooserDemo (5 icon on Toolbar from left)
Click on Show Plain JFileChooser button
Open Dialog appears
Click Tab: Focus switch to "Open"- and "Cancel"-buttons
AT does not announce button titles

Can you verify that this use case is working with 2.0.2 JAB separately installed wth JDK 1.6?

If it does: clearly NOT OUR BUG =>

JAB 2.0.3 included with JDK 1.7 is broken in that respect.

New use case 1:

the same as in c12, but with JAWS 14.0 and not with NVDA:

As suggested in 

http://docs.oracle.com/javase/7/docs/technotes/guides/access/enable_and_test.html
under the section:
Testing Java Access Bridge:
Installing JAWS from the follow location:
http://www.freedomscientific.com/products/fs/jaws-product-page.asp

following the link for 

FREE Trial Download for Windows 64 bit:
ftp://ftp.freedomscientific.com/users/hj/private/WebFiles/JAWS/J14.0.4004-64bit.exe

Reboot
After restart
confirming to using JAWS in demo mode.

Starting:

java -jar SwingSet2.jar
as described in c12, open a dialog
use Tab to switch the focus
AT correclty announces the button switch with
"Open button",
"Cancel buton"

New use case 2:

download latest LibreOffice from:
http://ftp.rz.tu-bs.de/pub/mirror/tdf/tdf-pub/libreoffice/stable/4.0.4/win/x86/LibreOffice_4.0.4_Win_x86.msi
install LO
During install lick on support for assistive technologies
start jaws 14.0
start LO Writer 
Info Dialog: Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2)
Option=>Extended=>Java 1.7.0_25
Write text
Ctrl+s
switch with tab
AT correclty announces the button switch with
"Open button",
"Cancel buton"

Conclusion:

NOT OUR BUG: Oracle JDK 1.7.0_25 with JAB 2.0.3 works correctly with SwingSet2.jar & LO 4.0.4.2 with AT JAWS 14.0, demo mode, but
doesn't work correctly with AT NVDA 2013.1 =>

NVDA 2013.1 is broken with Oracle JDK 1.7.0_25 JAB 2.0.3,
to reproduce see above (New use case 1 or New use case 2).

SwingSet2.jar works correctly for me with NVDA 2013.1 following the steps you provided in comment 12. I'm not sure why it doesn't work for you. Did you have the JAB enabled correctly? (It is included, but not enabled by default. It's possible JAWS automatically enables it; I'm not sure.)

New use case 2 from comment 13 is invalid. The Save dialog in LO is a native Windows Save dialog and does not use the JAB, so it would work regardless of JAB related problems. In contrast, the dialog that appears when you close with unsaved changes does use the JAB, so you should test with this dialog as described in comment 0.

David

Sorry reopening. There are problems with UNO Accessibility API <--> Java Accessibility API not passing accessibility events from LibreOffice.
JRE 1.6u45 bridges events flawless, while JRE 1.7u25 misses large numbers of accessibility events.

Also, we should not bring an AT tool like NVDA or JAWS into the mix as the they are really not the issue--as AT they have to handle the instrumentation being passed to them by JAA on Windows. (Although the latest NVDA 2013.1 build is throwing some JABHandler.pyo gain_Focus errors that are new to me. -- Jamie?)

At this point, rather than the AT it seems more controlled to use the JRE 6, JavaFerret-32 and follow the focus events, and review the AccessibleContext information being returned.

Then what is useful is to see the Accessibility Events and Java Events--and Oracle provides the javaferret-32.exe--since we're on Windows need to keep things 32-bit for the time being.  The javaferret-32.exe is found bundled with JAB v2.0.2. Which has a link from the the JRE 7 Enabling & Test page linked at http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html   Unzip the download, the Windows executables are

Yes, the Java SwingSet2 demo, which is JRE 6 bytecode 50.0, runs correctly and its instrumented accessibility events show in javaferret-32 with JRE 1.7u25 and JAB 2.0.3

But LibreOffice builds 4.0.3.2, 4.0.4.2, 4.1.0.1 and 4.2.0alpha+ are sporadic in delivering accessibility events when JRE 1.7u25 is otherwise correctly functioning.


Use case:

Install and configure JRE 1.7u25 environment, so that from a command prompt

where java
java -version
where WindowsAccessBridge*.dll

return meaningful results.


C:\Users\vsfoote>where java
C:\Program Files (x86)\Java\jre7\bin\java.exe

C:\Users\vsfoote>java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b16)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode, sharing)

C:\Users\vsfoote>where WindowsAccessBridge*.dll
C:\Windows\System32\WindowsAccessBridge-32.dll
C:\Program Files (x86)\Java\jre7\bin\WindowsAccessBridge-32.dll

Launch javaferret-32.exe 

Run SwingSet2.jar from command line:  java -jar SwindSet2.jar

Set javaferret-32 -- Java Events --> Track focus events; and on Accessibility Events --> Track Name, Value, Selection and Text properties.

Observe that javaferret-32 will show every change of focus and that accessibile context is well filled.


Install any current LibreOffice build.  Configure 
1) Tools -> Options -> Advanced -> Java Options panel -- check use a Java Runtine environment, and select radio button for available JRE environment noting "with accessibility support" if the JRE's jabswitch -enable flag had been set.

2) Tools -> Options -> Accessibility -> Miscellaneous options panel -- check Support assistive technology tools (program restart required)

Restart LibreOffice.

The javaferret-32 should reflect the start panel on launch. And <F6> key entry should generate focus events from LibreOffice. A launch of any component from start panel should move focus, and again <F6> should cycle focus through various accessible components.

Uninstall JRE 1.7u25 and install JRE 1.6u45. Make same system configurations to have reasonable command line results.

C:\JABv2.0.2>where java
C:\Program Files (x86)\Java\jre6\bin\java.exe

C:\JABv2.0.2>java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode, sharing)

C:\JABv2.0.2>java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode, sharing)
C:\JABv2.0.2>where WindowsAccessBridge*.dll
C:\JABv2.0.2\WindowsAccessBridge.dll
C:\Windows\System32\WindowsAccessBridge-32.dll

C:\JABv2.0.2>java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode, sharing)

Launch the same LibreOffice build, launch javaferret-32.

Will then have meaningful details for start panel, and <F6> actions will cause focus shift when following along in javaferret-32.  If they don't show in the javaferret-32 they won't be acted on by the AT, and that is what is happening with the LibreOffice java classes.

The most efficient way to set up the JRE 1.6u45 with Java Access Bridge is to download and install the 32-bit JRE

Then set a JRE_HOME system variable, pointing to the install location--C:\Program Files (x86)\java\jre6

Append ";%JRE_HOME\bin" to the Windows system PATH

Finally, set up Java Access Bridge, but Oracles instructions for setting up JAB v2.0.2 require a lot of hand edits and file placements.

Instead download and run the purpose built JWin -- JAB v2.0.2 installer by Jamal Mazrui found here: http://empowermentzone.com/JWin_setup.exe for a more consistent installation that will configure based on the JRE_HOME variable.

(In reply to comment #16)
> location--C:\Program Files (x86)\java\jre6
> 
> Append ";%JRE_HOME\bin" to the Windows system PATH
> 
missing "%" sign on variable... should be

Append ";%JRE_HOME%\bin" to the Windows system PATH

(In reply to comment #15)
> Although the latest NVDA 2013.1
> build is throwing some JABHandler.pyo gain_Focus errors that are new to me.
> -- Jamie?
I'm not seeing this for the SwingSet2 example. It's off-topic here, so it'd be great if you could email nvda-devel, file a ticket or email me privately regarding this issue if you get a chance. Thanks!

(In reply to comment #14)
> SwingSet2.jar works correctly for me with NVDA 2013.1 following the steps
> you provided in comment 12. 

Which JAB version are you using?

> I'm not sure why it doesn't work for you. Did
> you have the JAB enabled correctly? (It is included, but not enabled by
> default.
sure

Please can we first try to find the answer to that question: 

why i am not getting focus lost/gain events in SwingSet2.jar with 
JDK 1.7.0_25 (with included 2.0.3 JAB) and NVDA 2013.1 but getting it on JAWS 14.0?

The steps to reproduce:
1. Scratch installation of Windows 7, 64 bit
2. JDK 1.7.0_25 installed only (with included JAB 2.0.3),
   Note: neither JAB 2.0.2 no JDK 1.6 were ever installed on that machine
3. start SwingSet2.jar with java -jar SwingSet2.jar
4a. NVDA 2013.1 => Test Dialog from comment c12 => AT not announces button names on focus lost/gain (tab key hit)
4b. JWAS 14.0 => Test Dialog from comment c12 => AT announces button names on focus lost/gain (tab key hit)

filled a ticket vor NVDA project:

http://community.nvda-project.org/ticket/3303#ticket

@David,

(In reply to comment #19)

> Please can we first try to find the answer to that question: 
> 
> why i am not getting focus lost/gain events in SwingSet2.jar with 
> JDK 1.7.0_25 (with included 2.0.3 JAB) and NVDA 2013.1 but getting it on
> JAWS 14.0?

Normally I don't bother with 64-bit JRE, but I just ran through an installation of 64-bit JRE 1.7u25, activated accessbridge with jabswitch -enable and saw no issues with SwingSet2 demos run watching from JavaFerret-64.exe. Nor did I have any problems in an NVDA 2013.1 session which sounded all content on SwingSet2 demo.

So going to say JRE1.7u25 and NVDA 2013.1 WFM with the SwingSet2 demo, but not true for LibreOffice.

=-=-=

But, to maybe help work through it.

When you install the 64-bit JRE 1.7u25, it places both 32-bit and 64-bit versions of the Java executables. 

Defaults are:
C:\Program Files\Java\jre7
C:\Program Files (x86)\Java\jre7

Installer then copies java.exe, javaw.exe, javaws.exe and WindowsAccessBridge-64.dll (or -32.dll) into the Windows system folders. 64-bit into the C:\Windows\System32, and 32-bit into C:\Windows\SYSWOW64. 

On a 64-bit OS, unless you configure system environment variables, the 64-bit java will be called by default, and it will use the 64-bit WindowsAccessBridge-64.dll. 

The corresponding WindowsAccessBridge-32.dll will be called when 32-bit java needs it.

But before first use the Java AccessBridge for both the 64-bit and the 32-bit JREs must be set active by running "jabswitch -enable" from the respective Program Files directory. And likewise to deactivate "jabswitch -disable" from the respective directory.

The SiwngSet2.jar demo bytecode can be run from either 64-bit or 32-bit java, and you can monitor accessibility focus and events from the corresponding 64-bit or 32-bit JavaFerret. Where, if you see the focus and attributes for accessibility events in JavaFerret, the AT tools will as well.

@Stuart thank you for that description!

i can reproduce that it works with SwingSet2.jar (i closed the NVDA bug) and not with Close Writer without saving Dialog. There i do not get any focus lost/gain events on tab key hit.

I'm building debug version with 51 byte code version now but am afraid as Noel pointed out it wouldn't change anything. Let me debug and see...

(In reply to comment #21)
> @David,
> 
> (In reply to comment #19)
> 
> > Please can we first try to find the answer to that question: 
> > 
> > why i am not getting focus lost/gain events in SwingSet2.jar with 
> > JDK 1.7.0_25 (with included 2.0.3 JAB) and NVDA 2013.1 but getting it on
> > JAWS 14.0?
> 
> Normally I don't bother with 64-bit JRE, but I just ran through an
> installation of 64-bit JRE 1.7u25, activated accessbridge with jabswitch
> -enable and saw no issues with SwingSet2 demos run watching from
> JavaFerret-64.exe. Nor did I have any problems in an NVDA 2013.1 session
> which sounded all content on SwingSet2 demo.
> 
> So going to say JRE1.7u25 and NVDA 2013.1 WFM with the SwingSet2 demo, but
> not true for LibreOffice.
> 
> =-=-=
> 
> But, to maybe help work through it.
> 
> When you install the 64-bit JRE 1.7u25, it places both 32-bit and 64-bit
> versions of the Java executables. 
> 
> Defaults are:
> C:\Program Files\Java\jre7
> C:\Program Files (x86)\Java\jre7
> 
> Installer then copies java.exe, javaw.exe, javaws.exe and
> WindowsAccessBridge-64.dll (or -32.dll) into the Windows system folders.
> 64-bit into the C:\Windows\System32, and 32-bit into C:\Windows\SYSWOW64. 
> 
> On a 64-bit OS, unless you configure system environment variables, the
> 64-bit java will be called by default, and it will use the 64-bit
> WindowsAccessBridge-64.dll. 
> 
> The corresponding WindowsAccessBridge-32.dll will be called when 32-bit java
> needs it.
> 
> But before first use the Java AccessBridge for both the 64-bit and the
> 32-bit JREs must be set active by running "jabswitch -enable" from the
> respective Program Files directory. And likewise to deactivate "jabswitch
> -disable" from the respective directory.
> 
> The SiwngSet2.jar demo bytecode can be run from either 64-bit or 32-bit
> java, and you can monitor accessibility focus and events from the
> corresponding 64-bit or 32-bit JavaFerret. Where, if you see the focus and
> attributes for accessibility events in JavaFerret, the AT tools will as well.

Created attachment 81351 [details]
Source for Java Access Bridge v2.0.2 from Oracle distribution of accessbridge-2_0_2-fcs-bin-b06.zip

@David,
(In reply to comment #22)
 
> I'm building debug version with 51 byte code version now but am afraid as
> Noel pointed out it wouldn't change anything. Let me debug and see...
>

It will be a start and returning Java Access Bridge to full function under JRE 7 may be as simple as a recompile with different target. Oracle has suggests that current recompile be done with current headers.

Unfortunately, no API details for JAB v2.0.3 built in to JRE 7. We have the API for JAB v2.0.2 and I've attached the V2.0.2 source code as a zipped file. We just don't know how much things changed when the code was moved into the JRE.

http://docs.oracle.com/javase/accessbridge/2.0.2/api.htm

These are installation notes for the JAB at v2.0.2, may be some hints there as well.

http://docs.oracle.com/javase/accessbridge/2.0.2/setup.htm

Stuart

How are you managing to switch from JAB 2.0.2 to JAB 2.0.3 on the same machine back and forth?

I've found that question (without an answer ;-)
https://forums.oracle.com/thread/2513951

Frequently end up installing and uninstalling the v2.0.2 JAB and JRE 1.6u45, when needing to work JRE 1.7

However, work around is to not move the WindowsAccessBridge32.dll or the java executables into the C:\Windows\Sytem32 (on 32-bit systems) or C:\Windows\SYSWOW64 (on 64-bit systems) and to not install 64-bit JRE.

Then use a JRE_HOME (or JAVA_HOME) environment variable to point to either of the JREs as needed in their default locations.

e.g. set JRE_HOME to either
C:\Program Files (x86)\Java\jre6
C:\Program Files (x86)\Java\jre7

and then append ";%JRE_HOME\bin" to the system PATH

Why I suggest folks test reasonableness of configuration from a command prompt.

so building with JDK 1.7, i can reproduce the problem with LO 4.2.0 alpha (unchanged master from  2013-06-24) => JAB 2.0.3, JDK 1.7u25 and can confirm that switching back to JDK 1.6u45, JAB 2.0.2 solves the problem for the same LO build.

No NVDA installation is actually needed to see the problem: JavaFerret-32 is enough with activated traces for Focus gain/lost event.

The logging analysis shows though, that in both cases (working and not working JAB) the events broadcasting works in Component.java:

                   case AccessibleStateType.FOCUSED:
                    getEventQueue().postEvent(new java.awt.event.FocusEvent(
                        Component.this, enable ?
                        java.awt.event.FocusEvent.FOCUS_GAINED :
                        java.awt.event.FocusEvent.FOCUS_LOST));
                    break;

I would like to isolate the problem and have a small reproducer to be able to report it. Are there other known/reported use cases or applications with not working JAB 2.0.3 included in JDK 1.7?

(In reply to comment #26)
> Are there other known/reported use cases or applications with
> not working JAB 2.0.3 included in JDK 1.7?
Unfortunately, none that have been reported to us.

I guess the advice I got from the Java / a11y team was to stick with 1.6 for now, and that there may be some security related meta-issue around event emission that was fixed in 1.7 that makes this hard to fix; I imagine focus stealing is one of those things where security guys traditionally turn up to vandalise the user-experience ;-) [ at least my window manager is still recovering from well-meaning attempts to 'improve' this are some five years after the initial 'fix' ;-].

(In reply to comment #28)
> I guess the advice I got from the Java / a11y team was to stick with 1.6 for
> now, and that there may be some security related meta-issue around event
> emission that was fixed in 1.7 that makes this hard to fix;

focus gain/lost events emission works fine in JDK 1.7 (JAB 2.0.3) with: 

standalone JVM runnning SwingSet2.jar

but doesn't work with:

soffice => Java UNO Bridge => JVM in process => Component.java (even emission seems to work) => no events are recognized (for example from JavaFerret-32)

Can we ask an opinion of Java / a11y team how to track it down any further? Get more logging/traces?

Java / a11y team, not sure whom that is, Noel G. & Stephen B.?  I just try to stay on top of the QA side of accessibility and stir the pot sometimes ;-)

Last substantive work on Windows Java Access Bridge for bug 53474 --at 3.6.3.2+--, see Stephen B.'s commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=5ba1694606577f9cda2b773d82ae765118bfc9e1 to clean up some issues of conversion to GBUILD.

Is there anyway to finding out what Oracle has incorporated into the JRE 7 for Windows as JAB v2.0.3 that is making those JRE's flakey for use?  

I was looking to compare the JAB v2.0.2 source headers to what we actually incorporate in LibreOffice.  Only bread crumbs in OpenGrok, for example...  http://opengrok.libreoffice.org/search?q=WindowsAccessBridgeAdapter&project=core&defs=&refs=&path=&hist=

And just to show my confusion... why are there both WindowsAccessBridge.java and WindwosAccessBridge.cxx source files--is that for JNI? And why are there calls to WindowsAccessBridge.h in the CustomTarget make files if it that header does not exist?

David Ostrovsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7746de6e42d5957fa62fa278e2c46a0cb472dc01

fdo#58995 fix focus gain/lost events dropping on JDK 1.7



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

@David,

Something is not quite correct yet. Pulled tonight's daily with your patch, and installed JRE 1.7u25 and activated JAB with jabswitch -enabled.

Build Info
tinderbox: administrator: Tinderbox <l.lunak@suse.cz>
tinderbox: buildname: Win-x86@6
tinderbox: tree: MASTER
tinderbox: pull time 2013-06-27 01:06:16
tinderbox: git sha1s
core:7746de6e42d5957fa62fa278e2c46a0cb472dc01

Watched with JavaFerret-32.exe running w/JRE1.7u25. 

All Java & Accessibility elements of SwingSet2.jar demo track correctly.

But with LODev 4.2.0.0alpha0 2013-06-27, I am not seeing Tab movement or cursor based focus changes showing.  Some of the pop-up window frame events will show a focus change.  And some of the accessibility events--text, selection, value will report. But little movement of the Java Events for track focus--would expect every tab or cursor movement in menus, or even typing text to update. So something is still not quite correct.

Stuart

(In reply to comment #32)
> @David,
> 
> Something is not quite correct yet. Pulled tonight's daily with your patch,
> and installed JRE 1.7u25 and activated JAB with jabswitch -enabled.
> 
> Build Info
> tinderbox: administrator: Tinderbox <l.lunak@suse.cz>
> tinderbox: buildname: Win-x86@6
> tinderbox: tree: MASTER
> tinderbox: pull time 2013-06-27 01:06:16
> tinderbox: git sha1s
> core:7746de6e42d5957fa62fa278e2c46a0cb472dc01
> 
> Watched with JavaFerret-32.exe running w/JRE1.7u25. 
> 

Can you confirm, that the original problem solved? Steps to reproduce:

1. install JRE1.7u25 32 bit
2. activate AT with jabswitch -enabled
3. install and start JavaFerret-32.exe
4. install and start LO with the patch above
5. activate JRE1.7u25
6. activate AT
7. type space
8. type Alt-F4
9. type tabs multiple times
10. focus gain/lost events are reported in JavaFerret-32 (for "Save", "Discard" and "Cancel" buttons)

We can possible have another problem(s), please provide the exact steps (like above) how to reproduce.

Complete steps how to reproduce the original problem:

1. install Windows 7 64 bit
2. install JRE1.7u25 32 bit (or JDK)
3. activate JRE AT support with C:\Program Files (x86)\Java\jre7\\bin\jabswitch -enabled
4. install and start JavaFerret-32.exe
5. activate "track focus events" in JavaFerret-32
6. install and start LO with the patch 7746de6e42d5957fa62fa278e2c46a0cb472dc01
7. activate JRE1.7u25 (or JDK) in LO
8. activate AT in LO
9. create an empty writer document
10. type space
11. type Alt-F4
12. Save Document Alert dialog appears
13. type tabs multiple times in this dialog

behavior with the patch:
14a. focus gain/lost events are reported in JavaFerret-32 (for "Save", "Discard" and "Cancel" buttons)

behavior without the patch:
14b. focus gain/lost events are not reported in JavaFerret-32

Note:
JavaFerret-32 can be obtained here: http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html

Fix looks lovely David - thanks so much for that ! :-) Assuming that code was once useful for JDK 1.6 (?) could we make removing that branch JDK version specific ? :-) It'd be a shame to bust the otherwise working 1.6 accidentally.

And I guess we should back-port this to LibreOffice 4.1 :-)

Thanks !

(In reply to comment #35)
> Fix looks lovely David - thanks so much for that ! :-) Assuming that code
> was once useful for JDK 1.6 (?) could we make removing that branch JDK
> version specific ? :-) It'd be a shame to bust the otherwise working 1.6
> accidentally.

While it would be trivially to introduce a JDK 1.7 specific branch a lá

           if (isJDKLooksLike17XOrHigher()) { ...

i did test the patch with JDK 1.6u45 (sure i did ;-) no regression here.

> 
> And I guess we should back-port this to LibreOffice 4.1 :-)
> 

done:

4-1:
https://gerrit.libreoffice.org/#/c/4560/
4-0:
https://gerrit.libreoffice.org/#/c/4559/

Cool - I'm just a dofus - I was reading the diff in the comment as the real diff ;-) will approve the gerrit changes - thanks ! :-)

David Ostrovsky committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5c96ee2a52e869f98500f07f3505d99986c9f85a&h=libreoffice-4-1

fdo#58995 fix focus gain/lost events dropping on JDK 1.7


It will be available in LibreOffice 4.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

David Ostrovsky committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ebe3b1c188744062588ab880a09bcaa8d3af2625&h=libreoffice-4-0

fdo#58995 fix focus gain/lost events dropping on JDK 1.7


It will be available in LibreOffice 4.0.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

(In reply to comment #33)

> Can you confirm, that the original problem solved? Steps to reproduce:
> 

Yes, that frame panel is now responding in JavaFerret-32

> 
> We can possible have another problem(s), please provide the exact steps
> (like above) how to reproduce.

I think so. We are not gaining focus to the start panel on launch, although JRE w/accessibility support selected and support assistive technology tools support were enabled. And when a component is running, key board navigation of GUI is not showing focus event changes in JavaFerret.  When some frame/panels launch, notably in the Format menu, those panels respond with focus changes for <TAB> keys and <LEFT><RIGHT> cursors but not on objects with vertical <UP><DOWN> cursor control like drop box menus.

On launch, landing on the root pane (aka start panel) use <F6> key to toggle from start panel to menubar and back--both should reflect focus change and accessible context of the object landed on.

=-=-=

Specific test case 1

1. javaferret-32 running, with Tools --> Options --> Advanced: JRE selected and
Tools --> Options --> Accessibility: Support assistive technology tools checked in prior LO session.

2. launch LO, allow start panel to load--should be sitting on "Text Document"
   expected - JavaFerret to report Text Document object
   result - it just shows root pane

3. <TAB> or <UP,DOWN,LEFT,RIGHT> cursor to each item on panel
   expected - JavaFerret to reflect focus change and report each object
   result - no change in focus, shows only root pane of original

4. <F6> key to toggle to menu bar
   expected - JavaFerret to reflect focus change and 
   result - no change in focus, menu items not listed

5. <TAB> or <UP,DOWN,LEFT,RIGHT> cursor to each item on panel
   expected - JavaFerret to reflect focus change and report each object
   result - no change in focus, shows only root pane of original opening.

=-=-=

And while in a writer session, movement from GUI component to component with <F6> should show Focus change. It is not, although on some of the menu items that launch new frame panels, those gain focus and have some focus response with <TAB> and cursor key movements.

=-=-=

Specific test case 2

1. javaferret-32 running, with Tools --> Options --> Advanced: JRE selected and
Tools --> Options --> Accessibility: Support assistive technology tools checked in prior LO session.

2. launch LO, allow start panel to load--should be sitting on "Text Document"
   expected - JavaFerret to report Text Document object
   result - it just shows root pane

3. Open Text Document
    expected - JavaFerret to report focus gained by writer, as Document view
    result - no focus change, remains at last reported focus

4. <F6> key to toggle to menu bar
   expected - JavaFerret to reflect focus change and File menu context
   result - no change in focus, menu items not listed

5. <TAB> or <LEFT><RIGHT><UP><DOWN> key to move across menu items
   expected - JavaFerret to reflect focus changed menu context
   result - no change in focus, menu items not listed

6. <F6> key to move to Standard tool bar and then Formatting tool bar
   expected - JavaFerret to reflect focus change menu context
   result - no change in focus, menu items not listed

7. <F6> key back to document text
   expected - JavaFerret to reflect focus change to "Document view"
   result - no change to focus

=-=-=

Specific test case 3

1. javaferret-32 running, with Tools --> Options --> Advanced: JRE selected and
Tools --> Options --> Accessibility: Support assistive technology tools checked in prior LO session.

2. launch LO, allow start panel to load--should be sitting on "Text Document"
   expected - JavaFerret to report Text Document object
   result - it just shows root pane

3. Open Text Document
    expected - JavaFerret to report focus gained by writer, as Document view
    result - no focus change, remains at last reported focus

4. <ALT>+O+A (or mouse click Format, Paragraph menu) to open Paragraph format panel
    expected - Open Paragraph format panel and JavaFerret to report panel and default landing--Indent set automatic 
    result - as expected

5. <TAB> multiples (or mouse select) to reach Line Spacing drop menu
    expected - JavaFerret to report default drop list setting of "Single" with parent role/name changed and Accessible role and status 
    result - last active focus remains, and <TAB> or <Shift><TAB> show next or prior accessible object details.  Drop list widget and cursor movement have no focus or JAB action.

(In reply to comment #40)
> (In reply to comment #33)
> 
> > Can you confirm, that the original problem solved? Steps to reproduce:
> > 
> 
> Yes, that frame panel is now responding in JavaFerret-32
> 
> > 
> > We can possible have another problem(s), please provide the exact steps
> > (like above) how to reproduce.
> 
> I think so. We are not gaining focus to the start panel on launch, although
> JRE w/accessibility support selected and support assistive technology tools
> support were enabled. And when a component is running, key board navigation
> of GUI is not showing focus event changes in JavaFerret.  When some
> frame/panels launch, notably in the Format menu, those panels respond with
> focus changes for <TAB> keys and <LEFT><RIGHT> cursors but not on objects
> with vertical <UP><DOWN> cursor control like drop box menus.
> 
> On launch, landing on the root pane (aka start panel) use <F6> key to toggle
> from start panel to menubar and back--both should reflect focus change and
> accessible context of the object landed on.
>
[...]

I addressed all your comments. Can you confirm that with this new jar version installed (just replace the old one):

http://ostrovsky.org/patches/java_uno_accessbridge.jar 

the fidelity of JAB v2.0.3 with JDK 1.7u25 is exactly the same
as of JAB v2.0.2 with JDK 1.6u45?

@David,
The replacement JAR works very well. JavaFerret-32 responding with focus to all events I ran through. I think you are on track. Having a bit of an issue with NVDA. Can't tell if it is on the LO side or the NVDA side.

@Jamie,
I'm not getting very good response from NVDA 2013.1, even though everything looks to be showing up now in JavaFerret. Can you have a go at David's patched JAR. It installs to $ORIGIN\program\clases

I'm getting these errors in NVDA debug level log 
ERROR - queueHandler.flushQueue (15:28:03):
Error in func event_gainFocus from JABHandler.internalFunctionQueue
Traceback (most recent call last):
  File "queueHandler.pyo", line 47, in flushQueue
  File "JABHandler.pyo", line 420, in event_gainFocus
  File "JABHandler.pyo", line 242, in __init__
  File "JABHandler.pyo", line 24, in _errcheck
RuntimeError: Result None
DEBUGWARNING - JABHandler.JABContext.__del__ (15:28:03):
Error releasing java object
Traceback (most recent call last):
  File "JABHandler.pyo", line 253, in __del__
AttributeError: 'JABContext' object has no attribute 'vmID'


Stuart

@Jamie,

No improvement with a NVDA 2013.1.1 JABHandler even though JavaFerret rendering w/JRE 1.7u25 now seems complete (at least as good as the JRE 1.6 and JAB v2.0.2).
 
Would the errors for "vmID" be LO <--> JAB associated and passed out from the JRE (that we need to help chase down) or is that an internal tag that NVDA assigns and tracks?

(In reply to comment #42)
> I'm not getting very good response from NVDA 2013.1, even though everything
> looks to be showing up now in JavaFerret. Can you have a go at David's
> patched JAR.
I'll try to do this when i have a chance, but that may be a while, so here are some thoughts in the meantime.

> I'm getting these errors in NVDA debug level log
Do you get these errors with JRE 1.6 or does everything work as expected?

> ERROR - queueHandler.flushQueue (15:28:03):
> Error in func event_gainFocus from JABHandler.internalFunctionQueue
> Traceback (most recent call last):
>   File "queueHandler.pyo", line 47, in flushQueue
>   File "JABHandler.pyo", line 420, in event_gainFocus
>   File "JABHandler.pyo", line 242, in __init__
>   File "JABHandler.pyo", line 24, in _errcheck
> RuntimeError: Result None
This error occurs when we try to retrieve the HWND from the JAB accessible context (calling the JAB function getHWNDFromAccessibleContext) for the focus or one of its descendants in response to either a focus gained or active descendant change event. We're getting a value of 0, which should never happen; it should be a valid HWND. I'm not sure if that's an LO issue or a JAB issue, but I haven't seen it in any other JAB apps. I'd need to do some rather tedious debugging to tell you which specific event and accessible it is.

> DEBUGWARNING - JABHandler.JABContext.__del__ (15:28:03):
> Error releasing java object
> Traceback (most recent call last):
>   File "JABHandler.pyo", line 253, in __del__
> AttributeError: 'JABContext' object has no attribute 'vmID'
This warning is caused by the first error and can be ignored for now.

(In reply to comment #42)
> @David,
> The replacement JAR works very well. JavaFerret-32 responding with focus to
> all events I ran through. I think you are on track. Having a bit of an issue
> with NVDA. Can't tell if it is on the LO side or the NVDA side.
> 
> @Jamie,
> I'm not getting very good response from NVDA 2013.1 [...]

Can you provide exact instructions how to reproduce the problem: 

NVDA 2013.1 <-> JAB v2.0.3 JDK 1.7u25 <-> LO 4.2.0 Alpha (with patched jar)

Something like this [1].

[1] https://bugs.freedesktop.org/show_bug.cgi?id=58995#c34

@Jamie
(In reply to comment #44)

Darn! May be a new issue affecting NVDA introduced in LibreOffice between June 7th and June 11th.

> Do you get these errors with JRE 1.6 or does everything work as expected?
> 

I had thought not and all was good with JRE 1.6u45 and JAB v2.0.2, but then realized it had been a while since I'd checked a LODev 4.2.0 master build with NVDA sounding.

I went back and checked with a JRE 1.6u45 & JAB v2.0.2 configured. 

In fact first problem with NVDA appears with the 2013-06-11 TB-6 build of LODev 4.2.0 master (commit c36348f20c4fcb6ae1acb0fd06c19edfa9fb108).

Last build I have without the the NVDA sounding problem is the TB6 build of 2013-06-07 LODev 4.2.0 master (commit 67278daaf3cb664f8a89900382f0d7b19956b18 ).

Problem is not in any of the 4.1.0 beta or rc builds. None of which will function with JRE 1.7u25 and JAB v2.0.3 configuration.

The NVDA 2013.1.1 error from JRE 1.6u45 JAB v2.0.2 for these builds after commit 67278daaf3cb664f8a89900382f0d7b19956b18 ARE the same as with JRE 1.7u25 and JAB v2.0.3:

ERROR - queueHandler.flushQueue (11:38:37):
Error in func event_gainFocus from JABHandler.internalFunctionQueue
Traceback (most recent call last):
  File "queueHandler.pyo", line 47, in flushQueue
  File "JABHandler.pyo", line 420, in event_gainFocus
  File "JABHandler.pyo", line 242, in __init__
  File "JABHandler.pyo", line 24, in _errcheck
RuntimeError: Result None

or this...

ERROR - queueHandler.flushQueue (11:38:37):
Error in func event_stateChange from JABHandler.internalFunctionQueue
Traceback (most recent call last):
  File "queueHandler.pyo", line 47, in flushQueue
  File "JABHandler.pyo", line 443, in event_stateChange
  File "JABHandler.pyo", line 242, in __init__
  File "JABHandler.pyo", line 24, in _errcheck
RuntimeError: Result None

> This error occurs when we try to retrieve the HWND from the JAB accessible
> context (calling the JAB function getHWNDFromAccessibleContext) for the
> focus or one of its descendants in response to either a focus gained or
> active descendant change event. We're getting a value of 0, which should
> never happen; it should be a valid HWND. I'm not sure if that's an LO issue
> or a JAB issue, but I haven't seen it in any other JAB apps. I'd need to do
> some rather tedious debugging to tell you which specific event and
> accessible it is.

Is the event_stateChange error also related to missing HWND Windows Handle?

@David,
Not sure exactly how to describe a test case to reproduce this issue with NVDA <--> JAB <--> LO.

At this point it is with either JRE and JAB v2.0.3 or v2.0.2.
But JavaFerret seems to be showing the accessible events without problem--is it less sensitive to problems with HWND and vmID that Jamie suspects as the problem for NVDA? Guess we should check how JAWS is also affected.

> @David,
> Not sure exactly how to describe a test case to reproduce this issue with
> NVDA <--> JAB <--> LO.
> 
Try to find the simplest test case where it fails and describe the steps to reproduce.

Given that NVDA 2013.1 behaves equally with JAB v2.0.2 JDK1.6u45 and JAB v2.0.3 JDK1.7u25 with patched jar, i would suggest to close this bug as solved and track the problem at hand as a follow up.

(In reply to comment #46)
> ERROR - queueHandler.flushQueue (11:38:37):
> Error in func event_stateChange from JABHandler.internalFunctionQueue
> Traceback (most recent call last):
>   File "queueHandler.pyo", line 47, in flushQueue
>   File "JABHandler.pyo", line 443, in event_stateChange
>   File "JABHandler.pyo", line 242, in __init__
>   File "JABHandler.pyo", line 24, in _errcheck
> RuntimeError: Result None
> Is the event_stateChange error also related to missing HWND Windows Handle?
Yes.

> But JavaFerret seems to be showing the accessible events without problem--is
> it less sensitive to problems with HWND and vmID that Jamie suspects as the
> problem for NVDA?
JavaFerret probably doesn't need the HWND. It deals purely with JAB events, so it doesn't need to care about native HWNDs.

So are Fririch S's commit--dropping jint for jlong-- on 7 June possibly the cause of problems with WHND response via the JAB (both JRE 1.6u45 JAB v2.0.2 & JRE 1.7u25 JAB v.20.3)?
 41660feef6095f6d9510d11c99376652b41a504b -- WindowsAccessBridgeAdapter.cxx   e704c34ba1ef09f0abd0ad38c79245385f714dc4 -- jni_md.h

Also, do we have to be concerned about building native 32-bit vs. 64-bit interprocess runtimes as identified in this Stack Overflow SE posting: http://stackoverflow.com/questions/8498596/32-bit-java-accessibility-on-a-64-bit-machine ? All my testing has been on 64-bit Windows systems running the *-32.dll's. 

I'll have to scrounge a 32-bit windows system to see if the JREs, JABs and LODev builds behave any different.

(In reply to comment #49)
> So are Fririch S's commit--dropping jint for jlong-- on 7 June possibly the
> cause of problems with WHND response via the JAB (both JRE 1.6u45 JAB v2.0.2
> & JRE 1.7u25 JAB v.20.3)?
>
> 41660feef6095f6d9510d11c99376652b41a504b

Reverting this commit seems to help here: NVDA sounds again. Can you confirm it with this new dll:

http://ostrovsky.org/patches/java_uno_accessbridge.dll

I noticed that the order in which the applications are started is important:

right order:

1. start NVDA
2. start LO

NVDA announces everything

wrong order:

1. start LO
2. start NVDA

NDA says nothing

Test case:

Adjusted instruction from Comment 34 in this bug,
replacing the step 4,5,14a with 

4.new start NVDA 2013.1
5.new not related
14a.new NVDA announces the buttons

@David,

Having some problems getting both your java_uno_accessbridge.dll and java_uno_accessbridge.jar and either JRE/JAB pair stable to be able to run with NVDA.

I've applied both to TB6 build of master as well as your MSVC debug build of 20130613 master you'd posted up previously. I see the JAB events shows in JavaFerret-32, but on launch of NVDA no sounding--so I guess still some issue with HWND. 

That aside, I am really having an issue with activating Accessibility and enabling AT tool support reliably.

Neither the SAL_ACCESSIBILITY_ENABLED (system or user WRITE_REGISTRY=1 registry settings) or in forcing the EnableATToolSupport true seems to be holding state in the LO builds.

The SAL Accessibility Windows registry was work that Andras T. did for the bug 39833 Windows install enhancement. I'm not exactly sure how it interacts. It was intended as a replacement for manually setting the Options --> Tools --> Accessibility --> Support assistive technologies tools checkbox. And sort of superseded stanza settings in LO registrymodifications.xcu. That is toggling stanza True or False:

<item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['Accessibility']">
<prop oor:name="EnableATToolSupport" oor:op="fuse" oor:type="xs:string"><value>[true|false]</value></prop>
</item>

Hit or miss with 4.0.0+ builds, but a real issue now in that I can not keep Accessibility enabled with your current java_uno_accessbridge patches.

(In reply to comment #51)

> Hit or miss with 4.0.0+ builds, but a real issue now in that I can not keep
> Accessibility enabled with your current java_uno_accessbridge patches.

just uploaded a complete build to test:

http://ostrovsky.org/libo/LibreOfficeDev_4.2.0.0.alpha0_Win_x86_archive-2013-06-29.zip

(In reply to comment #52)
> just uploaded a complete build to test:
> 
> http://ostrovsky.org/libo/LibreOfficeDev_4.2.0.0.alpha0_Win_x86_archive-2013-
> 06-29.zip

Oops, can't run it--I've no VS 2010 installed. Getting a no MSVCR100D.dll error. 

Did not have that problem the last zipped full build you put up. So did this build need to be set to release build in some fashion?

(In reply to comment #53)
> (In reply to comment #52)
> > just uploaded a complete build to test:
> > 
> > http://ostrovsky.org/libo/LibreOfficeDev_4.2.0.0.alpha0_Win_x86_archive-2013-
> > 06-29.zip
> 
> Oops, can't run it--I've no VS 2010 installed. Getting a no MSVCR100D.dll
> error. 
> 
> Did not have that problem the last zipped full build you put up. 

That's weird, last time it was debug build too:

http://ostrovsky.org/libo/msvcr100d.dll

@David,

Sorry... dropping the MSVCR100D.dll into the program file didn't fix things, it the next popped up an error about no MSCVP100D.dll

To double check, I wen't back and reinstalled the zip'd 20130623 build you'd posted up. I extracted it the same as todays, but it runs just fine.

(In reply to comment #55)
> @David,
> 
> Sorry... dropping the MSVCR100D.dll into the program file didn't fix things,
> it the next popped up an error about no MSCVP100D.dll
> 
> To double check, I wen't back and reinstalled the zip'd 20130623 build you'd
> posted up. I extracted it the same as todays, but it runs just fine.

compiled release build again:

http://ostrovsky.org/libo/LibreOfficeDev_4.2.0.0.alpha0_Win_x86_archive_2013-06-30_release.zip

@David,

(In reply to comment #56)
> compiled release build again:
> 
> http://ostrovsky.org/libo/LibreOfficeDev_4.2.0.0.alpha0_Win_x86_archive_2013-
> 06-30_release.zip

Got it, no problems with launching this build... JRE 1.7u25 and JAB v2.0.3 working with JavaFerret-32 and also sounding NVDA 2013.1.1

Thanks! I know that was a lot of work.

But JavaFerret and is dropping some key LO GUI elements, notably vertical menus navigated with <UP> & <DOWN> cursor keys, and <RIGHT> cursor movement onto subwindows.

=-=-=

Launching with JRE 1.7u25 here is one JAB deficiency wiht LO, i.e. not reflected in JavaFerret-32. Although NVDA seems to pick it up, I think using IAccessibile/MSAA, Jamie?

Steps to reproduce:

A: complete comment 34 steps to step 10 opening a LO writer document.
R: JavaFerret-32 shows focus shifts and events including any typing on the Text object in the Document view canvas.

A: Use <ALT>+v to enter View menu,
R: JavaFerret reflects focus change to menu

A: Use <DOWN> cursor to move down menu list to "Toolbars" item, 
R: JavaFerret does NOT reflect focus changes, and continues to show the View menu

A: Use <RIGHT> cursor to open sub-menu and <DOWN> cursor to move, 
R: JavaFerret again does NOT reflect focus changes of these menu movements.  

Same result if using keyboard accelerators <ALT>+V, <ALT>+T and picking a menu, e.g. <ALT>+G toggling Formatting toolbar on/off--all NOT reflected with focus changes in JavaFerret-32.

(In reply to comment #57)
> Launching with JRE 1.7u25 here is one JAB deficiency wiht LO, i.e. not
> reflected in JavaFerret-32. Although NVDA seems to pick it up, I think using
> IAccessibile/MSAA, Jamie?
Aside from native dialogs, there is no MSAA in LO. See below.

> A: Use <DOWN> cursor to move down menu list to "Toolbars" item, 
> R: JavaFerret does NOT reflect focus changes, and continues to show the View
> menu
I believe this bug has existed for as long as I can remember. NVDA has a specific hack to work around this. In short, if we detect a state change event on a tab, menu item or menu that includes the focused or selected states, we map it to a focus event.

@Jamie, OK then, I guess I've never followed along closely like this with JavaFerret as to what is happening with all the menus. 

The workarounds you've put into NVDA help mask LO problems with these UNO Accessibility <--> JAB <--> Java Accessibility API connections.

I hear it being handled by NVDA, but then don't look any closer. I bet that makes it a bit of a mess on your end if it is not consistent across the projects you are providing AT for.

@David, before you can finish up your commits, is there any additional Java work needed on Fridrich's June 7th commit(s) that were reverted?  Is using a Java 64-bit jlong vs. jint something that still needs to be reworked for correctness--but that may require adjustments to AT like NVDA?  Maybe documented in an API?

I'll poke at it a little with a VM to check 32-bit Windows with David's patched build. And I already have another VM to follow in GNOME Accerciser what ORCA and ATK are doing when rendering similar test documents. Maybe start a catalog of what is not yet fully working in the JAB compared to ATK/AT-SPI.  Suspect we will need some of that information for validating the IAccessible2 bridge as that code starts to flow in.

Perhaps some final sanity checks that the other components, especially Calc, are working at least the same between JRE/JAB pairs and then I agree we should close out this issue.

And if anyone is interested -- Apache OpenOffice is tracking this same JRE 1.7 JAB issue as https://issues.apache.org/ooo/show_bug.cgi?id=121510

David Ostrovsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9dfe00c74f384886cc3cf336061c6b35f25babd6

fdo#58995 Fix focus gained/lost event dropping for Window and Frame



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

David Ostrovsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4364d1afac91bc90b3e7b665d971929fd8e7af36

fdo#58995 Fix window handle is null on AT side of JAB bridge



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

2013-06-30 David O. Patched build of master runs equally well on 32-bit Windows XP sp3 using JRE 1.6u45 w/JAB 2.0.2 or JRE 1.7u25 w/JAB 2.0.3

In this configuration JavaFerret-32.exe (w/64-interprocess comms) errors on launch.  Native 32-bit JavaFerret.exe shows focus as expected, but does lock up when NVDA directly handles events that are not correctly handling Java focus. Locks up both JavaFerret and NVDA, and one or the other must be closed.

NVDA running with LODev 4.2.0 2013-06-30 David O.'s build is otherwise stable.

Still need to verify a TB build against master with these commits, but believe this issue can be closed.

Setting Resolved Fixed

Verified correct function of JRE 1.7u25 with JAB v2.0.3 set active with jabswitch -enable with 20130701 TB6 build of master for Windows.

Build Info
tinderbox: administrator: Tinderbox <l.lunak@suse.cz>
tinderbox: buildname: Win-x86@6
tinderbox: tree: MASTER
tinderbox: pull time 2013-07-01 09:19:22
tinderbox: git sha1s
core:7857d772f7f82a33de506cd10e4298aa092bfe8f

@David O., should be good to push down to 4.1 and 4.0 if you'd please. AND a very big thank you!

Stuart

(In reply to comment #63)
> Setting Resolved Fixed
> 
> Verified correct function of JRE 1.7u25 with JAB v2.0.3 set active with
> jabswitch -enable with 20130701 TB6 build of master for Windows.
> 
> Build Info
> tinderbox: administrator: Tinderbox <l.lunak@suse.cz>
> tinderbox: buildname: Win-x86@6
> tinderbox: tree: MASTER
> tinderbox: pull time 2013-07-01 09:19:22
> tinderbox: git sha1s
> core:7857d772f7f82a33de506cd10e4298aa092bfe8f
> 
> @David O., should be good to push down to 4.1 and 4.0 if you'd please.

done:

4-0:
https://gerrit.libreoffice.org/#/c/4646/

4-1:
https://gerrit.libreoffice.org/#/c/4645/

> AND a very big thank you!

Thank you and Jamie for all your help!!!

(In reply to comment #49)
 
> Also, do we have to be concerned about building native 32-bit vs. 64-bit
> interprocess runtimes as identified in this Stack Overflow SE posting:
> http://stackoverflow.com/questions/8498596/32-bit-java-accessibility-on-a-64-
> bit-machine ? All my testing has been on 64-bit Windows systems running the
> *-32.dll's. 

So, still not clear to me about impact of native 32-bit JREs, vs use of 64-bit interprocess runtimes on 64-bit Windows OSs.

> I'll have to scrounge a 32-bit windows system to see if the JREs, JABs and
> LODev builds behave any different.

But, with 32-bit Windows XP Pro SP3 running in a VMWare Workstation VM, both David O's patched, and the TB6 build of master 2013-07-01 ( 7857d772f7f82a33de506cd10e4298aa092bfe8f ) for Windows, run with either JRE / JAB pair and respond with Java Accessibility API focus when using the 32-bit JavaFerret.exe, though using the 64-bit JavaFerret-32.exe crashes immediately in this environment.

David Ostrovsky committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=76b57740571628ca3d0101d29c9276e8f5930197&h=libreoffice-4-1

fdo#58995 Fix focus gained/lost event dropping for Window and Frame


It will be available in LibreOffice 4.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

David Ostrovsky committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a516c14d62684f498821d0389bbdee349774a8b&h=libreoffice-4-0

fdo#58995 Fix focus gained/lost event dropping for Window and Frame


It will be available in LibreOffice 4.0.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.