1627812 - Rework context menu code to work with headless widgets

Status: NEW

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

Description

[Morgan Reschenberg [:morgan]]

Right now, it is not possible to launch a context menu via our mochitest framework.
The context menu code in mozAccessible::accessibilityPerformAction should be updated to either:
(a) launch our context menu via mouse events in the gecko layer or
(b) use headless widgets/handle when we can't get a widget from our existing widget call

if we can re-work this code, we'd then listen for a reorder event to tell when our context menu appears (I think?)

NI'ing eeejay for more info, and marco mentioned we might wanna NI jamie here also? gonna leave that up to you.

Comment 1

[Eitan Isaacson [:eeejay]]

We can either wait for the EVENT_MENUPOPUP_START gecko event, or the AXMenuOpened mac event.

a reorder event won't happen because context menus don't cause a tree mutation in the doc (or in the chrome, since they are just toggled as visible and we listen for an obscure XUL dom event in RootAccessible).

Jamie, originally I suggested to Morgan that we implement a "Show menu" action in our platform code because I didn't want to mess with the brittle MSAA legacy actions we support in nsIAccessible. Marco mentioned there may be interest in having a context menu action in Windows too?

Comment 2

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #1)

Jamie, originally I suggested to Morgan that we implement a "Show menu" action in our platform code because I didn't want to mess with the brittle MSAA legacy actions we support in nsIAccessible. Marco mentioned there may be interest in having a context menu action in Windows too?

The problem with actions on Windows (and I'd argue with our current action API across the board) is that there's no differentiation between primary and secondary actions. So, we have to assume that action 0 is primary. Even in the absence of a primary action (e.g. click, press), I'd argue that "show context menu" should not be treated as the primary action. To put this in terms of a user scenario, a user won't expect pressing enter on something (even if it isn't clickable) to open the browser context menu.

In short, I think there's definitely a theoretical benefit to having context menu actions on all platforms, but we'd need to find some way to deal with this primary/secondary action problem. On Windows, there's no current practical benefit because screen readers, not having such an API for years, just route the mouse and right click.

Comment 3

[James Teh [:Jamie]]

As a side note, I notice that Windows Narrator has a "perform secondary action" command, but I can't find any UI Automation API which actually supports this. So that's fun.