This was on Windows 7 sp1 64-bit
NVDA 2013.2
Accprobe 1.2.1.1
JRE 1.7u45
JavaFerret/JavaMonkey v2.0.2

Version: 4.2.0.0.beta1
Build ID: f4ca7b35f580827ad2c69ea6d29f7c9b48ebbac7

Confirming able to activate IAccessible2 by enabling "experimental features", but was not able to activate Java JRE w/JAB based AT.

4.2.0.0beta1+ builds on Windows 7 sp1 64-bit

Version: 4.2.0.0.beta1+
Build ID: 12ebbb7e471d851eec940a47e6737c7c89d0f7f8
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-11-25_23:50:44

On Windows 7 sp1, 64-bit with a full installation of 4.2.0 RC1

LibreOffice
Version: 4.2.0.1
Build ID: 7bf567613a536ded11709b952950c9e8f7181a4a

In working the paired issues of bug 72647 ang bug 71946, I'm now back over to one of Cloph's release build configurations.  Unfortunately, the Java Access Bridge based AT support exclusively comes up with the 4.2.0.1 RC1 build.

I am unable to force the IAccessible2 AT support to activate with any combination of LibreOffice registry or Windows registry configuration.

If the Tools -> Options -> Advanced: enable experimental features is checked, to build forces Java Access Bridge based accessibility active and then errors that a JRE has not been selected.

This really is not an acceptable UX behavior. There should be smooth toggle between the legacy JAB based AT and the experimental IAccessible2 based AT support. If it can not be corrected, we may need to pull the legacy JAB out as done already for master, or possibly set IAccessible2 active by default in some fashion--making the JAB based AT the alternate.

Setting mab4.2

If you have enabled experimental mode, and you have an AT running [!!!] that requests the accessiblity handle from the app - *then* and only then will the IA2 support be used.

> I am unable to force the IAccessible2 AT support to activate with any
> combination of LibreOffice registry or Windows registry configuration.

IMHO we would do better to work out why it is not activating than trying to add odd extra user configuration settings :-) it should "just work".

> or possibly set IAccessible2 active by default in some fashion--making the
> JAB based AT the alternate.

JAB is only activated -after- the IAccessible2 work fails to launch / activate / work.

Having said that IAcc2 has a check to ensure that there is an AT running that requests, that code is here [ wow it has moved into a super-ugly #ifdef WNT when I had moved it nicely into the component itself which would simply refuse to activate if there was no AT registered - is there a reason for that Michael ? ]

#ifdef _WIN32
            bool bTryIAcc2 = ( officecfg::Office::Common::Misc::ExperimentalMode::get( xContext ) &&
                               !getenv ("SAL_DISABLE_IACCESSIBLE2") );

            if ( bTryIAcc2 ) // Windows only really
            {
                if (!HasAtHook() && !getenv("SAL_FORCE_IACCESSIBLE2"))
                {
                    SAL_INFO("vcl", "Apparently no running AT -> "
                            "not enabling IAccessible2 integration");
                }
                else
                {
                    try {
                        pSVData->mxAccessBridge
                            = css::accessibility::MSAAService::create(xContext);
                        SAL_INFO("vcl", "got IAccessible2 bridge");
                        return true;
                    } catch (css::uno::DeploymentException & e) {
                        SAL_INFO(
                            "vcl",
                            "got no IAccessible2 bridge, \"" << e.Message
                                << "\", falling back to java");
                    }
                }
            }
            else
                SAL_INFO( "vcl", "IAccessible2 disabled, falling back to java" );
#endif

cf. svdata.cxx

#ifdef _WIN32
bool HasAtHook()
{
    BOOL bIsRunning = FALSE;
    // pvParam must be BOOL
    return SystemParametersInfo(SPI_GETSCREENREADER, 0, &bIsRunning, 0)
        && bIsRunning;
}
#endif

My suspicion would be using something that is not registered as a running screenreader and falling into that pit ? [ such as an at-poke type tool ? ]

Michael - why did we re-instate this horrible 'HasAtHook' and a ton of conditionals there ? Why have a:

#ifdef _WIN32
bool HasAtHook()

#ifdef inside the windows backend ? or did I screw something up there ? it seemed to belong elegantly inside the (windows specific) winaccessibility component - surely ?

So, moved over to a /A administrative install of TB-42 build of the 4.2.0.1 branch

Version: 4.2.0.1.0+
Build ID: 8d00de2114f148857291aee9a5dc31e92597412d
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-18_23:48:42

With this build, I am able to activate IAccessible2 support. And to then toggle on Java Access Bridge based support by unchecking Tools -> Options -> Advanced: Enable experimental features. This is closer to the expected behavior.

Nothing jumps out from the additional commits included in the TB build.

Any thoughts on what could be different between the working TB-42 build and the TDF infra builds that would cause the differing behavior for using IAccessible2?

(In reply to comment #5)
> Any thoughts on what could be different between the working TB-42 build and
> the TDF infra builds that would cause the differing behavior for using
> IAccessible2?

on the 4.2 branch the configure flag --enable-ia2 is still required;
not sure if the release builds have it?


(In reply to comment #4)
> Michael - why did we re-instate this horrible 'HasAtHook' and a ton of
> conditionals there ? Why have a:
> 
> #ifdef _WIN32
> bool HasAtHook()
> 
> #ifdef inside the windows backend ? or did I screw something up there ? it
> seemed to belong elegantly inside the (windows specific) winaccessibility
> component - surely ?

perhaps the #ifdef here is rather pointless but while the HasAtHook was elegantly inside winaccessibility it also elegantly caused loading that library on every startup, even if no AT is running.

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=63592dae83016ead525276a4bf42dd1fa4766ef3&h=libreoffice-4-2

fdo#71946: LibreOfficeWin32.conf: add --enable-ia2


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.

cloph gave me a hint on irc, hope that should fix it for 4.2 branch

As mentioned, the TB-42 builds are OK--just the TDF build of 4.2.0.1 is flaky regards the AT support, now have to wait two weeks for the 4.2.0.2 build to see if any improvement with the --enable-ia2 build flag? 

Checked and Thorsten's TB 42 build that works does use the --enable-ia2 flag.

(In reply to comment #4)
> My suspicion would be using something that is not registered as a running
> screenreader and falling into that pit ? [ such as an at-poke type tool ? ]
> 

I usually work with NVDA 2013.2 build active, I'm pretty sure it issues the SPI_SETSCREENREADER flag for consumption by http://opengrok.libreoffice.org/xref/core/vcl/win/source/window/salframe.cxx (ref http://support.microsoft.com/KB/180958 ).

> but while the HasAtHook was elegantly inside winaccessibility it also
> elegantly caused loading that library on every startup, even if
> no AT is running.

Hah :-) fair cop. I guess we should prolly also avoid initializing JAB with the same filter - otherwise if you start LO and then your AT you'll get JAB, and the other way around IA2 which could be confusing.

Anyhow - thanks for finding / fixing the config. problem ! =)