1914785 - The mousemove event's clientX and clientY values are sporadically invalid in an Iframe after overflow happens

Status: UNCONFIRMED

(Core :: DOM: Events, defect)

Description

[hecvid97]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

• Create and Iframe which is movable using the mousedown and mousemove events.
• Cause overflow in the created iframe (scroll bars must appear / become active)
• Move the iframe, and at / above a certain movement speed, the window will "jitter"

For an easy example, just open any page, e.g.: google, and paste the following code into the web console, creating an iframe. For the issue to appear, the textbox's size has to be increased to cause overflow, and after that, drag the iframe (anywhere except the textarea)
The example provides logging in the console, writing warning when it detects a movement direction change, which should not happen in the middle of moving the mouse diagonally (but it does)
https://pastebin.com/mrQDDhEs

(This issue does not appear in Chrome for example, so I assume it is not due to any web standard regarding event handling)

The issue was tested on two separate machines, with different Windows, Firefox and mouse
Machines:

• OS: Win10
  Firefox version: 129.0.2 (64-bit)
  Mouse: wired Logitech G402
• OS: Win11
  Firefox version: 128.1.0esr (64-bit)
  Mouse: wireless Logitech M185

Actual results:

After causing the overflow, the mousemove's event.clientX and event.clientY sporadically start to report wrong values, which is even visible as the window is "jittering".

Details:

• The jittering only seems to happen when moving upwards (negative Y), but when it happens, it affects both event.clientX and event.clientY
• The fault is sporadic, and it only seems to happen at or above certain speeds of movement
• The visibility of this bug reduces the faster the computer is. On slower machines, it is very visible by eye, sometimes mistakenly moving the full length of the iframe, and with luck, it is possible to stop as the iframe moves out from under the cursor (it moves back on the next mousemove event), on faster machines it is hard to see, likely due to the movement in a single event having to hit a certain threshold, which is harder if the events fire more rapidly
• Changing the overflow to clip in different places with different content can cause the issue to happen when moving down instead of up, and in certain cases it can go away completely, but I did not find an obvious rule, so it's best to test all diagonal movements for reproduction
• Does happen when overflow of the content is set to scroll, but still only after actual overflow happens (meaning that it's not about the scrollbar's appearance)

Expected results:

The iframe is moved exactly along the mouse's real path, so if the mouse is moved strictly in one direction, the window does not "jump back" at any point

Comment 1

[hecvid97]

Attachment: Same as the linked example, it is supposed to be pasted into the web console on any page