Is requestAnimationFrame called at the right point?

[jakearchibald]

I'm repurposing this slightly.

Currently the spec says that requestAnimationFrame callbacks should come before the very next render, unless requestAnimationFrame is called after the browser has started processing the raf callback queue, in which case the callbacks happen before the following render.

Chrome & Firefox do this, but Edge and Safari don't. They run requestAnimationFrame callbacks before the following render.

test.style.transform = 'translate(0, 0)';

document.querySelector('button').addEventListener('click', () => {
  const test = document.querySelector('.test');
  test.style.transform = 'translate(400px, 0)';
  
  requestAnimationFrame(() => {
    test.style.transition = 'transform 3s linear';
    test.style.transform = 'translate(200px, 0)';
  });
});

In Edge and Safari, the box will move to the left. In Chrome and Firefox (spec compliant) it'll move to the right. Demo.

Developers are pretty confused about this, with currently 60% expecting the Edge/Safari behaviour.

Should we do something about this?

Here's the original issue text:

---

It's currently impossible to request a callback for the next animation frame.

requestAnimationFrame(cb) will call cb before the next visual update in most cases, unless it's called during "run the animation frame callbacks", in which case it'll be called after the next visual update.

Sometimes you want to wait until after a natural layout/render to perform particular steps, to avoid a synchronous layout.

function requestNextAnimationFrame(cb) {
  requestAnimationFrame(() => requestAnimationFrame(cb));
}

The above guarantees cb will be called after a natural layout/render, but if called during "run the animation frame callbacks" you end up waiting an additional frame.

Another way to solve this problem would be to provide insight into the current position within the event loop, so a user-land implementation of requestNextAnimationFrame could avoid calling raf twice if it's already in that phase of the loop.

[domenic]

This seems vaguely related to the discussion in #512 (which got off topic pretty quickly)

[jakearchibald]

It seems like both Edge & Safari treat requestAnimationFrame as "next frame" already (box moves to the left). https://safari-raf-bug.glitch.me/

Replies to https://twitter.com/jaffathecake/status/912601447442927617 suggest developers are very confused about this.

Feels like we should do something to make this kind of scheduling more explicit, but I'm not sure how, yet.

[jakearchibald]

If the use cases of requestAnimationFrame are:

• Let me debounce things that happen multiple times a frame.
• Sync me to the refresh rate of the screen.

…then the spec makes the most sense, and Safari and Edge are needlessly delaying the callbacks. I guess I'll file bugs with them and see if they disagree.

[wanderview]

Is this covered by any existing WPT cases?

[jakearchibald]

This takes me back to thinking we need something like requestAfterAnimationFrame, which lands after paint. This is the point you'd do all your style/layout-dependent reading, and you'd do all your style/layout writing in requestAnimationFrame.

[jakearchibald]

@wanderview I can't find one at a glance

[wanderview]

This takes me back to thinking we need something like requestAfterAnimationFrame, which lands after paint.

Or maybe, requestAnimationFrame(cb, { mode: 'after-frame' }). We could have before-frame, after-frame, and the current default of surprise-me.

[annevk]

@smaug---- also occasionally asks for an "after animation frame callback".

@rocallahan and @heycam might recall some of the original motivation for the timing used by the specification.

[jakearchibald]

@wanderview that works, although it might encourage GC? I think that's why raf uses a callback rather than a promise.

[rocallahan]

requestAnimationFrame was created before promises existed.

[rocallahan]

The current spec and Firefox/Chrome behavior let you use requestAnimationFrame to batch work to happen before the next render. That seems useful. I guess I'm agreeing with #2569 (comment).

[rocallahan]

I'm pretty sure that was the original motivation, though I can't be sure.

[jakearchibald]

I filed https://bugs.webkit.org/show_bug.cgi?id=177484 for Safari, and https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/15469349/ for Edge.

[smaug----]

Yeah, the current behavior feels reasonable. I'm very surprised people think that is confusing.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28644 is separate thing. Quite often one wants to do something right after rendering. Something which isn't possibly about rendering but something else.

[annevk]

@rniwa could you maybe add Apple's rationale for doing this after the frame rather than before? Or include the relevant folks who can.

cc @mstange

[rniwa]

cc @smfr @hober

[smfr]

I think WebKit's behavior falls out of our "it's like a timer" thinking. In fact, we fall back to a timer in the implementation in some cases. I agree that the Safari behavior seems wrong in the case where you really want to have changes show up before the up-coming paint.

[jakearchibald]

requestAnimationFrame's timing as specced is really useful for debouncing things like mousemove, where you only need to update once per frame, but waiting an additional frame introduces visual lag.

[jakearchibald]

I believe WebKit is switching to match other browsers here.

[nullhook]

This issue still persists on Safari.

[smfr]

This issue still persists on Safari.

Please clarify, with Safari version, more details and a testcase filed at bugs.webkit.org

[07akioni]

@smfr

Safari Version 14.0.3 (16610.4.3.1.7)
Mac OS Big Sur11.2.3 (20D91)

https://safari-raf-bug.glitch.me/

Chrome: left to right
Safari: right to left

[smfr]

Thanks for the testcase; I filed https://bugs.webkit.org/show_bug.cgi?id=225871. It's not clear to me that this is about rAF timing; it may be a style resolve or animation bug.

[jakearchibald]

@smfr I wondered if this was related to "click" timing. It isn't, but I noticed another bug at the same time https://bugs.webkit.org/show_bug.cgi?id=225866

[LiChangyi]

Mac OS Big Sur 11.4
chrome 92.0.4515.131(x86_64) right to left.

[moriwang]

Hi there, I made a test but I can't explain it.

• macOS 11.4
• Chrome 94.0.4606.61
• Safari 14.1.1

Right to left on both chrome and safari.

document.querySelector('button').addEventListener('click', () => {
  const test = document.querySelector('.test')
  test.style.transform = 'translate(400px, 0)'

  requestAnimationFrame(() => {
    test.style.transition = 'transform 3s linear'
    test.style.transform = 'translate(200px, 0)'
  })
})

Left to right on both chrome and safari.

document.querySelector('button').addEventListener('click', () => {
  const test = document.querySelector('.test')
  test.style.transform = 'translate(400px, 0)'
  test.style.transition = 'transform 3s linear'

  requestAnimationFrame(() => {
    test.style.transform = 'translate(200px, 0)'
  })
})

Why does the position of test.style.transition matter?

[smfr]

Live test: https://codepen.io/smfr/pen/jOwedOW

document.querySelector('button').addEventListener('click', () => {
  const test = document.querySelector('.test')
  test.style.transform = 'translate(400px, 0)'

  requestAnimationFrame(() => {
    test.style.transition = 'transform 3s linear'
    test.style.transform = 'translate(200px, 0)'
  })
}

On click, the translate is set to 400px, instantaneously. On the next rAF, the 200px translate and transition make it animate from 400px to 200px.

document.querySelector('button').addEventListener('click', () => {
  const test = document.querySelector('.test')
  test.style.transform = 'translate(400px, 0)'
  test.style.transition = 'transform 3s linear'

  requestAnimationFrame(() => {
    test.style.transform = 'translate(200px, 0)'
  })
})

On click, the 400px translate and transition make it animate from 0 to 400px. In the rAF callback the target is now set to 200px, so the transition retargets to 200px.

[aquaductape]

Goes left to right on Firefox 111.0 (64-bit), Mac 13.2.1 https://safari-raf-bug.glitch.me/. It's odd, cuz sometimes it goes right to left on first time page load then is consistently is left to right even after refreshing page/clearing cache, I can't reproduce it.

[aquaductape]

Still goes left to right on Firefox 124.0 (64-bit), Mac 14.4

[Zhang-Junzhi]

I tested it on Linux with Chrome 131, and the element moves from right to left, not from left to right as @jakearchibald mentioned.