Fix MOUSE_MOVE firing outside the canvas in Firefox

[eclctc]

Fixes #12373.

If you set a MOUSE_MOVE action, the events behave differently in Firefox vs Chrome. In Chrome they stop once the cursor leaves the canvas, but in Firefox they keep coming with coordinates outside the canvas (sometimes negative).

I dug into it and the two browsers end up on different code paths. Chrome uses Pointer Events with pointermove on the canvas, so moving off-canvas just stops firing (and drags keep going thanks to pointer capture). Firefox has Pointer Events turned off (#6372), so it falls back to the old mouse path where mousemove is attached to the document. That's on purpose so drags still work when you go past the canvas edge — but the side effect is plain hover moves outside the canvas were firing too.

The fix is in handleMouseMove: if no mouse button is down, ignore moves that land outside the element bounds, which lines up with how the Pointer Event path already behaves. Drags (button held) still fire off-canvas so the camera controls aren't affected. Nothing changes for Chrome, and the bounds check only runs on hover so it's not in the way during a drag.

Testing:

• Added specs in ScreenSpaceEventHandlerSpec.js for the off-canvas hover being ignored, drags still firing off-canvas, and the previous position not getting clobbered when a hover move is skipped.
• eslint is clean and the existing mouse move specs still pass.

Checklist:

• I have submitted a Contributor License Agreement.
• I have added my name to CONTRIBUTORS.md.
• I have updated CHANGES.md with a short description of my change.

[github-actions]

Thank you for the pull request, @eclctc! Welcome to the Cesium community!

In order for us to review your PR, please complete the following steps:

• Send in a Contributor License Agreement (CLA)
• Add yourself to the contributors file

Review Pull Request Guidelines to make sure your PR gets accepted quickly.

[ggetz]

I can confirm @eclctc has completed a CLA!

[javagl]

I did a first review/test pass.

---

Aside: I first thought that the inclusive check of
position.y <= rect.height
was wrong, and that it should be
position.y < rect.height
but it looks like the inclusive check is correct.
(All UI environments that I've (actively) been working with did define "inside" as "min<=value<max", so that was a bit surprising)

---

More importantly:

This does not seem to fully resolve the issue - or at least, not all "flavors" of this issue: When you move the mouse cursor over the timeline (at the bottom of the viewer), then the behavior is still different: Chrome does not fire events there. But FireFox still does fire events there, even with this fix.

This is not entirely surprising when looking at the code: The event position is still contained in the main viewer. The fact that there is that "timeline widget" that is "on top of" the main viewer window is not anticipated there.

In order to fix this, the check will probably have to include some check for another event... property. (Maybe the currentTarget or originalTarget or explicitOriginalTarget or the srcElement ...how many elements is such an event carrying along...?). I haven't investigated which one, but maybe you can figure it out.

[eclctc]

Sounds good! I'll have a look and circle back when once I've investigated. Thanks for letting me know :)