With ESC decision to keep the UAA <-> Java Accessibility API Java Accessibility Bridge while implementing the IAccessible2 native bridge as an experimental feature for 4.2.0.0 now requires more work. The JAB has can no longer be enabled on LODev 4.2.0 beta1+ builds forward. Believe results from IA2 a11y related commit for 4.2.0.0beta1+ between Nov 21 and Nov 25th that isn't quite correct: http://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-4-2&qt=range&q=f4ca7b35f580827ad2c69ea6d29f7c9b48ebbac7..12ebbb7e471d851eec940a47e6737c7c89d0f7f8&ofs=50 The result is though that currently for the 4.2.0 RC1 users dependent on Java Access Bridge will not be able to activate it, and would have to attempt to activate the IAccessible2 bridge as an "experimental feature". Setting a blocker status accordingly--knock it back to critical if we're content to let the RC1 out without JAB functioning.
Nominating for mab4.2 obviously. Really sorry, I saw this back on Nov 26 ( bug 71946 )lost track of it and did not follow up. I know a lot of folks worked hard to bring in the IAaccessible2 native bridge in working form for the 4.2 release--also a lot of moving parts; but at present this regression in the Java Access Bridge would be discouraging for our AT users. Not sure how best to fix it. Pulling JAB out completely as already done in master might be the most direct way, but in truth it could be just some simple issue affecting the JAB--but will need to dig back into it to clear the regression.
OK, so for anyone following along. I'd been testing against TB-42 daily builds of LODev4.2.0.beta2+. Build logs show the --enable-ia2 flag. I went back and loaded the pre-release LODev4.2.0beta2 (5 Dec). And it will not come up with IAccessible2 with "Experimental Features" set, insisting that I enable a JRE. At which point it comes up with JAB provided AT (monitored with Java Ferret). Original issue of bug 71946 What are the compile flag differences between Cloph's 4.2 release build system and Thorsten TB-42 for 4.2? Are they building with the same configuration flags regards the enable_ia2 and the "fall back" for Windows Java Access Bridge support?
yep --enable-ia2 build doesn't register JAB UNO component; should be fixed now. please test the new builds (as i'm only building master on Windows myself).
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ece20685104a3c0900677c1baa4ec975af7e4bf7&h=libreoffice-4-2 fdo#72647: register Java Access Bridge component It will be available in LibreOffice 4.2. 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.
Created attachment 90761 [details] with an Assistive Technology tool in use, and Experimental features not checked, default activation of JAB AT support triggers call for JRE activation On Windows 7 sp1, 64 bit with /A administrative install of Version: 4.2.0.0.beta2+ Build ID: 4031765b004dded31f04c54f9a055b7a3d0053f2 TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-14_01:35:27 Can verify, with an Assistive Technology tool (NVDA 2013.2) active, this build of LODev 4.2.0 beta2+ enables Java Access Bridge and IAccessible2 support for Assistive Technology tools. Hooray! :) One potential down side, is that we are now always activating support for Assistive Technology if an AT tool (NVDA, Jaws) is in use. Probably correct, and will not be an issue for IA2 native bridge alone--as targeted for 4.3 release--but the JAB is a bit resource heavy, and when an AT tool is active it is now challenging to disable the JRE--requiring deletion of LODev profile, and needing to kill the soffic.exe process tree not a good UX. see the attached image of JRE required error. Some notes on state of things for 4.2: **UAA -- Java Accessibility API via JAB** Possibly masked by the current "activate when an AT is in use" implementation. At this point it is unclear if there is a continuing need for the established Windows methods allowing a user to activate the Java Access Bridge-- e.g. 1) using Tools --> Options Advanced, Java options use a JRE and select a system JRE for use, coupled with Tools --> Options Accessibility Miscellaneous check-box to "Support assistive technology tools". Followed by relaunch of LODev. 2) a Windows registry HKCU key value Software\LibreOffice\Accessibility\AtToolSupport of "SupportAssistiveTechnology" set true will also activate JAB based AT. 3) Setting the SAL_ACCESSIBILITY_ENABLED=1 system environment variable activates the JAB support. So a full install using the "Support Assistive Technology Tools" that will set the SAL_ACCESSIBILITY_ENABLED environment variable ( see bug 39833 ) will still be functional. They seem to work, but hard to tell. And they probably should go away for 4.3 if we drop JAB based AT support via the JRE. **UAA -- native IAccessible2 bridge** Checking "Enable experimental features" from Tools --> Options --> Advanced panel, and restart of LODev--WILL toggle off JAB support and activate IAccessible2 support for AT use. Although it does not clear the use Java Runtime. If the Java JAB had not been activated as above, i.e. AT not in use then selecting the "Enable experimental features" check-box will directly activate IAccessible2, when an AT is activated. Not the common use case as anyone needing AT will usually have it in use on launch. Maybe not the best UX, is there a simple fix short of yanking out the JAB based support? This late in the release cycle can the IAccessible2 native bridge be made the default, and retain use of the JAB as the option?
Migrating Whiteboard tags to Keywords: (regression) [NinjaEdit]