fix: Align TimerManager sequential ids and function error handling with web standard#51500
fix: Align TimerManager sequential ids and function error handling with web standard#51500kitten wants to merge 6 commits intofacebook:mainfrom
TimerManager sequential ids and function error handling with web standard#51500Conversation
As per WHATWG HTML 8.6.1 (Timers) ids must be greater than zero, i.e. start at 1
TimerManager sequential ids and function error handling on with web standardTimerManager sequential ids and function error handling with web standard
|
@rshest has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
cipolleschi
left a comment
There was a problem hiding this comment.
Thanks for the fix! :D
|
This pull request was successfully merged by @kitten in 480a464 When will my fix make it into a release? | How to file a pick request? |
…with web standard (#51500) Summary: Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the `TimerManager` implementation, which instead starts at zero inclusively. This has two side-effects for code assuming a spec-compliant implementation of `setTimeout` and `setInterval`: - Calls to `clearTimeout(0)` or `clearInterval(0)` will potentially cancel scheduled timers, although it's supposed to be a noop - Predicates like `if (timeoutId)` will fail since they assume non-negative ids The change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers > otherwise, let id be an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) integer that is **greater than zero** and does not already [exist](https://infra.spec.whatwg.org/#map-exists) in global's [map of setTimeout and setInterval IDs](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#map-of-settimeout-and-setinterval-ids). Specifically, - we should return `0` to indicate that no timer was scheduled - we should start generating timer IDs at `1` instead of `0` This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008 The spec-incompliant behaviour was raised in an issue here: apollographql/apollo-client#12632 (comment) This PR does not, - add bounds checking on `timerIndex_` and add a search of an available id that isn't in the unordered map - exclude `0` from being an accepted `TimerHandle` in `TimerManager::createTimer` or `TimerManager::deleteTimer` since the above bounds checking hasn't been added either ## Changelog: [GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards. Pull Request resolved: #51500 Test Plan: - Run `setTimeout` / `setInterval`; before applied changes the timeout for the first timer will be `0` - Run `setTimeout(null)`; before applied changes the timer ID will be non-zero - Run `setInterval(null)`; before applied changes an error will be thrown rather than `0` being returned Reviewed By: cipolleschi Differential Revision: D75145909 Pulled By: rshest fbshipit-source-id: 6646439abd29cf3cfa9e5cf0a57448e3b7cd1b48
|
This pull request was successfully merged by @kitten in 24131c6 When will my fix make it into a release? | How to file a pick request? |
…with web standard (#51500) Summary: Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the `TimerManager` implementation, which instead starts at zero inclusively. This has two side-effects for code assuming a spec-compliant implementation of `setTimeout` and `setInterval`: - Calls to `clearTimeout(0)` or `clearInterval(0)` will potentially cancel scheduled timers, although it's supposed to be a noop - Predicates like `if (timeoutId)` will fail since they assume non-negative ids The change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers > otherwise, let id be an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) integer that is **greater than zero** and does not already [exist](https://infra.spec.whatwg.org/#map-exists) in global's [map of setTimeout and setInterval IDs](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#map-of-settimeout-and-setinterval-ids). Specifically, - we should return `0` to indicate that no timer was scheduled - we should start generating timer IDs at `1` instead of `0` This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008 The spec-incompliant behaviour was raised in an issue here: apollographql/apollo-client#12632 (comment) This PR does not, - add bounds checking on `timerIndex_` and add a search of an available id that isn't in the unordered map - exclude `0` from being an accepted `TimerHandle` in `TimerManager::createTimer` or `TimerManager::deleteTimer` since the above bounds checking hasn't been added either ## Changelog: [GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards. Pull Request resolved: #51500 Test Plan: - Run `setTimeout` / `setInterval`; before applied changes the timeout for the first timer will be `0` - Run `setTimeout(null)`; before applied changes the timer ID will be non-zero - Run `setInterval(null)`; before applied changes an error will be thrown rather than `0` being returned Reviewed By: cipolleschi Differential Revision: D75145909 Pulled By: rshest fbshipit-source-id: 6646439abd29cf3cfa9e5cf0a57448e3b7cd1b48
|
This pull request was successfully merged by @kitten in 942422c When will my fix make it into a release? | How to file a pick request? |
…with web standard (#51500) Summary: Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the `TimerManager` implementation, which instead starts at zero inclusively. This has two side-effects for code assuming a spec-compliant implementation of `setTimeout` and `setInterval`: - Calls to `clearTimeout(0)` or `clearInterval(0)` will potentially cancel scheduled timers, although it's supposed to be a noop - Predicates like `if (timeoutId)` will fail since they assume non-negative ids The change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers > otherwise, let id be an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) integer that is **greater than zero** and does not already [exist](https://infra.spec.whatwg.org/#map-exists) in global's [map of setTimeout and setInterval IDs](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#map-of-settimeout-and-setinterval-ids). Specifically, - we should return `0` to indicate that no timer was scheduled - we should start generating timer IDs at `1` instead of `0` This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008 The spec-incompliant behaviour was raised in an issue here: apollographql/apollo-client#12632 (comment) This PR does not, - add bounds checking on `timerIndex_` and add a search of an available id that isn't in the unordered map - exclude `0` from being an accepted `TimerHandle` in `TimerManager::createTimer` or `TimerManager::deleteTimer` since the above bounds checking hasn't been added either ## Changelog: [GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards. Pull Request resolved: #51500 Test Plan: - Run `setTimeout` / `setInterval`; before applied changes the timeout for the first timer will be `0` - Run `setTimeout(null)`; before applied changes the timer ID will be non-zero - Run `setInterval(null)`; before applied changes an error will be thrown rather than `0` being returned Reviewed By: cipolleschi Differential Revision: D75145909 Pulled By: rshest fbshipit-source-id: 6646439abd29cf3cfa9e5cf0a57448e3b7cd1b48
|
This pull request was successfully merged by @kitten in 26b70c2 When will my fix make it into a release? | How to file a pick request? |
…with web standard (#51500) Summary: Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the `TimerManager` implementation, which instead starts at zero inclusively. This has two side-effects for code assuming a spec-compliant implementation of `setTimeout` and `setInterval`: - Calls to `clearTimeout(0)` or `clearInterval(0)` will potentially cancel scheduled timers, although it's supposed to be a noop - Predicates like `if (timeoutId)` will fail since they assume non-negative ids The change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers > otherwise, let id be an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) integer that is **greater than zero** and does not already [exist](https://infra.spec.whatwg.org/#map-exists) in global's [map of setTimeout and setInterval IDs](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#map-of-settimeout-and-setinterval-ids). Specifically, - we should return `0` to indicate that no timer was scheduled - we should start generating timer IDs at `1` instead of `0` This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008 The spec-incompliant behaviour was raised in an issue here: apollographql/apollo-client#12632 (comment) This PR does not, - add bounds checking on `timerIndex_` and add a search of an available id that isn't in the unordered map - exclude `0` from being an accepted `TimerHandle` in `TimerManager::createTimer` or `TimerManager::deleteTimer` since the above bounds checking hasn't been added either ## Changelog: [GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards. Pull Request resolved: #51500 Test Plan: - Run `setTimeout` / `setInterval`; before applied changes the timeout for the first timer will be `0` - Run `setTimeout(null)`; before applied changes the timer ID will be non-zero - Run `setInterval(null)`; before applied changes an error will be thrown rather than `0` being returned Reviewed By: cipolleschi Differential Revision: D75145909 Pulled By: rshest fbshipit-source-id: 6646439abd29cf3cfa9e5cf0a57448e3b7cd1b48
|
This pull request was successfully merged by @kitten in 157cf11 When will my fix make it into a release? | How to file a pick request? |
Summary:
Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the
TimerManagerimplementation, which instead starts at zero inclusively.This has two side-effects for code assuming a spec-compliant implementation of
setTimeoutandsetInterval:clearTimeout(0)orclearInterval(0)will potentially cancel scheduled timers, although it's supposed to be a noopif (timeoutId)will fail since they assume non-negative idsThe change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
Specifically,
0to indicate that no timer was scheduled1instead of0This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008
The spec-incompliant behaviour was raised in an issue here: apollographql/apollo-client#12632 (comment)
This PR does not,
timerIndex_and add a search of an available id that isn't in the unordered map0from being an acceptedTimerHandleinTimerManager::createTimerorTimerManager::deleteTimersince the above bounds checking hasn't been added eitherChangelog:
[GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards.
Test Plan:
setTimeout/setInterval; before applied changes the timeout for the first timer will be0setTimeout(null); before applied changes the timer ID will be non-zerosetInterval(null); before applied changes an error will be thrown rather than0being returned