Repository navigation
[BUG] setTimeout fires incorrectly when using chrome debug #4470
Description
Hey,
I've found an issue that means when you're running on an iOS device and debugging in chrome setTimeouts can fire in the wrong order. If you place the following code block into a fresh app and run it you should get the error...
componentDidMount:function() {
this.runTest()
},
test:function(cb) {
var aFired = false
var bFired = false
var aExpected = new Date().getTime()+130
var bExpected = new Date().getTime()+500
console.log('Schedule A to fire @' + aExpected)
console.log('Schedule B to fire @' + bExpected)
var a = setTimeout(() => {
var now = new Date().getTime()
console.log('A fired', now, now - aExpected)
aFired = true
if (bFired) { console.log('ERROR: b fired early'); return;
}
if (aFired && bFired) { cb() }
}, 130)
var b = setTimeout(() => {
var now = new Date().getTime()
console.log('B fired', now, now - bExpected)
bFired = true
if (!aFired) { console.log('ERROR: A not fired'); return;
}
if (aFired && bFired) { cb() }
}, 500)
},
runTest:function() {
this.test(() => {
setTimeout(() => {
this.runTest()
}, 500)
})
},On the console you'll get something like...
index.ios.js:25 Schedule A to fire @1448977966848
index.ios.js:26 Schedule B to fire @1448977967218
index.ios.js:30 A fired 1448977966754 -94
index.ios.js:38 B fired 1448977966755 -463
index.ios.js:25 Schedule A to fire @1448977966902
index.ios.js:26 Schedule B to fire @1448977967272
index.ios.js:30 A fired 1448977966806 -96
index.ios.js:38 B fired 1448977966806 -466
index.ios.js:25 Schedule A to fire @1448977966951
index.ios.js:26 Schedule B to fire @1448977967321
index.ios.js:30 A fired 1448977966835 -116
index.ios.js:38 B fired 1448977966835 -486
index.ios.js:25 Schedule A to fire @1448977966983
index.ios.js:26 Schedule B to fire @1448977967353
index.ios.js:38 B fired 1448977966871 -482
index.ios.js:40 ERROR: A not fired
index.ios.js:30 A fired 1448977966871 -112
index.ios.js:32 ERROR: b fired early
... with the first 3 firing correctly and the last one incorrectly. I believe this bug is also what is causing issue #1693 as one of the setTimeout functions sometimes fires early in touchableHandleResponderGrant
Reacted by Sibelius Seraphini, William Wong, Roman Galochkin, Vladislav Bezenson, Hans Piña, Sébastien Lorber, Alex, Samer Murad and Lucas Bento
Activity
facebook-github-bot commentedon Dec 1, 2015
Hey Thomas101, thanks for reporting this issue!
React Native, as you've probably heard, is getting really popular and truth is we're getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.
react-nativeor for more real time interactions, ask on Discord in the #react-native channel.christopherdro commentedon Dec 1, 2015
@Thomas101 Try taking a look at https://facebook.github.io/react-native/docs/timers.html#timermixin at the last paragraph:
We strongly discourage using the global setTimeout(...) and recommend instead that you use this.setTimeout(...)Thomas101 commentedon Dec 1, 2015
Thanks @christopherdro, we've been using that wherever possible but some of the built in react functionality uses plain old settimeout which is where the bug raised its head initially
ide commentedon Dec 1, 2015
@Thomas101 Thanks for your detailed investigation and write-up. RN should implement timers correctly. In fact if I'm reading your code and logs correctly, it looks like the timeout arg is ignored as events A and B run at almost the same time. cc @sahrens
Thomas101 commentedon Dec 1, 2015
Those were the logs that came out, you should get similar results if you run it yourself. This is purely speculation as I haven't looked at the implementation, but as it only happenens when running the chrome debugger and using the device, did wonder if it could be a time drift issue between my Mac and ipad?
satya164 commentedon Dec 3, 2015
@christopherdro Also not possible to use it when using the ES6 class syntax. Need to manually cleanup ofc.
sahrens commentedon Dec 5, 2015
Not sure who owns timers these days - maybe @tadeuzagallo or @nicklockwood ? Also cc @dmmiller because we want to be consistent on iOS and android.
aleclarson commentedon Jan 6, 2016
I've experienced this while "Debug in Chrome" is active.
setTimeoutfires very early.Has it been confirmed that
TimerMixinavoids this issue?I thought
TimerMixinonly helps with cleanup incomponentWillUnmount?Thomas101 commentedon Jan 7, 2016
Hi @aleclarson using the TimerMixin still has the same problem as this uses setTimeout behind the scenes.
aleclarson commentedon Jan 8, 2016
Who works on the
debugger-proxypackager endpoint? Is there a hack related tosetTimeoutthat involves accounting for socket latency? I can't imagine how elsesetTimeoutcould be acting so strangely.PaulBGD commentedon Jan 9, 2016
Go vote for this issue so that the developers can see that it's important: https://productpains.com/post/react-native/settimeout-fires-incorrectly-when-using-chrome-debug/
sahrens commentedon Jan 9, 2016
I don't know much about our chrome integration or why it would cause a difference in timer behavior - @frantic or @tadeuzagallo?
aleclarson commentedon Jan 12, 2016
Would it be worth implementing a native shim for
setTimeoutandclearTimeout?satya164 commentedon Jan 19, 2016
Any updates on this?
24 remaining items
alpfilho commentedon Aug 9, 2017
still an issue in 0.46.4
dave-irvine commentedon Aug 24, 2017
Still an issue on 0.47.x as far as I can tell
#18 Implemented a timeout for recording the video. Note that this onl…
emusgrave commentedon Sep 5, 2017
@Odinvt Did you consider integrating your library into a PR for the core RN library? I'm curious if the team would accept it as a solution for this issue.
Odinvt commentedon Sep 5, 2017
@emusgrave I thought about it and I would love to, but I don't think that the PR will be merged because first of all, it's an ugly hack and second of all, it's not a modification of react native's source code, it's only a modification of another package ( React Native Timer ) which would force devs to use the package's overridden methods instead of the classic JS setTimeout and setInterval methods...
The source code is there, we've been using it for 4 months in our dev env for our projects and it's proven its worth. I encourage anyone who has the time to make those changes in RN's source code and submit a PR to do so, I think that the idea is there but the code still needs some refactoring and tests should be written. I hope you're all having fun creating stuff with RN as I know I do <3
kesha-antonov commentedon Oct 17, 2017
RN 0.50 Same issue
ahmb84 commentedon Nov 13, 2017
Same issue from RN 0.50.3
loveky commentedon Dec 13, 2017
any update on this? just spent about 1 hour and see this issue... 😞
jacklovepdf commentedon Dec 15, 2017
close the debugger model
Vishal-vash commentedon Dec 20, 2017
I had similar issue using
onLongPresswith debugger open and it fires the event asonPress, SoonLongPressalso don't work accurately in debugger mode similar tosetTimeout/setIntervaldhirendrarathod2000 commentedon Mar 19, 2018
RN 0.53
Not working
fatfatson commentedon Apr 18, 2018
sync your emulator and host' time by:
Sharcoux commentedon May 12, 2018
get-date-> unknown command.I had better luck with: