Closed Bug 1581441 Opened 5 years ago Closed 5 years ago

Fission a11y: When sandbox enabled, child/parent relationships broken for OOP iframe

Categories

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

All
Windows
defect

Tracking

()

RESOLVED FIXED
mozilla72
Fission Milestone M4
Tracking Status
firefox72 --- fixed

People

(Reporter: Jamie, Assigned: Jamie)

References

Details

Attachments

(1 file)

It seems I've (unintentionally) been testing my Windows Fission a11y work with the content sandbox disabled. When it's enabled:

  1. accChild(1) on the OuterDocAccessible for an OOP iframe fails with E_INVALIDARG, even though accChildCount returns 1 as expected.
  2. accParent on the embedded document returns null, even though the document can otherwise be accessed as expected.
Fission Milestone: --- → M4

Findings so far:

  1. For Fission, we send up the embedded iframe document from its content process to the parent process. Parent then sends this down to the embedder content process to return as the child of the iframe OuterDocAccessible.
  2. With sandboxing enabled, we must send the embedded document from parent to content using an mscom::PassthruProxy. This is why this doesn't fail with sandboxing disabled.
  3. In the embedder content process, when we try to unmarshal the passthru proxy to return the embedded document as the child of the OuterDocAccessible, we fail.
  4. When marshaling from the parent process, we're dealing with the handler if it's enabled. However, we already strip out the handler. I guess there must be a problem with what we marshal here?
  5. I eventually tracked the unmarshaling failure in (3) down to mscom::GetObjRefSize failing because the clsid of OBJREF_TYPE_CUSTOM is not CLSID_StdMarshal:
    https://searchfox.org/mozilla-central/rev/1fe0cf575841dbf3b7e159e88ba03260cd1354c0/ipc/mscom/Objref.cpp#323
  6. Instead, the clsid is {00000027-0000-0008-C000-000000000046}. Some Googling suggests this is CLSID_AggStdMarshal. Curiously, if I try to use this, the linker can't find the symbol, even though it seems to be defined in the same place in the Windows headers as CLSID_StdMarshal.
  7. When we use the handler, we do use the aggregated standard marshaler. I guess it must use a different clsid when aggregated.

For Fission, the parent process needs to take an Accessible sent up from one content process and send it down to another content process, where it will eventually be returned to the client.
If sandboxing is enabled, we must use a PassthruProxy, and if the handler is enabled, the handler will marshal the interface.
Even though we strip out the handler, the handler still marshals using the aggregated standard marshaler, which uses a different clsid (CLSID_AggStdMarshal).
When unmarshaling to return to the client, we call GetObjRefSize.
This previously didn't know about the aggregated standard marshaler, so it failed, causing E_INVALIDARG to be returned to the client.
Now, we just handle these clsids in the same way.

Pushed by aklotz@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/59f57b1d4737
mscom::GetObjRefSize: Correctly handle proxies marshaled by the aggregated standard marshaler. r=aklotz
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: