-
Notifications
You must be signed in to change notification settings - Fork 24.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Regression 0.62.2] requestIdleCallback is never called on iOS #28602
Comments
RN 0.62.2 [broke requestIdleCallback](facebook/react-native#28602). refs: MBL-14307 affects: student, teacher release note: none Test plan: * Viewing discussion details should automatically mark replies as read
RN 0.62.2 [broke requestIdleCallback](facebook/react-native#28602). refs: MBL-14307 affects: student, teacher release note: none Test plan: * Viewing discussion details should automatically mark replies as read
I can confirm that I'm running into this issue as well, thinking it was a |
If anyone runs into the issue, you can just polyfill it with something like this for now: window.requestIdleCallback =
function(cb) {
var start = Date.now();
return setTimeout(function() {
cb({
didTimeout: false,
timeRemaining: function() {
return Math.max(0, 50 - (Date.now() - start));
},
});
}, 1);
}; Taken from https://github.com/pladaria/requestidlecallback-polyfill, but the package itself won't work since |
When creating a RCTFrameUpdate, ensure it is created with the correct unix timestamp. This is needed to match the NSTimeInterval type. Previously, it was using the CADisplayLink's "timestamp" property, which is not an NSTimeInterval but is instead a CFTimeInterval. This is the Mach host time converted to seconds, which is the number of seconds since the device was turned on. This was causing issues with the window.requestIdleCallback timers as the timer code was expecting this "timestamp" property to be a unix timestamp in seconds which was causing the calculations to be done incorrectly and for the callbacks to never be called. Fixes facebook#28602
@Freddy03h @svenlombaert I have found the issue that's causing this and submitted a PR to fix it. It's easy to fix this yourself using patch-package. |
This was causing issues with the window.requestIdleCallback timers as the timer code was expecting this "timestamp" property to be a unix timestamp in seconds which was causing the calculations to be done incorrectly and for the callbacks to never be called. Fixes facebook#28602
I hope this can get fixed? It's pretty confusing that the function is defined and everything seems right, but then the code just stops executing when we try to use the function. Took me a bit to realize what the issue was since it works fine on Android. |
I don't know about to following of the issue, I stoped using |
This was causing issues with the window.requestIdleCallback timers as the timer code was expecting this "timestamp" property to be a unix timestamp in seconds which was causing the calculations to be done incorrectly and for the callbacks to never be called. Fixes facebook#28602
Bump. Any movement on this?
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This issue was closed because it has been stalled for 7 days with no activity. |
Summary: Fixes #28602 When creating a `RCTFrameUpdate`, ensure it is created with the correct unix timestamp in seconds. This is needed to match the `NSTimeInterval` type defined in the header. Previously, it was using the `CADisplayLink`'s `timestamp` property, which is not an `NSTimeInterval` but is instead a `CFTimeInterval` (note the different class prefix). This is the host time converted to seconds, which is the number of seconds since the device was turned on and therefore not a unix timestamp as expected. This was causing issues with the `window.requestIdleCallback` timers as the timer code was expecting this `timestamp` property to be a unix timestamp in seconds which was causing the calculations to be done incorrectly and for the callbacks to never be called. The code does this calculation is here: https://github.com/facebook/react-native/blob/4d920fe7c991eaec61d229a71df30b0f6c446d38/React/CoreModules/RCTTiming.mm#L262 As one of these is a valid unix timestamp and the other is a much smaller number (number of seconds since device turn on), the `if` statement following this calculation never passes and the callbacks are never called. This regression seems to have been introduced with this pull request: #26114 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Fixed] - Fixed window.requestIdleCallback not firing on iOS Pull Request resolved: #29895 Test Plan: I have tested this by patching my React Native code and testing that idle callbacks are correctly called. There is a reproduction case of the issue in the linked issue. Reviewed By: NickGerleman Differential Revision: D47381404 Pulled By: sammy-SC fbshipit-source-id: fd166741889b0084e1def8dedf6e4018adfd570f
Just wondering is there any update on this in Hermes? Can we run requestIdleCallback on iOS yet? |
Description
requestIdleCallback
is never called on iOS. On a debug or release mode the behavior is the same. On Android it still work as expected.The only way for
requestIdleCallback
to be called on iOS is by providing an timeout option (but all called ofrequestIdleCallback
will be withdidTimeout
…).It's a regression in 0.62.X, it worked well on 0.61.5 (and since, at least, 0.47.X on my own app).
React Native version:
Steps To Reproduce
Expected Results
Expect to
requestIdleCallback
work as expected.Snack, code example, screenshot, or link to a repository:
Expo/Snack is not yet on 0.62, the best way is to create a new project with react native cli or by cloning https://github.com/react-native-community/rn-diff-purge/tree/release/0.62.2/RnDiffApp
Thank you
The text was updated successfully, but these errors were encountered: