Microsoft magnifier.exe ability to follow keyboard focus doesn't seem to work with Firefox

NEW
Unassigned

Status

()

a year ago
a year ago

People

(Reporter: davidb, Unassigned)

Tracking

57 Branch
Points:
---

Firefox Tracking Flags

(firefox57 affected)

Details

Just one of many tools I haven't tested in a long time. Today I did and it wasn't a perfect experience.

When you set the preference to have the magnifier follow keyboard focus, when you tab to something off screen there is a visual jump but it returns to where it was. It is like it tries but fails and comes back.

Comment 1

a year ago
David, could you test this with e10s disabled? (I'd do it myself, but inability to see it might make the results gathering process somewhat problematic. :) )

I notice IAccessible::accFocus on the root accessible is broken for e10s, but I'm pretty sure it worked before e10s. That's definitely a place to start looking if it works properly with non-e10s.

Comment 2

a year ago
See comment 1.
Flags: needinfo?(dbolter)
Magnifier follows keyboard focus in nightly with tabs.remote.autostart false. This is pretty bad that we didn't catch this.
status-firefox57: --- → affected
Flags: needinfo?(dbolter)

Comment 4

a year ago
Try build which fixes accFocus on the root accessible for e10s:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=143e916814d4418ab44434a77e925fa7d69fa4a6

David, would you be able to test with Magnifier?
Flags: needinfo?(dbolter)
Sorry for quick vague comment: I've encountered some weirdness and I (or someone) need to do more testing (when I find a space of time).

Comment 6

a year ago
Based on a quick discussion with David, we feel that accFocus probably isn't the issue for Magnifier... at least, not the whole issue. I'm going to open a separate bug for accFocus anyway, since it is breaking something in NVDA, which means we'll get this fix either way.

Another possibility is that our handler caching is causing some problems. (UIA will hit this if it's allowed to run in-proc.) I'm not sure when we fire location change events; firing them on all accessibles while scrolling would be pretty expensive for everyone, so it's possible we don't do it. However, that would also mean our accLocation cache might not get invalidated.

I'd suggest testing Magnifier with the accessibility.handler.enabled pref set to false.

Comment 7

a year ago
(In reply to James Teh [:Jamie] from comment #6)
> I'm going to open
> a separate bug for accFocus anyway

Bug 1421144.
Okay, tested this morning, nightly and the try build, with the handler enabled and disabled, seems to be the same broken behaviour. The weird part is that sometimes the first page works (in nearly all testing sessions), and magnifier scroll view follows keyboard focus, but trying a new tab quickly shows the broken behaviour.

I had thought maybe the scroll view was moving the mouse pointer over a DOM element that focuses on mouseover... but that doesn't appear to be the case.
Flags: needinfo?(dbolter)
You need to log in before you can comment on or make changes to this bug.