Detecting type of DOM element under mouse

[cybersight]

I want to create custom menus that function similar to context menus, but are opened via modifier keys rather than right click. The problem is that CEF currently provides no way to query the type of the current DOM element under mouse from the browser process, so there's no way to customize the menus accordingly, nor get information necessary for actions like "Open link in new tab...".

I see three solutions:

1. When the user hits a modifier key, simulate a right click event in order to get information about the DOM element under mouse from a ContextMenuParams object, then suppress the context menu and show a custom menu instead. This has the side effect of stealing focus which would then need to be reset after, but seems like the only thing that could possibly work without setting up custom IPC between the browser and renderer processes.

2. Use JavaScript to set up an event listener for mouseover events, and inside the listener callback, push information about the DOM element to the renderer process, which then gets forwarded to the browser process. Similar to what already happens in the sample project with FocusNodeChanged event. This would have the advantage of the element type being known before the user hits the menu, so there's no delay in determining what menu actions to generate. However, there doesn't seem to be a way to send information from a JavaScript callback to the renderer process directly, so this might not even be possible.

3. Set up an event listener like in 2, but instead of pushing events to the browser process, set some global variable in JavaScript that represents the current element under mouse. Then when a user hits a modifier key, use a CefV8Context in the renderer process to query the global variable to find out its type and any other information needed for the custom menus, then send it to the browser process via IPC.

Are there any better methods, or better ways to execute these methods? I'm not keen on 1 since it's too much like sonar and would interfere with text input. 2 could be ideal but would probably require invasive changes to CEF and even Chromium to work correctly. 3 seems the most viable for now.

[ndesktop]

DOM is probably available only on renderer process. You can use OnFocusedNodeChanged to send a message to your browser process to keep track of the browser, frame and DOM node + whatever attributes you might find necessary from the renderer process.

[cybersight]

DOM is probably available only on renderer process. You can use OnFocusedNodeChanged to send a message to your browser process to keep track of the browser, frame and DOM node + whatever attributes you might find necessary from the renderer process.

OnFocusedNodeChanged only gets called for keyboard focus, though, so it doesn't tell me when say a link or an image is being hovered over. And the only way for them to receive keyboard focus is if the user clicks on it, whereas I want my menus to be driven entirely by key presses.

What I really need is an OnMouseFocusedNodeChanged or OnMouseOver or OnHover callback which would function the same way as "onmouseover" event listeners in JavaScript.

[magreenblatt]

I would suggest implementing the menus completely in JavaScript.

[KatrinaS]

What you want to do can be accomplished completely in JavaScript, querying the DOM provides no further information about an Element that Script can't already provide, all of this other stuff is unnecessary / just reinventing the wheel

[cybersight]

I would suggest implementing the menus completely in JavaScript.

No, these are custom controls that I need total ownership of. And definitely don't want to be beholden to the laws of HTML and JavaScript.

There's also the issue of menu actions that couldn't be executed in JavaScript since they pertain to the application, not a particular web page.

[cybersight]

No, these are custom controls that I need total ownership of. And definitely don't want to be beholden to the laws of HTML and JavaScript.

To clarify, they're highly non-standard controls that chaff against a lot of assumptions made by HTML and JavaScript. Assumptions like DOM elements only receiving keyboard focus when you click or tab onto them. And shift only ever being used for text input, when I also need to use it to open menus.

I have tried just using JavaScript in a regular browser and the result was deeply unsatisfying. Doing it with CEF provides more control and might get it to 90% correct, but that still isn't good enough. And definitely not if it adds both a language and process barrier between selecting and executing menu actions.

[ndesktop]

Then perhaps a mix between JS for event detection and forwarding of custom messages to browser? There is always the possibility of patching CEF/Chromium, but I suppose you are not very fond of this way.

[KatrinaS]

Like the person above says, all of this can be accomplished with JavaScript and plus some sort of Handler,, nothing you mention is insurmountable

[cybersight]

Then perhaps a mix between JS for event detection and forwarding of custom messages to browser? There is always the possibility of patching CEF/Chromium, but I suppose you are not very fond of this way.

How do you forward events from JavaScript to the browser process?

I see multiple ways of making calls to JavaScript from the browser and renderer processes, but not the other way around.