1392568 - Dispatch node in contextMenus.onClicked

Status: RESOLVED DUPLICATE of bug 1325814

(WebExtensions :: Untriaged, enhancement)

Description

[YF (Yang)]

This is a feature request, I hope it send the element to facilitate the development, which is available through sophisticated approachs. This is an actual functional needs, and it is complicated to get the object.

It should be dispatched only if have a host permission of the tab.


https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextMenus/onClicked 
https://hg.mozilla.org/mozilla-central/annotate/a9d372645a32b8d23d44244f351639af9d73b96a/browser/components/extensions/ext-c-menus.js#l165 
https://hg.mozilla.org/mozilla-central/annotate/a9d372645a32b8d23d44244f351639af9d73b96a/browser/components/extensions/schemas/menus.json#l380 

https://stackoverflow.com/questions/7703697/how-to-retrieve-the-element-where-a-contextmenu-has-been-executed
https://stackoverflow.com/questions/44436954/get-node-on-which-context-menu-was-open-in-chrome-extension 
https://bugs.chromium.org/p/chromium/issues/detail?id=39507  context menu API needs to provide a way to get at the actual DOM node

Comment 1

[Andrew Swan [:aswan]]

If you're asking for the same thing as the chromium bug you cited, this isn't feasible.  Background scripts (where an onClicked handler can run) and content pages run in different processes (and in different security contexts).
If you're actually asking for something else, please clarify the request?

Comment 2

[YF (Yang)]

I hope it dispatches an object information in callback of onClicked, maybe cloneInfo() of document.activeElement. Then the background script can send message to content script to manipulates the element with the information.

Comment 3

[u287251]

Specifically, what information do you need which is not available in the contextMenus.OnClickData[1] object?

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextMenus/OnClickData#Type

Comment 4

[YF (Yang)]

Get the context menus was open in which element, use the context menus to insert text to the element.

Comment 5

[Andrew Swan [:aswan]]

This is not practical for the reasons described in comment 1

Comment 6

[YF (Yang)]

<del>Why, only clone element information does not involve the element itself.</del>

Well, I think I understand, so the context menu is also generated in chrome instead of the content context, not being involved for the content context.

Comment 7

[u287251]

I don't see how this can work given all of this is asynchronous and cross-process -- the background process can't have a handle to a node which exist in a content process.

Cloning the node into background process-side is not going to accomplish anything more than say using a xpath as reference. It seems what you are asking is a whole infrastructure to be added so that background process can manipulate a DOM node in a content process, all of this in a transparent way -- in short going backward to old ways API-wise with all the bad consequences.

I (roughly) suggest an approach which does not involve any API change (regression).

- Content script-side: detect "mousedown" events (optionally narrow to right-click events):
    - Store node locally somehow, let's call this "content script data registers".
    - Send message to background page of extension that a node was clicked, along with whatever information you may required in order to act on the node later.
- Background process-side: receive message from content process about a node being clicked:
    - Store all information needed to be able later to tell the content script to act on whatever node was clicked -- let's call this "background process data registers":
         - Whatever information about the node passed by content script
         - Tab id
         - Frame id

- Background process-side: contextmenus.OnClicked event handler called
    - Take the event handler being triggered as a mere signal to act upon the information currently sitting in the background process data registers.
    - Send text to be inserted through a message at the tab id/frame id registers.
    - Clear background process data registers.
- Content process-side: receives message about text to-be-inserted in currently locally stored node.
    - Insert text.
    - Clear content script data registers.

The only thing I see would help here is that the content script would be given a way to detect when the context menu is *about to be opened* for a specific node -- currently need to rely on "mousedown" event.

Comment 8

[YF (Yang)]

(In reply to R. Hill from comment #7)
> I don't see how this can work given all of this is asynchronous and
> cross-process -- the background process can't have a handle to a node which
> exist in a content process.
> 
> Cloning the node into background process-side is not going to accomplish
> anything more than say using a xpath as reference. It seems what you are
> asking is a whole infrastructure to be added so that background process can
> manipulate a DOM node in a content process, all of this in a transparent way
> -- in short going backward to old ways API-wise with all the bad
> consequences.

I think getting an unreliable element reference is acceptable for me, I assume and accept the page content is generally not changed when the context menu is open.

I tried some ways but have not yet succeeded and I will continue to try.

Comment 10

[YF (Yang)]

I just figured out the problem for me, I actually did not need to handle elements in background script, just send message (like clearing active input), storing and handling elements within content script is good, although it may have a little uncertainty due to the asynchronous.