a11y+e10s broken on Windows 10 creators update

RESOLVED FIXED in Firefox 55

Status

()

defect
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: aklotz, Assigned: aklotz)

Tracking

Trunk
mozilla55
x86
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox55 fixed)

Details

(Whiteboard: aes+)

Attachments

(1 attachment)

This is fallout from bug 1348069 which also landed on 55.

Creator's update got rid of the IAccessible typelib on 32-bit and replaced it with a proxy dll. This means that our manifest overrides are invalid on the Creator's Update. :-(

Now I need to figure out a way to handle this gracefully...
A couple of ideas:

1) manually pushing the correct activation context in our startup code only when needed;
2) getting rid of the manifest override and using the updater to fix corrupted IAccessible entries in the registry if they point to missing or non-system components.
The problem is that there is a typelib entry in the registry for the IAccessible interface that is provided by pre-creators update Windows. This registry entry is sometimes modified by third-party software installers to point to a third-party component. The third-party uninstaller does not revert the registry change, however, so some systems are left with a registry value that now points to a non-existent location, thus breaking anything that relied on that system component to be there.

It is particularly bad for Firefox on e10s because it causes marshaling failures which subsequently triggers a fatal IPDL error.

The idea is that we could detect whether the registry entry is dangling and correct it during PostUpdate.

Matt, what is your opinion on this?
Flags: needinfo?(mhowell)
To make sure I have this right, the plan is to look under the IAccessible typelib entry and make sure the file it points to for 32-bit exists? And if not, point it back to the system oleacc.dll? Yeah, that sounds like something we could do in PostUpdate.
Flags: needinfo?(mhowell)
(In reply to Matt Howell [:mhowell] from comment #3)
> To make sure I have this right, the plan is to look under the IAccessible
> typelib entry and make sure the file it points to for 32-bit exists? And if
> not, point it back to the system oleacc.dll? Yeah, that sounds like
> something we could do in PostUpdate.

Pretty much, yeah.
Comment on attachment 8862151 [details]
Bug 1358276: Add FixCorruptOleAccRegistration to PostUpdate;

https://reviewboard.mozilla.org/r/134130/#review137026

::: browser/installer/windows/nsis/shared.nsh:933
(Diff revision 1)
> +!define IID_IAccessible "{618736E0-3C3D-11CF-810C-00AA00389B71}"
> +!define CLSID_UniversalMarshaler "{00020404-0000-0000-C000-000000000046}"
> +!define OleAccTypeLib "{1EA4DBF0-3C3B-11CF-810C-00AA00389B71}"
> +!define OleAccTypeLibVersion "1.1"
> +Function FixCorruptOleAccRegistration
> +  ${If} "${ARCH}" == "x64"

Just wrap the whole function in
!ifndef HAVE_64BIT_BUILD
!endif
Attachment #8862151 - Flags: review?(mhowell) → review+
Pushed by aklotz@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/22485a2a6eb4
Add FixCorruptOleAccRegistration to PostUpdate; r=mhowell
Depends on: 1360371
https://hg.mozilla.org/mozilla-central/rev/22485a2a6eb4
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Blocks: 1372357
You need to log in before you can comment on or make changes to this bug.