requestAnimationFrame callback order is nondeterministic

[gaearon]

Description

In my experience, the order of rAF callbacks is always deterministic on web. It seems like it's deterministic per spec. In other words, this:

requestAnimationFrame(() => {
  console.log('1')
})

requestAnimationFrame(() => {
  console.log('2')
})

requestAnimationFrame(() => {
  console.log('3')
})

should produce

1
2
3

That is the case on the web, but it's not in React Native.

Instead, on React Native, it's seemingly non-deterministic

Steps to reproduce

See this snack: https://snack.expo.dev/PsXPlo457DmfjCIEzRIsp?platform=ios

Expected:

1,2,3

Actual:

I believe this is the case for:

• Both platforms on 0.74.*
• Seemingly, only for Android on 0.76.* (maybe due to New Architecture being a default?)

React Native Version

0.76.0

Affected Platforms

Runtime - Android, Runtime - iOS

Output of npx react-native info

System:
  OS: macOS 14.6.1
  CPU: (16) arm64 Apple M3 Max
  Memory: 60.87 GB / 128.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.8.0
    path: /opt/homebrew/bin/node
  Yarn:
    version: 1.22.22
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.8.2
    path: /opt/homebrew/bin/npm
  Watchman:
    version: 2024.09.09.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.5
      - iOS 17.5
      - macOS 14.5
      - tvOS 17.5
      - visionOS 1.2
      - watchOS 10.5
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2412.12266719
  Xcode:
    version: 15.4/15F31d
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.12
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.74.1
    wanted: 0.74.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

Stacktrace or Logs

N/A

Reproducer

https://snack.expo.dev/vZ6_gSpj6iB6z0tpgDnsw?platform=android

Screenshots and Videos

No response

[react-native-bot]

Tip

Newer version available: You are on a supported minor version, but it looks like there's a newer patch available - 0.76.3. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.

[react-native-bot]

Tip

Newer version available: You are on a supported minor version, but it looks like there's a newer patch available - undefined. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.

[gaearon]

The issue is present on the newest version. The problem is that the GitHub issue template forces me to output the result of running npx react-native info which is local but the reproducing case I'm using (an Expo Snack) is running 0.76.

[gaearon]

cc @rubennorte @sammy-SC i believe you both worked in this area, is this a known issue? breaking this expectation can lead to very subtle mistakes in app code (in our case, this led to a lightbox being permanently stuck and requiring an app restart.)

[rubennorte]

Thanks for reporting this, @gaearon!

Honestly, we need to rewrite the entire implementation for requestAnimationFrame because, apart from the problems you mentioned, it doesn't provide semantics that resemble anything on Web. They're basically glorified timers.

I don't know why the order isn't respected, but if this is happening for requestAnimationFrame then it's also happening for setTimeout, where the order should also be preserved. This is definitely a bug.

I'll add it to our backlog to prioritize it. If you'd like to contribute a fix in the meantime, please feel free to submit a PR :)

Edit: it looks like the problem is that we only sort by time, but not also by timer ID in both platforms (see Android and iOS).