Apache OpenOffice (AOO) Bugzilla – Issue 123643
[ia2] IAccessible2 is not enabled automatically even with an AT running
Last modified: 2014-01-30 03:19:47 UTC
This applies only to the ia2 branch. Tested with the 1538508 build. IAccessible2 support should be enabled automatically (permanently or just for the session) if an assistive technology application is detected. Ideally, this would be done dynamically based on WM_GETOBJECT, but SPI_SETSCREENREADER is also a possibility. I thought this worked previously and this page seems to suggest it does using the SPI_SETSCREENREADER flag: https://cwiki.apache.org/confluence/display/OOOUSERS/Tips+for+branch+ia2 However, if I delete my configuration with the 1538508 build and then run OpenOffice while NVDA is running, I get no IAccessible2. NVDA does use SPI_SETSCREENREADER. I know this can be forced with a registry patch, but this really is a hack and isn't reasonable for most users. Even an installer option isn't ideal, since a screen reader user with a portable screen reader might wish to use OpenOffice on a system on which they didn't install it themselves; e.g. public access situation.
Confirmed on WIndows 7 sp1 64-bit ia2 branch AOO410m1(Build:9750) - Rev. 1539225 Rev.1539225 Without a registry hack, the ia2 branch initial launch is not made with Assistive Technology tools enabled. The .REG batch is listed below, but it seems there should be some way to enable AT support when AT is in use. place this into a text file with a .REG extension, and merge for each user needing AT support <snip> Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\OpenOffice] [HKEY_CURRENT_USER\Software\OpenOffice\Accessibility] [HKEY_CURRENT_USER\Software\OpenOffice\Accessibility\AtToolSupport] "SupportAssistiveTechnology"="true" <snip>
The AT support option is turned off by the default setting. I just commented the line for checking the option status in the previous revisions. For a better user experience, I think this option should be turned on by default. I will fix it in the branch firstly.
On Windows 7 sp1 64-bit with NVDA 2013.2 active AOO410m1(Build:9750) - Rev. 1540658 Rev.1540658 Not yet addressed at this rev. Tools --> Options --> Accessibility check box, or HKCU registry hack still needed. Gentle reminder :-)
"steve_y" committed SVN revision 1541823 into branches/ia2: Fix for i123643 - [ia2] IAccessible2 is not enabled automatically even with a...
@Steve, (In reply to SVN Robot from comment #4) > "steve_y" committed SVN revision 1541823 into branches/ia2: > Fix for i123643 - [ia2] IAccessible2 is not enabled automatically even with > a... the first build attempt #300 of ia2 branch r1541823 died horribly on the Buildbot. Is it related to this patch, or just mis-timed update that blew the scheduled build?
On Windows 7 sp1 64-bit with NVDA 2013.2 active AOO410m1(Build:9750) - Rev. 1542312 Rev.1542312 The Windows nightly buildbot of rev 1542312 with the ia2 branch merge has resolved this issue--partially. Unfortunately, the hard coding used causes an unintended consequence where if AT is deactivated (e.g. by turning off NVDA) OpenOffice can not again be launched for the same user without first deleting their per-user OpenOffice registry registrymodifications.xcu The hardcoded settings resulting in setting the OpenOffice regsitry .xcu file: <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</value></prop></item> Are then preventing the same configuration from running when AT is not active for the user.
@Steve, (In reply to V Stuart Foote from comment #6) > ... the hard coding used causes an unintended consequence where > if AT is deactivated (e.g. by turning off NVDA) OpenOffice can not again be > launched for the same user without first deleting their per-user OpenOffice > registry registrymodifications.xcu > > The hardcoded settings resulting in setting the OpenOffice regsitry .xcu > file: > <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</value></prop></item> > > Are then preventing the same configuration from running when AT is not > active for the user. Should this bug 123643 be closed and the related issue as in comment 6 be moved into a new issue? Or continue to keep it here? Stuart
I will fix it by remove the option checking for accessibility support. The accessibility support option is useless on windows now. It should be removed from UI later. (In reply to V Stuart Foote from comment #7) > @Steve, > (In reply to V Stuart Foote from comment #6) > > ... the hard coding used causes an unintended consequence where > > if AT is deactivated (e.g. by turning off NVDA) OpenOffice can not again be > > launched for the same user without first deleting their per-user OpenOffice > > registry registrymodifications.xcu > > > > The hardcoded settings resulting in setting the OpenOffice regsitry .xcu > > file: > > <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</value></prop></item> > > > > Are then preventing the same configuration from running when AT is not > > active for the user. > > Should this bug 123643 be closed and the related issue as in comment 6 be > moved into a new issue? Or continue to keep it here? > > Stuart
@Steve, (In reply to Steve Yin from comment #8) > I will fix it by remove the option checking for accessibility support. The > accessibility support option is useless on windows now. It should be removed > from UI later. > On Windows 7 sp1, 64-bit with /A Administrative install of AOO410m1(Build:9750) - Rev. 1547747 Rev.1547747 I am no longer seeing the issue of inability to launch after deactivation of AT, so at this point would say it WFM, and issue can be closed unless you have a more refined solution. Stuart
I can still reproduce the issue at the latest reversion. And I think it may reveal an issue on configuration part. I agree with you to open a new defect scripted by comment 6 and close this one. (In reply to V Stuart Foote from comment #9) > @Steve, > > (In reply to Steve Yin from comment #8) > > I will fix it by remove the option checking for accessibility support. The > > accessibility support option is useless on windows now. It should be removed > > from UI later. > > > On Windows 7 sp1, 64-bit with /A Administrative install of > AOO410m1(Build:9750) - Rev. 1547747 > Rev.1547747 > > I am no longer seeing the issue of inability to launch after deactivation of > AT, so at this point would say it WFM, and issue can be closed unless you > have a more refined solution. > > Stuart
@Steve, No things have changed. On an /A administrative load of rev 1549513. With PROCMON I'm watching the relaunch following deactivation of AT (NVDA 2013.2), I see the registrymodifications.xcu being recreated--including a check for GetEnableATToolSupport ( http://opengrok.adfinis-sygroup.org/source/search?q=GetEnableATToolSupport&defs=&refs=&path=&hist=&project=aoo-trunk )-- following the rewrite the soffice.bin threads and process closes cleanly and then the soffice.exe process. Don't have a symbols repository to use with dbghelp.dll so can't follow the exact calls. However, once the initial launch closes, I am now able to launch a second time and AOO comes up cleanly without the AT running. Before I had to physically delete the registrymodifications.xcu (was simplest to delete user profile) and that is no longer necessary. Only need now to launch a second time with "non-AT" registry.
Verifying this as Resolved Fixed. AOO410m1(Build:9750) - Rev. 1562109 Rev.1562109 Get reliable automatic activation of AT support. And reliable launch of OpenOffice after AT has been deactivated.