646360 - Plugins should be beneath the document in the accessibility hierarchy

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

In Firefox <= 3.6, the document accessible which embedded a plugin was the parent of the plugin window accessible, which meant that the document was part of the plugin's ancestry. This occurred because each document had its own window (HWND) which was the parent of any plugin windows it created. In Firefox >= 4, there is only one HWND. This means that the parent of the plugin window accessible is the top level Firefox frame accessible, which in turn means that the document is no longer part of the plugin's ancestry. A way needs to be found to fix the hierarchy so that the document is part of the plugin's ancestry, which is needed to determine the document which embeds a plugin.

A work around for this problem is to use NAVRELATION_EMBEDS on the top level frame accessible to find the document in the active tab. However, this is extremely hacky or inelegant at best. It also only works for plugins in the current tab (though there aren't any realistic use cases for examining plugins in background tabs).

Comment 1

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #0)
> A work around for this problem is to use NAVRELATION_EMBEDS on the top level
> frame accessible to find the document in the active tab.
To implement this work around, for Firefox <= 10, we got to the top level frame accessible by simply retrieving the parent of the GeckoPluginWindow client accessible. However, in Firefox >= 11, the parent of the GeckoPluginWindow client accessible is an oleacc generated client accessible and its parent is an oleacc generated window accessible, meaning that we have to walk up three parents instead of one to get to the top level frame accessible.

It seems there is a MozillaWindowClass HWND between the GeckoPluginWindow HWND and the main browser HWND. This was present in Firefox <= 10 as well. However, in Firefox <= 10, WM_GETOBJECT with this wrapper HWND and OBJID_CLIENT returned the top level frame accessible, even though that accessible actually belongs to the parent HWND. In Firefox >= 11, Gecko doesn't handle WM_GETOBJECT in this case, causing oleacc to create a generic object.

The behaviour in Firefox <= 10 is probably not quite correct, as it's returning a client accessible for the wrong HWND, so I'm not necessarily suggesting that this should be reinstated. However, I'm curious as to why this changed, as I don't recall any changes related to WM_GETOBJECT and any unexplainable changes in this area are likely to bite us later.

Comment 2

[alexander :surkov (:asurkov)]

accessible hierarchy:
root document (has associated HWND)
  tab document
    embed element
      plugin window and plugin document

window hierarchy:
main browser HWND
  MozillaWindowClass
    GeckoPluginWindow

If embed element will be exposed with MozillaWindowClass HWND and WM_GETOBJECT for this HWND returns embed element then does it cause/fix any problems and does it look like reasonable solution?

Comment 3

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #2)
> If embed element will be exposed with MozillaWindowClass HWND and
> WM_GETOBJECT for this HWND returns embed element then does it cause/fix any
> problems and does it look like reasonable solution?
In theory, that should work nicely and completely solves this bug, assuming the MozillaWindowClass wrapper doesn't disappear in the future. Very nice thinking! :)

Note that WindowFromAccessibleObject on the embed element will probably return the wrong window, as the oleacc generated window object is missing, but IAccessible2::windowHandle will be correct. Fixing WindowFromAccessibleObject requires bug 441553.

Note also that we've hacked around this in NVDA for both Firefox <= 10 and Firefox 11/12. I still think this is a much more elegant solution, but it's not critical for us, assuming NAVRELATION_EMBEDS works correctly.

Comment 4

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #2)
> If embed element will be exposed with MozillaWindowClass HWND
Sorry. Actually, this part of the solution will cause problems for NVDA due to the algorithm we use to determine whether an object is inside a given document. If the object's HWND is a descendant of the document HWND, we assume it is part of the document, which isn't necessarily true in this case. This code exists to support Firefox <= 3.6. I'm happy to discuss changing this, but it'll definitely break backwards compatibility. If the embed element is exposed with the document HWND as it is now, everything is fine.

> WM_GETOBJECT for this HWND returns embed element
This is still fine. However, technically, this is a bit weird because WM_GETOBJECT for this HWND will return an accessible whose HWND is the document HWND. I guess this doesn't really matter that much, but it's worth noting.