Closed Bug 1337935 Opened 4 years ago Closed 3 years ago

64-bit a11y clients cannot see content accessibles from 32-bit firefox

Categories

(Core :: Disability Access APIs, defect)

x86_64
Windows
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox54 --- affected

People

(Reporter: aklotz, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: aes+)

This is fallout from bug 1303060.

The real solution is more of a releng problem: We would need to ship both 32-bit and 64-bit handler DLLs with a 32-bit installation of Firefox.

In the absence of a 64-bit handler DLL, 64-bit a11y clients are not able to access the COM objects exposed by 32-bit content.

A simple workaround is to just run Win64 Firefox with the 64-bit a11y client.

This bug is more to note that the problem exists than anything.
I assume the same is true for a 32 bit client accessing 64 bit Firefox? That could be a problem for us, since NVDA (the app itself) is only ever 32 bit. Making users explicitly choose 32 bit Firefox might be okay as a temporary workaround, but it's not going to be workable long-term.
(In reply to James Teh [:Jamie] from comment #1)
> I assume the same is true for a 32 bit client accessing 64 bit Firefox? That
> could be a problem for us, since NVDA (the app itself) is only ever 32 bit.
> Making users explicitly choose 32 bit Firefox might be okay as a temporary
> workaround, but it's not going to be workable long-term.

Marco has confirmed that this is a problem when running NVDA against a 64-bit Nightly with |accessibility.handler.enabled = true|.

I'll bring it up at our a11y+e10s meeting tomorrow.
Whiteboard: aes+
gps, do you have any comments on the feasibility of adding the ability to build a 32-bit DLL from within a 64-bit build configuration?
Flags: needinfo?(gps)
Redirecting needinfo to glandium because he's got the toolchain/binaries situation on Windows more paged in than I do.

At the very least, we'll need to teach configure to locate multiple toolchains for visual studio, since the executables used for producing 32-bit binaries vary from those that produce 64-bit. We'll then need something in moz.build to denote that a binary must be 32-bit or requires multiple versions.
Flags: needinfo?(gps) → needinfo?(mh+mozilla)
glandium: ping? Any info here? This is blocking our ability to go 100% e10s rollout.
The build system is totally unable to deal with this, and dealing with it properly would require a lot of work. We did have gross hacks in place to cross-build the WOW64 stuff, and I'm grateful they could go away in bug 1339729.
Flags: needinfo?(mh+mozilla)
(In reply to James Teh [:Jamie] from comment #1)
> I assume the same is true for a 32 bit client accessing 64 bit Firefox? That
> could be a problem for us, since NVDA (the app itself) is only ever 32 bit.
> Making users explicitly choose 32 bit Firefox might be okay as a temporary
> workaround, but it's not going to be workable long-term.

This is our only answer - for NVDA, making 32-bit Firefox our only supported configuration. It would be great if NVDA could move toward fully supporting the proper bitness of the local machine to solve this in the future.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
I understand and respect your decision, but it's worth noting that we have no current plans to ship a 64 bit build. NVDA already supports most 64 bit apps, since cross-process calls are bitness independent and we ship 64 bit dlls for our in-process components. Aside from Firefox, there is no practical benefit for us to ship a fully 64 bit build. In contrast, there is a great deal of cost and many disadvantages: we have to ship and maintain two builds, user confusion as to the correct build, problems for users who run NVDA "portably" (off a USB drive, for example), breaking all existing add-ons with binary components, etc.
You need to log in before you can comment on or make changes to this bug.