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
When a wildcard observer is queued to run, and a different batched property re-sets a dependency to the observer, the nested call to the observer returns the correct information, but the initially queued observer runs with a stale value in the info argument.
Live Demo
Setup: The trigger dependency causes computeArray to be run with an uninitialized size (defaults to 0); at this point the arrayChanged observer is queued to run, but before it does the trigger observer runs and sets size to 1. This causes a nested invocation of computeArray and arrayChanged to be run first (with the correct info information reflecting the new array size of 1). However, when the processing unrolls back to the initially queued invocation of arrayChanged, it runs with stale info information.
info.value.length always matches this.array.length at the time the observer runs.
Actual Results
The initial observer invocation (which runs last, due to a re-entrant change after it was enqueued) returns info.value.length == 0 while this.array.length == 1.
Note that in 3.x, the observer runs twice, while in 1.x it only runs once. This is expected, since in 1.x the initial call to computeArray is aborted because of the "undefined" rule (the size argument is yet undefined); however in 2.x comptueArray runs first due to trigger, and subsequently due to size. That is WAI, however the info should always reflect the current state of the world
Browsers Affected
All
Versions
Polymer: v3.x, v2.x
The text was updated successfully, but these errors were encountered:
Description
When a wildcard observer is queued to run, and a different batched property re-sets a dependency to the observer, the nested call to the observer returns the correct information, but the initially queued observer runs with a stale
value
in theinfo
argument.Live Demo
Setup: The
trigger
dependency causescomputeArray
to be run with an uninitialized size (defaults to 0); at this point thearrayChanged
observer is queued to run, but before it does thetrigger
observer runs and setssize
to 1. This causes a nested invocation ofcomputeArray
andarrayChanged
to be run first (with the correctinfo
information reflecting the new array size of 1). However, when the processing unrolls back to the initially queued invocation ofarrayChanged
, it runs with staleinfo
information.3.x: https://jsbin.com/babeyaz/1/edit?html,console,output (wrong)
1.x: https://jsbin.com/vojode/edit?html,console,output (correct)
Expected Results
info.value.length
always matchesthis.array.length
at the time the observer runs.Actual Results
The initial observer invocation (which runs last, due to a re-entrant change after it was enqueued) returns
info.value.length == 0
whilethis.array.length == 1
.Note that in 3.x, the observer runs twice, while in 1.x it only runs once. This is expected, since in 1.x the initial call to
computeArray
is aborted because of the "undefined" rule (thesize
argument is yet undefined); however in 2.xcomptueArray
runs first due totrigger
, and subsequently due tosize
. That is WAI, however theinfo
should always reflect the current state of the worldBrowsers Affected
All
Versions
The text was updated successfully, but these errors were encountered: