Browser:
all | Chrome XX | Firefox XX | Edge XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView
Language:
all | TypeScript X.X | ESNext
Current behavior:
If one of the queued micro tasks calls flushMicroTaskQueue
Queue enters the second flush cycle even though flushing is set to true
after which length of queue is set to zero
but for 1st flush call index is greater then length of queue at this point
and leads to unexpected behavior
Expected/desired behavior:
What is the expected behavior?
If queue is already flushing we should ignore the second call
What is the motivation / use case for changing the behavior?
prevent uncertainty
I'm submitting a bug report
Please tell us about your environment:
Operating System: OSX 10.x|Linux (distro)|Windows [7|8|8.1|10]
Node Version: 6.2.0
NPM Version: 3.8.9
Browser: all | Chrome XX | Firefox XX | Edge XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView
Language: all | TypeScript X.X | ESNext
Current behavior: If one of the queued micro tasks calls flushMicroTaskQueue Queue enters the second flush cycle even though flushing is set to true after which length of queue is set to zero but for 1st flush call index is greater then length of queue at this point and leads to unexpected behavior
Expected/desired behavior:
What is the expected behavior? If queue is already flushing we should ignore the second call
What is the motivation / use case for changing the behavior? prevent uncertainty