ContextMenuCloseWatcher

[Zhang-Junzhi]

Problem

Due to the fact that the closing operation of the context menu may differ from ordinary close requests (for example, in the Linux Chrome browser, a pointerdown event outside of the context menu can trigger the context menu to close, while ordinary close events are triggered by click events). Therefore, using CloseWatcher class to simulate the context menu would result in the simulated context menu's closing conditions being inconsistent with those of the standard context menu. Such user experience is not ideal.

The absence of information regarding "whether the focus should return to the target element" is also one of the reasons why CloseWatcher is insufficient(See details below).

Solution

Therefore, I propose the addition of a ContextMenuCloseWatcher class, which is similar to CloseWatcher. Below is a simple code demonstration:

<menu id="ctxmenu" role="menu" tabindex="-1">...</menu>

ele.addEventListener("contextmenu", evt =>
{
    evt.preventDefault()

    let watcher = new ContextMenuCloseWatcher()
    watcher.onclose = shouldReturnFocus =>
    {
        //Close ctxmenu
        //...

        shouldReturnFocus && ele.focus()
    }

    //Show ctxmenu
    //...

    ctxmenu.focus()
})

ContextMenuCloseWatcher also differs from CloseWatcher in one aspect:

There is no parameter for the close event callback of CloseWatcher, while there is one parameter for that of ContextMenuCloseWatcher: shouldReturnFocus. If the closing of the context menu is usually accompanied by a change of focus in the document (for example, if the mouse clicks elsewhere), then shouldReturnFocus is false; if the change implies that the focus should be returned to the very target element of the context menu (for example, the user presses ESC), then shouldReturnFocus is true.

The behavior of creating ContextMenuCloseWatcher on platforms that do not support context menus is left for further discussion.

[smaug----]

FWIW, All the event handler callbacks have a parameter, the event object. (Well, error and beforeunload event handlers may have a bit more complicated parameters, but that setup is a legacy thing and shouldn't be used in new APIs)