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
As of version 1.0.2, there can be an infinite loop when location2action returns multiple actions. The reason is that each of the actions was triggering a call to delta2update (since each action produced a new state). Now, normally we would detect when delta2update produces a URL that is already set. However, in this case there are two, separate changes. The net result after the two changes would be the same. However, we don't detect that, and the infinite loop begins ...
I've got a fix almost ready that keeps track of when we're sending the actions to the address, and basically turns off delta2update while that is happening.
This does involve a slightly wider behaviour change in the following circumstances.
You could, in theory, have multiple URLs which map to the same set of actions (that is, multiple URLs that do the same thing). It might even be sensible (in the "be liberal in what you accept, and strict in what you emit" sense).
Currently when we see a new URL and run location2action, the resulting action will typically generate a state change, which will run delta2update. Now, delta2update will produce a canonical URL for the state, which might be different from the URL we originally saw.
Currently, the canonical URL would then actually be set, if it is different from the URL in the location bar. You might consider this a feature or a bug -- it's a feature, in that you get the canonical URL. But, it's a bug in that you might not want that -- you especially might not want a new history entry.
But, once I apply the fix, the canonical URL won't be computed right away, since delta2update will be disabled while the location2action actions are being sent.
Now, I suppose the canonical URL will be computed whenever the next "normal" action occurs (that is, not computed by location2action), so perhaps that is soon enough? If not, there are some slightly fancier changes I could make to ensure that the canonical URL is computed immediately -- I'll leave that for now, though.
The text was updated successfully, but these errors were encountered:
As of version 1.0.2, there can be an infinite loop when
location2action
returns multiple actions. The reason is that each of the actions was triggering a call todelta2update
(since each action produced a new state). Now, normally we would detect whendelta2update
produces a URL that is already set. However, in this case there are two, separate changes. The net result after the two changes would be the same. However, we don't detect that, and the infinite loop begins ...I've got a fix almost ready that keeps track of when we're sending the actions to the address, and basically turns off
delta2update
while that is happening.This does involve a slightly wider behaviour change in the following circumstances.
location2action
, the resulting action will typically generate a state change, which will rundelta2update
. Now,delta2update
will produce a canonical URL for the state, which might be different from the URL we originally saw.delta2update
will be disabled while thelocation2action
actions are being sent.Now, I suppose the canonical URL will be computed whenever the next "normal" action occurs (that is, not computed by
location2action
), so perhaps that is soon enough? If not, there are some slightly fancier changes I could make to ensure that the canonical URL is computed immediately -- I'll leave that for now, though.The text was updated successfully, but these errors were encountered: