1393600 - Handler <--> Proxy Interface Mismatch

Status: RESOLVED FIXED

(Core :: Disability Access APIs, enhancement, P1)

Description

[(No longer employed by Mozilla) Aaron Klotz]

The handler expects accessible proxies to be IAccessible2_3. If we export a different interface from content, the handler has to make an additional round-trip to obtain the correct one.

We should ensure that the interceptor correctly sends the expected interface so that we can avoid this extra work.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch

This patch brings into line the IID that is expected by the client and the IID that is being exported by the interceptor.

This significantly reduces inter-process QI traffic from our browser process because the expected vs actual interfaces now always match.

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e7f2eaf99d46116172266f2486a3682f845fc236
Bug 1393600: Prevent mismatches between the handler's expected interface and the one being provided by content; r=jimm

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/e7f2eaf99d46

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

Reopening due to bug 1395840. I'm going to back this out.

Comment 5

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

(Assuming this is P1)

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8becbd14ef2ae210917248e13f391ab4bc7a625a

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

Marco, could you please try out the try builds in comment 6 once they're ready? Thanks.

Comment 8

[Marco Zehe (:MarcoZ)]

I get an immediate crash of the tab, *any* tab, when running that try build. The crash i submitted is:
https://crash-stats.mozilla.com/report/index/61f0dab0-fea8-48c9-a480-8dca81170913

This is the 64 bit build, of course without symbols.

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

Was this unzipped or via the installer? You'll need to use the installer on this one, sorry for not mentioning that.

Comment 10

[Marco Zehe (:MarcoZ)]

It was the zipped one. Will try again. ;) Thanks!

Comment 11

[Marco Zehe (:MarcoZ)]

Still no luck. Symptoms are the same as before: Firefox behaves as if it was a very basic MSAA app. No IA2 related stuff is working or exposed. In the accessible tree, explored via NVDA's object navigation, I see no documents for loaded web pages, and the control information about the currently focused item (NVDA-key+F1) only gives me basic MSAA info, as if Firefox never had heard about any IAccessible2.

Comment 12

[am_dxer]

Tried the test builds on Windows 10 build 15063. Confirming Marco's findings in comment 11 with e10s enabled.

Comment 13

[(No longer employed by Mozilla) Aaron Klotz]

OK, I've got another build to try. Same as last time, use the installer please.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=91ff69e4c27f8d56be9c391f4c0fb92bb4887514

Comment 14

[Marco Zehe (:MarcoZ)]

(In reply to Aaron Klotz [:aklotz] (a11y work receiving priority right now, please send interceptor reviews to dmajor or handyman) from comment #13)
> OK, I've got another build to try. Same as last time, use the installer
> please.

Unfortunately still the same problem. Any remote content has no IAccessible2 and siblings support, just basic MSAA. Local content like about:support, however, works fine with IAccessible2 support.

Comment 15

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Marco Zehe (:MarcoZ) from comment #14)
> Unfortunately still the same problem. Any remote content has no IAccessible2
> and siblings support, just basic MSAA. Local content like about:support,
> however, works fine with IAccessible2 support.

How's this for annoying: Everything works fine on my local test build!

I wonder if this is some kind of strange thing like the previous version's handler is still loaded somewhere and thus the new version's handler isn't updated properly?

Comment 16

[Marco Zehe (:MarcoZ)]

Well, I uninstalled the regular Nightly from my machine, from what used to be the Control Panel applet, then installed the test build from the installer. I even tried the 32 bit one, same results. So the old handler must have disappeared from emory and disc when I uninstalled it.

Comment 17

[(No longer employed by Mozilla) Aaron Klotz]

David is going to try this out. See Comment 11 and Comment 13.

Comment 18

[Marco Zehe (:MarcoZ)]

1. Once you start the try build with NVDA running, check if virtual buffers are working. Make sure you are on a page from remote, not something like about:support.
2. Press NVDA+F1.
3. In the log viewer that appears, you get a bunch of info about the current object.
4. Scroll down to the last line.
a) If it says IAccessibleValue, you see the bug that I'm seeing.
b) If you see IAccessible2Attributes, you are not seeing my problem.

Comment 19

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

Using steps in comment 18 I also don't see IAccessible2 info in the nvda log on the 64 bit build from comment 13.

Comment 20

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

Setting 57 status to fix-optional since we will be making a special case final call on windows e10s a11y support early in beta cycle.

Comment 21

[(No longer employed by Mozilla) Aaron Klotz]

I was able to reproduce this on my Surface Book. For some reason NVDA is not sending the command to load the Gecko vbuf backend.

Comment 22

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e6ec7de0ed85cef78e86084cf94f7c5ab36fbfbf

Comment 23

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch (r2)

I think I found the problem. I changed one spot in the code that I shouldn't have.

Carrying forward r+ since it's the same patch less one diff chunk.

Comment 24

[(No longer employed by Mozilla) Aaron Klotz]

As for why I could not reproduce it locally, I believe it is because I had previously registered IA2 in the registry. By default this isn't necessary.

Comment 25

[(No longer employed by Mozilla) Aaron Klotz]

Still problems without that block though. More thought needs to go into this.

Comment 26

[James Teh [:Jamie]]

This doesn't really help, but just noting a couple of things here because I was curious and investigated them:

1. I was wondering why NVDA (out-proc) can't get the right interface even after the proxy gets injected. The answer is simple: NVDA doesn't support IAccessible2_3 yet; our proxy doesn't know about it.
2. I was wondering why IAccessible worked but IAccessible2 didn't. I figured that if IAccessible2 didn't work, nothing should work. The answer is that we're not actually using IAccessible on the child objects; accChild fails, so we never get them. We end up falling back to calling accName, etc. on the root accessible, but passing the unique id as the child id. Something to remember when dealing with this kind of thing in future: be sure to check the IAccessibleChildID reported in NVDA's dev info. If it shows a non-0 value, you're not dealing with the child IAccessible; accChild failed.

Comment 27

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Part 2: Use IAccessible when exporting to external processes

We need to use the existing IAccessible2_3 interface pointer for exporting to an external process, but that process may not recognize IA2. So we overwrite the IID in the serialized proxy with one that the client *will* recognize: IAccessible.

Comment 28

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a867ad57dcbcdb709e7b74bf22b4dc9893a68092

Comment 29

[(No longer employed by Mozilla) Aaron Klotz]

Alright Marco, let's try the one in comment 28!

Comment 30

[Marco Zehe (:MarcoZ)]

This build works as expected, in that it provides IAccessible2 in the manner NVDA expects. :) I'll reserve judgement on the perf improvement, since this try build seems to be generally very slow for me for some reason.

So I suggest landing these two, and I'll retest the actual perf improvement on a regular nightly build.

Comment 31

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e9cf1a5354ac88a80b32ff3276a7a71229d7db06
Bug 1393600: Prevent mismatches between the handler's expected interface and the one being provided by content; r=jimm

https://hg.mozilla.org/integration/mozilla-inbound/rev/6c07fa7775c903bd6c80db11f734b5f1af39f45f
Bug 1393600: Ensure that the handler sends a known interface to external clients; r=jimm

Comment 32

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/e9cf1a5354ac
https://hg.mozilla.org/mozilla-central/rev/6c07fa7775c9

Comment 33

[Marco Zehe (:MarcoZ)]

Aaron, can this be closed now, or do you have follow-ups still?

Comment 34

[(No longer employed by Mozilla) Aaron Klotz]

Ah, yes, thanks.