Edge: Implement mouse-related event listener support

[sratz]

• MouseListener

  • up
  • down
  • doubleClick

• MouseMoveListener

  • move

• MouseTrackListener

  • exit
  • enter

• MouseWheelListener

  • scroll

• DragDetectListener

  • dragDetected

The implementation is JavaScript-based by attaching listeners to the DOM for all relevant events and forwarding them to the WebView via window.chrome.webview.postMessage().

The event handling is analogous to IE's IE#handleDOMEvent(org.eclipse.swt.ole.win32.OleEvent).

This obsoletes and removes the workaround implemented in #1551.

[github-actions[bot]]

Test Results

  118 files  ±0    118 suites  ±0   10m 18s ⏱️ + 1m 6s 4 432 tests ±0  4 412 ✅ +1  17 💤 ±0  3 ❌  - 1    298 runs  ±0    291 ✅ +1   4 💤 ±0  3 ❌  - 1 

For more details on these failures, see this check.

Results for commit ae05ca9d. ± Comparison against base commit 7d4190a2.

:recycle: This comment has been updated with latest results.

[HeikoKlare]

May this fix ...?

• https://github.com/eclipse-platform/eclipse.platform.swt/issues/2072

[sratz]

May this fix ...?

• [Regression] Can't click on JavaDoc popup, resize or scroll #2072

Not sure.

I just remember that we've been down this road before.

The problem is that if we disable JavaScript via ICoreWebView2Settings.put_IsScriptEnabled(boolean), this will also prevent those listeners from running :(

[akurtakov]

Is this still being considered?

[HeikoKlare]

Is this still being considered?

Yes, we still have https://github.com/eclipse-platform/eclipse.platform.swt/issues/2164 and just had an offline talk about how we want to proceed with this a few weeks ago. I expect that we proceed with this or have something else supercede it in the next weeks.

[sratz]

Is this still being considered?

Yes, we still have #2164 and just had an offline talk about how we want to proceed with this a few weeks ago. I expect that we proceed with this or have something else supercede it in the next weeks.

As discussed offline, I changed the implementation to keep the fallback in place

• before first page load (where we don't have any javascript yet)
• when javascript is disabled

[sratz]

This should be ready to go now.

[sratz]

@HeikoKlare Should we get this into M1?

[sratz]

I tested the code out. Functionality-wise the code uses the new handler when javascript is enabled to capture cursor movements.

Thanks for testing and reviewing!

Although, I think the needsMouseMovementFallback being assigned in the method handleNavigationCompleted is a bit iffy. I am just being nitpicky here. I approve this PR.

I fully agree. I was also struggling and refactoring this part over several iterations - and it always felt off. Even when refactoring it into a helper method, the place where this condition effectively must change is still in handleNavigationCompleted, as there the jsEnabledFlag is toggled. So I thought it's at least consistent to have 2 flags and not 1 flag + 1 helper method (which uses the first flag as well).

[sratz]

I've given it some more thought and I think the flag atLeastOneTopNavigationCompleted isn't that bad actually. It expresses better why we need the fallback handling.

[amartya4256]

I've given it some more thought and I think the flag atLeastOneTopNavigationCompleted isn't that bad actually. It expresses better why we need the fallback handling.

Yes, I think it is very descriptive. Let's go with it.

[sratz]

Test failures on Windows are unrelated.