Open Bug 1772257 Opened 4 years ago Updated 1 year ago

When dragging a card with the mouse, it does not follow the mouse smoothly.

Categories

(Core :: CSS Transitions and Animations, defect, P3)

Desktop
Windows 10
defect

Tracking

()

Tracking Status
firefox103 --- affected

People

(Reporter: alice0775, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: nightly-community, parity-chrome)

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #1772176 +++

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

Steps to reproduce:

  1. Open https://conorpo.github.io/
  2. Drag a card

Actual results:
When dragging a card with the mouse, it does not follow the mouse smoothly.

Expected results:
Dragging a card should move smoothly.
Chrome works as expected.

FWIW,
Firefox 91ESR is also affected.
However, if WebRender is disabled, i.e. Direct3D 11 Compositing, it will move smoothly.

Attached file about:support

This looks like the same underlying problem as bug 1769938, transition + MouseEvent. When I removed all the transitions in the Style Editor, tracking seems just fine.

Noticed a something that caused it was updating the position too often, in your bug every time the mouse moves the position is updated and transition is restarted, which causes the issue to be really bad. In my case I only update every update funciton (about every 20ms) which helps out the smoothness, not sure why it wasnt working for reporter since I am using same firefox version.

Did some testing and using requestAnimationFrame to update element position almost completely negates the issue, especially when a delta check is added to manually throttle FPS. Main source of issue seems to be when the position is updated multiple times between animation frames.

See Also: → 1769938
Component: DOM: Copy & Paste and Drag & Drop → CSS Transitions and Animations

One more thing that could be useful, even when there is no delta time check (as in transform is updated every animation frame). Chaning the transition formula to ease-out almost completely fixes the problem for me.

Okay, what I am assuming that the card has a transform transition when it's dragged, right?

In our implementation, while transform animations are running on the compositor, when mouse is moved, we do flush the animations on the main-thread in order to work hit testing correctly. IIRC chrome doesn't do that stuff.

Severity: -- → S3
Priority: -- → P3
See Also: → 1930907
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: