1467257 - IAccessible(ROLE_SYSTEM_TEXT): CoMarshalInterface fails; QueryInterface(IID_IUnknown) fails

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[gindi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180606100133

Steps to reproduce:

In Firefox main process, find an IAccessible object iacc and call CoMarshalInterface(istream, IID_IAccessible, iacc, MSHCTX_LOCAL, NULL, MSHLFLAGS_NORMAL).


Actual results:

For objects of role ROLE_SYSTEM_TEXT it fails and returns 0x8000FFFF. For other objects succeeds. Also succeeds if multi-process mode is off. I tested objects in web page.

Possible reason: iacc->QueryInterface(IID_IUnknown) fails for objects of this role.
Also QueryInterface(IID_IMarshal) fails for objects of this role.


Expected results:

CoMarshalInterface should return 0.

Comment 1

[gindi]

Tested with Firefox 61.0b10 and 62.0a1. In previous versions worked, but I don't know in which exactly version this started.

Comment 2

[Adrian Florinescu [:aflorinescu]]

Thank you for the bug report. Could you please be more detailed in the STR to help us reproduce and triage this issue. 
Best would be if you could provide a reduced test case for the above purpose.

Also, in comment 1 you say that this is tested with 61.0b10 and 62.0a1, so just to confirm: does this means that you can reproduce this issue with both versions? Also based on comment 1, if this is a regression, then could you perhaps use mozregression (https://mozilla.github.io/mozregression/) to find a regression range.

Comment 3

[gindi]

Strange, cannot reproduce when Firefox runs from mozregression, even when testing the same version (62.0a1), the same profile, the same pages, the same extensions, both multi-process.

Anyway, the whole story:

My program:
1. Injects a dll into the main Firefox process.
2. The dll finds an accessible object (calls AccessibleChildren recursively) or gets from point (calls AccessibleObjectFromPoint).
3. Then the dll marshals the found IAccessible to my process.

This is to make finding accessible objects faster. Normally makes faster ~100 times. In multi-process Firefox ~2 times. Also it allows to use ISimpleDOMNode and IAccessible2. Works with all objects in all my tested programs where dll injection is possible.

In Firefox 61.0b10 and 62.0a1 it does not work if the object has role ROLE_SYSTEM_TEXT.

Also I noticed that IAccessible::QueryInterface for ROLE_SYSTEM_TEXT objects fails if riid is IID_IUnknown. Works if IID_IAccessible or IID_IDispatch. CoMarshalInterface calls QueryInterface(IID_IUnknown) and fails when it fails.

Code to reproduce:

IAccessible* iacc=an_accessible_object_in_the_main_process_of_multiprocess_Firefox;
IStream* istream=NULL; CreateStreamOnHGlobal(0, TRUE, &stream);
HRESULT hr=CoMarshalInterface(istream, IID_IAccessible, iacc, MSHCTX_LOCAL, NULL, MSHLFLAGS_NORMAL);
if(hr!=0) ... //0x8000FFFF if object of role ROLE_SYSTEM_TEXT

Comment 4

[Adrian Florinescu [:aflorinescu]]

I'd like to triage this to its correct component but I'm not sure where it should go.
Aaron, any idea related to what we have here?

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

This is probably related to the handler.

I'm going to set this to a11y for now.

Comment 6

[James Teh [:Jamie]]

This is almost certainly a regression introduced in bug 1431256. An in-process caller trying to marshal a text leaf node to an out-of-process client is not a use case I considered. (Most of our clients either fetch accessibles in-process or fetch them out-of-process, but don't marshal instances between the two.)

This is going to be difficult to test because we don't have an in-process client which does something like this. Nevertheless, I'll try to investigate this.

Note that the reason you can't reproduce this with mozregression is that our COM handler (smart proxy) doesn't get registered unless you actually *install* the build of Firefox. Unfortunately, this requires entries to be added to the registry; it's not possible to use a COM handler without that. You can use multi-process Firefox without the handler, but it will be *much* slower in-process without it.

Comment 7

[James Teh [:Jamie]]

As noted above, we don't have a good way to test this kind of in-process code right now. We can write a specialised test case for it, but that's fairly involved and not something I have time to work on right now.

Gindi, in the interest of potentially getting this fixed sooner, would you be able to install and test this try build to see if it fixes your issue?
https://queue.taskcluster.net/v1/task/SXYFqPWHS1-TK-wF0IxSGw/runs/0/artifacts/public/build/target.installer.exe

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:Jamie, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Comment 9

[James Teh [:Jamie]]

Given that this doesn't seem to be impacting anyone directly right now, we'll just wait for Cache the World to ship, which will fix this.

Comment 10

[James Teh [:Jamie]]

This is resolved by Cache the World, which is enabled by default in Firefox 113.