Bug 1704206 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

On macOS, native context menus do not respond to synthesized events, such as mousemove, click, or key presses. However, we have many automated tests which use synthesized events to interact with context menus.
In order to make these tests work (bug 1700724), we need to have APIs to do the following:

 1. Activate a menuitem in an open context menu
 2. Activate a menuitem in an open context menu with some key modifiers
 3. Open a submenu of a context menu

Our current tests currently use `EventUtils.synthesizeMouseAtCenter` for all three; opening a submenu is often done via a synthesized mousemove event. Some tests use `menuitem.click()` for 1.

I propose these two new APIs:

 1. `XULPopupElement.activateItem(menuItem, modifiers)` for activating menu items.
 2. `XULMenuElement.openSubmenu()` for opening submenus.

Moreover, if no key modifiers are needed, `menuitem.click()` can still be used.

The intention of these APIs is that they will work on both native and non-native menus.

WebIDL:

```js
dictionary ActivateMenuItemModifiers {
  boolean altKey = false;
  boolean metaKey = false;
  boolean ctrlKey = false;
  boolean shiftKey = false;
};

[ChromeOnly,
 Exposed=Window]
interface XULPopupElement : XULElement
{
  /**
   * Activate the item itemElement. This is the recommended way to "click" a
   * menuitem in automated tests that involve menus.
   * Fires the command event for the item and then closes the menu.
   * Only call this while this popup is open.
   *
   * @param itemElement The activated menuitem.
   * @param modifierKeys Which modifier keys should be set on the command event.
   */
  void activateItem(Element? itemElement,
                    optional ActivateMenuItemModifiers modifierKeys = {});
};

[ChromeOnly,
 Exposed=Window]
interface XULMenuElement : XULElement {
  /**
   * Open this menu's menupopup as a submenu of a currently open menu.
   * Should only be called if this is a <menu> inside an open <menupopup>.
   */
  void openSubmenu();
};
```

For openSubmenu(), alternatively we could also make it a method on XULPopupElement so that it's called as `popup.openSubmenu(menu)`. I'm not sure which one is preferable.

In this bug I'm planning to implement these two APIs and make them work for non-native menus.
In a follow-up bug, I'm going to implement them for native context menus as well.
And in other follow-up bugs, I'm planning to convert our existing tests to the new APIs.

I'm interested in feedback on these APIs. I'm going to go ahead with uploading patches that implement them as outlined above, because anything is better than nothing, and then I can address any non-blocking feedback in follow-ups.
On macOS, native context menus do not respond to synthesized events, such as mousemove, click, or key presses. However, we have many automated tests which use synthesized events to interact with context menus.
In order to make these tests work (bug 1700724), we need to have APIs to do the following:

 1. Activate a menuitem in an open context menu
 2. Activate a menuitem in an open context menu with some key modifiers
 3. Open a submenu of a context menu

Our current tests currently use `EventUtils.synthesizeMouseAtCenter` for all three; opening a submenu is often done via a synthesized mousemove event. Some tests use `menuitem.click()` for 1.

I propose these two new APIs:

 1. `XULPopupElement.activateItem(menuItem, modifiers)` for activating menu items.
 2. `XULMenuElement.openSubmenu()` for opening submenus.

Moreover, if no key modifiers are needed, `menuitem.click()` can still be used.

The intention of these APIs is that they will work on both native and non-native menus.

WebIDL:

```js
dictionary ActivateMenuItemModifiers {
  boolean altKey = false;
  boolean metaKey = false;
  boolean ctrlKey = false;
  boolean shiftKey = false;
};

[ChromeOnly,
 Exposed=Window]
interface XULPopupElement : XULElement
{
  /**
   * Activate the item itemElement. This is the recommended way to "click" a
   * menuitem in automated tests that involve menus.
   * Fires the command event for the item and then closes the menu.
   * Only call this while this popup is open.
   *
   * @param itemElement The activated menuitem.
   * @param modifierKeys Which modifier keys should be set on the command event.
   */
  void activateItem(Element? itemElement,
                    optional ActivateMenuItemModifiers modifierKeys = {});
};

[ChromeOnly,
 Exposed=Window]
interface XULMenuElement : XULElement {
  /**
   * Open this menu's menupopup as a submenu of a currently open menu.
   * Should only be called if this is a <menu> inside an open <menupopup>.
   */
  void openSubmenu();
};
```

For openSubmenu(), alternatively we could also make it a method on XULPopupElement so that it's called as `popup.openSubmenu(menu)`. I'm not sure which one is preferable.

In this bug I'm planning to implement these two APIs and make them work for non-native menus.
In bug 1704209 and bug 1704212, I'm going to implement them for native context menus as well.
And in other follow-up bugs (tracked by bug 1704211), I'm planning to convert our existing tests to the new APIs.

I'm interested in feedback on these APIs. I'm going to go ahead with uploading patches that implement them as outlined above, because anything is better than nothing, and then I can address any non-blocking feedback in follow-ups.
On macOS, native context menus do not respond to synthesized events, such as mousemove, click, or key presses. However, we have many automated tests which use synthesized events to interact with context menus.
In order to make these tests work (bug 1700724), we need to have APIs to do the following:

 1. Activate a menuitem in an open context menu
 2. Activate a menuitem in an open context menu with some key modifiers
 3. Open a submenu of a context menu

Our current tests currently use `EventUtils.synthesizeMouseAtCenter` for all three; opening a submenu is often done via a synthesized mousemove event. Some tests use `menuitem.click()` for 1.

I propose these two new APIs:

 1. `XULPopupElement.activateItem(menuItem, modifiers)` for activating menu items.
 2. `XULMenuElement.openSubmenu()` for opening submenus.

Moreover, if no key modifiers are needed, `menuitem.click()` can still be used for activating items (but not for opening submenus).

The intention of these APIs is that they will work on both native and non-native menus.

WebIDL:

```js
dictionary ActivateMenuItemModifiers {
  boolean altKey = false;
  boolean metaKey = false;
  boolean ctrlKey = false;
  boolean shiftKey = false;
};

[ChromeOnly,
 Exposed=Window]
interface XULPopupElement : XULElement
{
  /**
   * Activate the item itemElement. This is the recommended way to "click" a
   * menuitem in automated tests that involve menus.
   * Fires the command event for the item and then closes the menu.
   * Only call this while this popup is open.
   *
   * @param itemElement The activated menuitem.
   * @param modifierKeys Which modifier keys should be set on the command event.
   */
  void activateItem(Element? itemElement,
                    optional ActivateMenuItemModifiers modifierKeys = {});
};

[ChromeOnly,
 Exposed=Window]
interface XULMenuElement : XULElement {
  /**
   * Open this menu's menupopup as a submenu of a currently open menu.
   * Should only be called if this is a <menu> inside an open <menupopup>.
   */
  void openSubmenu();
};
```

For openSubmenu(), alternatively we could also make it a method on XULPopupElement so that it's called as `popup.openSubmenu(menu)`. I'm not sure which one is preferable.

In this bug I'm planning to implement these two APIs and make them work for non-native menus.
In bug 1704209 and bug 1704212, I'm going to implement them for native context menus as well.
And in other follow-up bugs (tracked by bug 1704211), I'm planning to convert our existing tests to the new APIs.

I'm interested in feedback on these APIs. I'm going to go ahead with uploading patches that implement them as outlined above, because anything is better than nothing, and then I can address any non-blocking feedback in follow-ups.
On macOS, native context menus do not respond to synthesized events, such as mousemove, click, or key presses. However, we have many automated tests which use synthesized events to interact with context menus.
In order to make these tests work (bug 1700724), we need to have APIs to do the following:

 1. Activate a menuitem in an open context menu
 2. Activate a menuitem in an open context menu with some key modifiers
 3. Open a submenu of a context menu

Our current tests currently use `EventUtils.synthesizeMouseAtCenter` for all three; opening a submenu is often done via a synthesized mousemove event. Some tests use `menuitem.click()` for 1.

I propose ~~two~~ one new API~~s~~: (Edited after comment 13)

 1. `XULPopupElement.activateItem(menuItem, modifiers)` for activating menu items.
 2. ~~`XULMenuElement.openSubmenu()` for opening submenus.~~

(Edit:) For opening submenus, we already have `menu.openMenu(true)` which we can make work for native menus as well.

Moreover, if no key modifiers are needed, `menuitem.click()` can still be used for activating items (but not for opening submenus).

The intention of these APIs is that they will work on both native and non-native menus.

WebIDL:

```js
dictionary ActivateMenuItemModifiers {
  boolean altKey = false;
  boolean metaKey = false;
  boolean ctrlKey = false;
  boolean shiftKey = false;
};

[ChromeOnly,
 Exposed=Window]
interface XULPopupElement : XULElement
{
  /**
   * Activate the item itemElement. This is the recommended way to "click" a
   * menuitem in automated tests that involve menus.
   * Fires the command event for the item and then closes the menu.
   * Only call this while this popup is open.
   *
   * @param itemElement The activated menuitem.
   * @param modifierKeys Which modifier keys should be set on the command event.
   */
  void activateItem(Element? itemElement,
                    optional ActivateMenuItemModifiers modifierKeys = {});
};

[ChromeOnly,
 Exposed=Window]
interface XULMenuElement : XULElement {
  /**
   * Open this menu's menupopup as a submenu of a currently open menu.
   * Should only be called if this is a <menu> inside an open <menupopup>.
   */
  void openSubmenu();
};
```

~~For openSubmenu(), alternatively we could also make it a method on XULPopupElement so that it's called as `popup.openSubmenu(menu)`. I'm not sure which one is preferable.~~

In this bug I'm planning to implement these two APIs and make them work for non-native menus.
In bug 1704209 and bug 1704212, I'm going to implement them for native context menus as well.
And in other follow-up bugs (tracked by bug 1704211), I'm planning to convert our existing tests to the new APIs.

I'm interested in feedback on these APIs. I'm going to go ahead with uploading patches that implement them as outlined above, because anything is better than nothing, and then I can address any non-blocking feedback in follow-ups.

Back to Bug 1704206 Comment 0