You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.
Currently, calling clearTimeout(timeoutId: number), as well as the other patched timer methods, clears the timeout in browser, but does not cancel the corresponding zone task.
Details
The patched timer methods, such as setTimeout, return a Task instance. At the same time, by the DOM specs, the return value should be numeric.
Polymer, for example, depends on the setTimeout return value to be numeric. In Polymer.Async implementation, the setTimeout output is processed with a tilde operator ~.
Given a Task instance, the numeric operations will implicitly invoke task.toString(). This way Zone’s task is spec-compatible. But the issues pop up when the resulting numbers are reused for clearing the timeouts.
Impact
This issue could block the protractor integration tests for the Angular apps that use Polymer elements. The tests timeout trying to sync with the Angular page, they wait for the stable flag, which is never raised because of some timeouts cleared, while their tasks are still pending.
Possible solutions
Ideally, the patched timer methods should return numeric IDs, as required by the spec. But that would be a big change, possibly breaking the code that depends on current Zone’s Task returns.
Another option is to extend the patched timer methods so that the clearTimeout and such can be called with a numeric timeout ID. This requires storing the tasks in an array indexed by timeoutIDs, which is easy.
The text was updated successfully, but these errors were encountered:
platosha
added a commit
to platosha/zone.js
that referenced
this issue
Sep 20, 2016
Currently, calling
clearTimeout(timeoutId: number)
, as well as the other patched timer methods, clears the timeout in browser, but does not cancel the corresponding zone task.Details
The patched timer methods, such as
setTimeout
, return aTask
instance. At the same time, by the DOM specs, the return value should be numeric.Polymer, for example, depends on the
setTimeout
return value to be numeric. InPolymer.Async
implementation, thesetTimeout
output is processed with a tilde operator~
.Given a
Task
instance, the numeric operations will implicitly invoketask.toString()
. This way Zone’s task is spec-compatible. But the issues pop up when the resulting numbers are reused for clearing the timeouts.Impact
This issue could block the protractor integration tests for the Angular apps that use Polymer elements. The tests timeout trying to sync with the Angular page, they wait for the stable flag, which is never raised because of some timeouts cleared, while their tasks are still pending.
Possible solutions
Ideally, the patched timer methods should return numeric IDs, as required by the spec. But that would be a big change, possibly breaking the code that depends on current Zone’s
Task
returns.Another option is to extend the patched timer methods so that the
clearTimeout
and such can be called with a numeric timeout ID. This requires storing the tasks in an array indexed by timeoutIDs, which is easy.The text was updated successfully, but these errors were encountered: