Edge Browser: Replace BrowserInformationControl dosn't work on hover

[amartya4256]

Describe the bug
When using Edge Browser as the default browser, the BrowserInformationControl for the JavaDoc hover tooltip doesn't replace with navihation buttons on hovering.

To Reproduce

• Use Edge browser as the default browser.
• Hover over a piece of code to open a javadoc tooltip.
• Hover over the tooltip.
• The navigation buttons won't appear and it wont be possible to navigate if you click on a link.
• The BrowserInformationControl is only replace if you hover to the bottom of the tooltip where the ends in the bottom. It is triggered by the styledText in the bottom and not the browser.

Expected behavior
The BrowserInformationControl should be replaced with the ones with navigation buttons with any action on the tooltip.

Note: With WebView2, it doesn't seem possible to capture hover events and one possible proposal could be to trigger this event on Mouse Click and other Mouse Events which can be captured.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc)

3. JRE/JDK version

Version since
Eclipse or SWT version since when the behavior is seen [e.g. 4.23]

Workaround (or) Additional context
Add any other context about the problem here.
Any known workarounds for the problem?

[fedejeanne]

I added this issue to the roadmap.

@amartya4256 please provide a screenshot to better understand the issue.

[sratz]

I looked into mouse events in general.

WebView2 does not offer any native API for this.

However, it should be possible to use a BrowserFunction or a host object + some mouse event listeners on the DOM to react on those.

I got a PoC partially(*) working locally which I need to clean up and will submit a draft PR when I find some time.

[HeikoKlare]

However, it should be possible to use a BrowserFunction or a host object + some mouse event listeners on the DOM to react on those.

I got a PoC partially(*) working locally which I need to clean up and will submit a draft PR when I find some time.

That sounds great! So if I understand correctly, that would render #1499 with eclipse-platform/eclipse.platform.ui#2408 obsolete, as it will allow to restore the "original" hovering behavior, won't it? Do think we should thus hold those back those PRs and wait for your draft PR, @sratz?

[merks]

Just a random thought: I also wondered if org.eclipse.swt.widgets.Display.addFilter(int, Listener) might help see events one might not otherwise see...

[HeikoKlare]

Just a random thought: I also wondered if org.eclipse.swt.widgets.Display.addFilter(int, Listener) might help see events one might not otherwise see...

As far as I understood the analysis results, once the cursor is on top of the (embedded) WebView component, no mouse events will reach the Eclipse/SWT process (and thus the Display class) anymore. They are already processed by the WebView process. That why this PR proposes, as a first step, to notify about focus events (implicitly triggered by clicking into the WebView component) and Sebastian's proposal would capture the mouse events within the WebView process and explicitly pass them to the Eclipse/SWT process via callback.

[merks]

Yes, if the embedded view can do the proper work, that would ideal and better. I just randomly wondered if say via a timer event one could trigger determining the location of the mouse position to know it is over the area of the display in which the browser component exists and could determine when hovering is occurring because the mouse point remains in that area without moving. Anyway, it's just a random thought...