Bugzilla

Okay. I think I've figured out why this breaks on some systems and not others.

MSAA (oleacc) can be handled by one of two COM proxy dlls:

1. oleacc.dll itself, clsid {03022430-ABC4-11D0-BDE2-00AA001A1953}.
2. The universal typelib marshaler, clsid {00020424-0000-0000-C000-000000000046}.

Which is registered depends on a number of factors, including 32/64 bit, Windows version, probably whether the system was updated from an earlier version of Windows... and just to make things more fun, app installers that decide to screw with the registry (even things like Adobe Reader).

Normally, this doesn't matter. Firefox has manifests which choose oleacc.dll for 64 bit builds and the typelib marshaler for 32 bit builds. Even if that's not the marshaler used by the rest of the system, it doesn't seem to matter. What does matter is that Firefox processes are consistent in which marshaler they use. And here's where we hit the problem.

1. When the skeleton UI appears, COM gets initialised in the parent process (but not by us); see comment 22 for discussion.
2. That means we can't initialise COM correctly, including setting up the marshaler we want (via the manifest).
3. On systems where the marshaler registered on the system is the same as the marshaler Firefox uses, everything is fine.
4. However, on systems where those differ (e.g. on 64 bit systems which use the typelib marshaler), we end up with one marshaler in the content process (the one Firefox chooses, since we explicitly initialise COM there) and a different marshaler in the parent process (the system chosen marshaler, since we failed to explicitly init COM there).
5. Everything blows up.

NVDA has a COM registration fixing tool which is supposed to correct the system marshaler, but this doesn't seem to be working, which explains why users who have reported they tried that tool are still seeing this problem.

So, to reliably reproduce this problem with a 64 bit build of Firefox:

1. Exit Firefox.
2. Press Windows+r, type regedit, press enter.
3. In the address bar, enter:
    `Computer\HKEY_CLASSES_ROOT\Interface\{618736E0-3C3D-11CF-810C-00AA00389B71}\ProxyStubClsid32`
4. Change the (Default) value to:
    `{00020424-0000-0000-C000-000000000046}`
5. Restart NVDA.
6. Start Firefox so that the skeleton appears.
7. Observe breakage.

If you run without the skeleton, everything works as expected.

Okay. I think I've figured out why this breaks on some systems and not others.

MSAA (oleacc) can be handled by one of two COM proxy dlls:

1. oleacc.dll itself, clsid {03022430-ABC4-11D0-BDE2-00AA001A1953}.
2. The universal typelib marshaler, clsid {00020424-0000-0000-C000-000000000046}.

Which is registered depends on a number of factors, including 32/64 bit, Windows version, probably whether the system was updated from an earlier version of Windows... and just to make things more fun, app installers that decide to screw with the registry (even things like Adobe Reader).

Normally, this doesn't matter. Firefox has manifests which choose oleacc.dll for 64 bit builds and the typelib marshaler for 32 bit builds. Even if that's not the marshaler used by the rest of the system, it doesn't seem to matter. What does matter is that Firefox processes are consistent in which marshaler they use. And here's where we hit the problem.

1. When the skeleton UI appears, COM gets initialised in the parent process (but not by us); see comment 22 for discussion.
2. That means we can't initialise COM correctly, including setting up the marshaler we want (via the manifest).
3. On systems where the marshaler registered on the system is the same as the marshaler Firefox uses, everything is fine.
4. However, on systems where those differ (e.g. on 64 bit systems which use the typelib marshaler), we end up with one marshaler in the content process (the one Firefox chooses, since we explicitly initialise COM there) and a different marshaler in the parent process (the system chosen marshaler, since we failed to explicitly init COM there).
5. Everything blows up.

NVDA has a COM registration fixing tool which is supposed to correct the system marshaler, but this [doesn't seem to be working](https://github.com/nvaccess/nvda/issues/9039#issuecomment-857356117), which explains why users who have reported they tried that tool are still seeing this problem.

So, to reliably reproduce this problem with a 64 bit build of Firefox and NVDA:

1. Exit Firefox.
2. Press Windows+r, type regedit, press enter.
3. In the address bar, enter:
    `Computer\HKEY_CLASSES_ROOT\Interface\{618736E0-3C3D-11CF-810C-00AA00389B71}\ProxyStubClsid32`
4. Change the (Default) value to:
    `{00020424-0000-0000-C000-000000000046}`
5. Restart NVDA.
6. Start Firefox so that the skeleton appears.
7. Observe breakage.

If you run without the skeleton, everything works as expected.

Okay. I think I've figured out why this breaks on some systems and not others.

MSAA (oleacc) can be handled by one of two COM proxy dlls:

1. oleacc.dll itself, clsid {03022430-ABC4-11D0-BDE2-00AA001A1953}.
2. The universal typelib marshaler, clsid {00020424-0000-0000-C000-000000000046}.

Which is registered depends on a number of factors, including 32/64 bit, Windows version, probably whether the system was updated from an earlier version of Windows... and just to make things more fun, app installers that decide to screw with the registry (even things like Adobe Reader).

Firefox uses manifests to specify a marshaler. It chooses oleacc.dll for 64 bit builds. For 32 bit builds, it chooses based on the version of Windows and what's registered on the system. Even if Firefox's choice is not the marshaler used by the rest of the system, it doesn't seem to matter. What does matter is that Firefox processes are consistent in which marshaler they use. And here's where we hit the problem.

1. When the skeleton UI appears, COM gets initialised in the parent process (but not by us); see comment 22 for discussion.
2. That means we can't initialise COM correctly, including setting up the marshaler we want (via the manifest).
3. On systems where the marshaler registered on the system is the same as the marshaler Firefox uses, everything is fine.
4. However, on systems where those differ (e.g. on 64 bit systems which use the typelib marshaler), we end up with one marshaler in the content process (the one Firefox chooses, since we explicitly initialise COM there) and a different marshaler in the parent process (the system chosen marshaler, since we failed to explicitly init COM there).
5. Everything blows up.

NVDA has a COM registration fixing tool which is supposed to correct the system marshaler, but this [doesn't seem to be working](https://github.com/nvaccess/nvda/issues/9039#issuecomment-857356117), which explains why users who have reported they tried that tool are still seeing this problem.

So, to reliably reproduce this problem with a 64 bit build of Firefox and NVDA:

1. Exit Firefox.
2. Press Windows+r, type regedit, press enter.
3. In the address bar, enter:
    `Computer\HKEY_CLASSES_ROOT\Interface\{618736E0-3C3D-11CF-810C-00AA00389B71}\ProxyStubClsid32`
4. Change the (Default) value to:
    `{00020424-0000-0000-C000-000000000046}`
5. Restart NVDA.
6. Start Firefox so that the skeleton appears.
7. Observe breakage.

If you run without the skeleton, everything works as expected.