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

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[David Bolter [:davidb] (NeedInfo me for attention)]

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

[James Teh [:Jamie]]

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

[James Teh [:Jamie]]

See comment 1.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Magnifier follows keyboard focus in nightly with tabs.remote.autostart false. This is pretty bad that we didn't catch this.

Comment 4

[James Teh [:Jamie]]

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?

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

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

[James Teh [:Jamie]]

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

[James Teh [:Jamie]]

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

Bug 1421144.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

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.