Created attachment 80494 [details]
regsvr32 error on load of UAccCOM.dll - build 1463876

Unable to enable IAccessible2 for latest ia2 branch build - 1463876.

Install as Administrator, initial run as Administrator

Toggle Tools -> Options -> Accessibility -> Support assistive technology tools with restart.

Nothing will engage IAccessible2 -- NVDA 2012.3.1 and AccProbe remain MSAA mode only.

Attempts to manually register UAccCOM.dll with regsvr32 fail with attached error.

Marking as confirmed. Something needs to be adjusted to get IAccessible2 to activate as needed without a lot of user tweeking.

-- Seems like FireFox browser can not be running during installation --

An IAccessible2 conflict?

Making additional attempts to install and configure. Restarted system and removed per-user AppData\Roaming\ApachedOpenOffice\4\user profiles (Administrator and normal user account).

FireFox 20.0 was NOT running. Launched AOO4 ia2 as Administrator. Toggled Accessibility -> Support assistive technology tools and exited.

Launch AccProbe and NVDA then launch AOO4 ia2 as normal user.  IAccessible2 activates, AccProbe and NVDA fully respond.

Check of regedit session now shows the UAccCOM.dll registered:

HKEY_CLASSES_ROOT\TypeLib\{19ECB1B0-9376-4FF9-B580-223FC9C200B8}
HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{19ECB1B0-9376-4FF9-B580-223FC9C200B8}
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{19ECB1B0-9376-4FF9-B580-223FC9C200B8}

And CLSIDs with matching Software classes
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{152884E0-268B-4481-9AE7-1B372D3AA97F}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{519A64CD-F6A6-4793-BE50-4E36C4C593EF}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{6D8AB08B-CCE9-471E-8A41-35773D5263F5}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{730A561B-1AF6-49E1-9C04-9A2F48CD8512}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{73A45800-7A62-432C-A1A6-BF8852994331}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{79CE1450-1F61-48E2-BF76-C07BD10105E2}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8745CF0C-3104-4BAE-B7D0-D7B1717C006E}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{92BAA62D-535A-4EAB-9ABB-BFA60B7A6DB6}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{9FD9BA47-70AF-4160-99F1-526F2B9F111B}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{AA49F20E-BB4E-400D-A5B0-6F5B7B770227}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{CC55D71B-1828-4EE0-89E2-C3749CF9C9AB}
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{CF8DF8BA-44FE-4B10-BD2E-8C8CB322485F}

I don't have time to verify this right now, but I suspect UAccCOM.dll is registering a proxy for the IAccessible2 interfaces and maybe even IAccessible as well. It absolutely should not do this. IAccessible2 proxying should be handled by the AT as was decided some time ago in the IA2 community. IAccessible should be left alone.

Can someone explain (or point me at an explanation) of why UAccCOM.dll needs to be registered system wide? I'm guessing there is some sort of accessibility IPC going on between OpenOffice processes that needs to be proxied, but I'm not clear on why. Even if this *is* necessary, it's possible to load a COM proxy DLL for your own processes without registering it system wide.

Is there a way to avoid registry operation for an out-of-process COM server? The current solution is temporary. Besides the proxy issue raised by James, it seems registering the dll during AOO installation is the only way to avoid privilege problem.

But there are one issue related on the COM self-reg process. https://issues.apache.org/ooo/show_bug.cgi?id=107562
It will lead a deadlock during the dll self-registration and freeze the installation process.

(In reply to Steve Yin from comment #6)
> Is there a way to avoid registry operation for an out-of-process COM server?
Yes, but I'm still curious as to why you need a cross-process COM server as I asked in comment #5.

You can use a proxy without registering it in the registry by getting the class object from the proxy dll using DllGetClassObject, registering the class object with CoRegisterClassObject and registering each interface you need proxied with CoRegisterPsClsid. You must do this in every process that needs the proxying. If you do indeed need this, it'd certainly be easier to just register it system wide in the installer.

(In reply to Steve Yin from comment #7)
> But there are one issue related on the COM self-reg process.
> https://issues.apache.org/ooo/show_bug.cgi?id=107562
> It will lead a deadlock during the dll self-registration and freeze the
> installation process.
I don't follow. I thought the proxy was in UAccCOM.dll, not sal3.dll. UAccCOM.dll shouldn't be doing anything like that in DllMain. Unless I'm missing something, in the installer, you should just load UAccCOM.dll and call DllRegisterServer. The installer system probably has a way to do this for COM dlls in general; NSIS certainly does.

(In reply to James Teh from comment #8)
> If you do indeed need [a proxy dll], it'd certainly be easier to
> just register it system wide in the installer.
I just took a look at the code and it looks like you are creating proxies for IA2. If you do need these, then registering them system wide isn't an option because it will conflict with AT proxying for IA2.

Here's some code which registers proxies without using the registry:
http://community.nvda-project.org/browser/nvdaHelper/remote/IA2Support.cpp#L62

Hi James,

Thanks for your suggestions. 

The root cause for this issue is UAccCOM.dll is created without a standard and public IAccessible2 proxy, it makes a private proxy. Because Symphony started to implement IA2 support from 2006, at that time there was no any standard IAccessible2 proxy available.

I will try to modify it later. Thanks.


(In reply to James Teh from comment #9)
> (In reply to James Teh from comment #8)
> > If you do indeed need [a proxy dll], it'd certainly be easier to
> > just register it system wide in the installer.
> I just took a look at the code and it looks like you are creating proxies
> for IA2. If you do need these, then registering them system wide isn't an
> option because it will conflict with AT proxying for IA2.
> 
> Here's some code which registers proxies without using the registry:
> http://community.nvda-project.org/browser/nvdaHelper/remote/IA2Support.
> cpp#L62

(In reply to Steve Yin from comment #10)
> The root cause for this issue is UAccCOM.dll is created without a standard
> and public IAccessible2 proxy, it makes a private proxy. Because Symphony
> started to implement IA2 support from 2006, at that time there was no any
> standard IAccessible2 proxy available.
You still can't register the standard proxy system wide without potentially breaking ATs on uninstallation. This is why the IA2 community agreed a few years ago that ATs would handle proxy registration themselves.

I'm guessing Symphony needs to communicate across processes using its IA2 subclasses (IMAccessible, etc.). If that is the case, you may need a proxy for the IA2 interfaces; I'm not 100% certain. If you do, the only way you can get around this is to register them per-process with CoRegisterPsClsid, etc. instead of using the registry.

(In reply to James Teh from comment #11)
> (In reply to Steve Yin from comment #10)
> > The root cause for this issue is UAccCOM.dll is created without a standard
> > and public IAccessible2 proxy, it makes a private proxy. Because Symphony
> > started to implement IA2 support from 2006, at that time there was no any
> > standard IAccessible2 proxy available.
> You still can't register the standard proxy system wide without potentially
> breaking ATs on uninstallation. This is why the IA2 community agreed a few
> years ago that ATs would handle proxy registration themselves.
> 
> I'm guessing Symphony needs to communicate across processes using its IA2
> subclasses (IMAccessible, etc.). If that is the case, you may need a proxy
> for the IA2 interfaces; I'm not 100% certain. If you do, the only way you
> can get around this is to register them per-process with CoRegisterPsClsid,
> etc. instead of using the registry.

It seems besides IA2 interfaces, no out-of-process requirement for UAccCOM.dll. I think the IA2 proxy can be moved out from UAccCOM.dll.

Another problem is, the IA2 idl file used by UAccCOM.dll is not a standard version. But the implemented interfaces are almost same with the standard one. I think this two issues can be fixed before or after the branch integration. Before that I will check in a temp fix (self-reg) for this bug in the branch for testing use.

(In reply to Steve Yin from comment #12)
> It seems besides IA2 interfaces, no out-of-process requirement for
> UAccCOM.dll.
In that case, why do you need to register it system wide at all? Is there cross-thread communication? Or is it something to do with the coclasses?

I dug into this a little further. With the current build (1536988), UAccCOM is including IAccessible in its typelib. This means that when UAccCOM's typelib is registered, it registers as the typelib for IAccessible. This is very bad and definitely shouldn't be the case. This is why it is breaking ATs when installing/uninstalling OOo, since IAccessible is proxied via its typelib. You can fix this easily by adding an importlib statement for oleacc.dll in the library definition, as follows:
library UACCCOMLib
{
	importlib("stdole32.tlb");
	importlib("stdole2.tlb");
	importlib("oleacc.dll");
...

(In reply to James Teh from comment #13)
> (In reply to Steve Yin from comment #12)
> > It seems besides IA2 interfaces, no out-of-process requirement for
> > UAccCOM.dll.
> In that case, why do you need to register it system wide at all? Is there
> cross-thread communication? Or is it something to do with the coclasses?
> 
> I dug into this a little further. With the current build (1536988), UAccCOM
> is including IAccessible in its typelib. This means that when UAccCOM's
> typelib is registered, it registers as the typelib for IAccessible. This is
> very bad and definitely shouldn't be the case. This is why it is breaking
> ATs when installing/uninstalling OOo, since IAccessible is proxied via its
> typelib. You can fix this easily by adding an importlib statement for
> oleacc.dll in the library definition, as follows:
> library UACCCOMLib
> {
> 	importlib("stdole32.tlb");
> 	importlib("stdole2.tlb");
> 	importlib("oleacc.dll");
> ...

Hi Jamie,

It is a known issue from Symphony. I just fixed it in the branch with updating new ia2 idl files. And introduced "side by side" for activating the dll.

(In reply to Steve Yin from comment #14)
> It is a known issue from Symphony. I just fixed it in the branch with
> updating new ia2 idl files.
Ideally, you still need the importlib statement for oleacc.dll in the library block. The typelib for IAccessible shouldn't ever be redefined.

> And introduced "side by side" for activating the
> dll.
Do you mean using an application manifest? That will work nicely and is a lot easier than CoRegisterClassObject and friends. I didn't think of that option for some reason. :)

I note the 1536988 build still seems to be registering UAccCOM.dll in the registry. Is this change more recent than that build?

(In reply to James Teh from comment #15)
> (In reply to Steve Yin from comment #14)
> > It is a known issue from Symphony. I just fixed it in the branch with
> > updating new ia2 idl files.
> Ideally, you still need the importlib statement for oleacc.dll in the
> library block. The typelib for IAccessible shouldn't ever be redefined.

You are right, Jamie. I will add it.

> > And introduced "side by side" for activating the
> > dll.
> Do you mean using an application manifest? That will work nicely and is a
> lot easier than CoRegisterClassObject and friends. I didn't think of that
> option for some reason. :)
> 
> I note the 1536988 build still seems to be registering UAccCOM.dll in the
> registry. Is this change more recent than that build?

Yes, by embedding a manifest into the dll and calling several actctx apis to activate. :)

I just submitted the code several hours ago. I think the build will be ready at noon tomorrow.

Thanks for your help!

When I delete my OO config data and start OO, it doesn't seem to enable IA2 automatically based on the SPI_SETSCREENREADER flag. I thought it used to do this. Am I missing something or did this change at some point? Should I file another bug for this?

(In reply to Steve Yin from comment #16)
> Yes, by embedding a manifest into the dll and calling several actctx apis to
> activate. :)
> I just submitted the code several hours ago. I think the build will be ready
> at noon tomorrow.
I tested with the 1538508 build. It doesn't register UAccCOM.dll but still works for me, which is excellent. Thanks! Stuart is experiencing trouble with it (bug 123640), but I can't reproduce this and suspect it might be due to UAccCOM.dll not being unregistered by the previous build.

The only thing is that I don't see the importlib for oleacc.dll in svn yet. I'm guessing you just haven't had a chance to do this yet, but it should be done before this bug is closed.

(In reply to James Teh from comment #17)
> When I delete my OO config data and start OO, it doesn't seem to enable IA2
> automatically based on the SPI_SETSCREENREADER flag.
Filed bug 123643 for this.

(In reply to James Teh from comment #18)
> (In reply to Steve Yin from comment #16)
> > Yes, by embedding a manifest into the dll and calling several actctx apis to
> > activate. :)
> > I just submitted the code several hours ago. I think the build will be ready
> > at noon tomorrow.
> I tested with the 1538508 build. It doesn't register UAccCOM.dll but still
> works for me, which is excellent. Thanks! Stuart is experiencing trouble
> with it (bug 123640), but I can't reproduce this and suspect it might be due
> to UAccCOM.dll not being unregistered by the previous build.
> 
> The only thing is that I don't see the importlib for oleacc.dll in svn yet.
> I'm guessing you just haven't had a chance to do this yet, but it should be
> done before this bug is closed.

Sorry for that. I took a day off yesterday. The importlib was added just now. This defect will be closed after the next build is tested.

verified fixed Windows 7 sp1 64-bit ia2 build
AOO410m1(Build:9750)  -  Rev. 1539225
Rev.1539225

First launch (or %APPDATA%\OpenOffice removed) as non-privileged user is fully active in AT (NVDA running with Accprobe utility monitoring).

@Jamie, are the UAccCOM and oleacc.dll changes Steve made everything you'd expected? Are we good to close this issue?

Everything looks fine as far as I can tell.

(In reply to James Teh from comment #22)
> Everything looks fine as far as I can tell.

Good news!