-
So I think what was happening before was we completely re-wrote the list of event handlers when something was added/removed (and it was the list of handlers that got queued for execution). Now, we just modify that list so if you're iterating and you're not at the last entry when it executes it'll carry on.
I just thought of a possible way around this - but I don't know if it's better or worse performance-wise. And there is probably some other drawbacks as well.
But - if
X.on
prepended listeners instead of appending them, maybe we could have the best of both worlds? The newly registered touch listener in theelapsed_t
case would instead sit on top and therefore not run from the current event.If this was to be adopted I suggest:
X.on
starts acting exactly likeX.prependListener
,X.prependListener
stays the same,- a new
X.appendListener
that would work likeX.on
worked before.
A strong argument against this is it breaks spec compliance - if I understand correctly.
Well, I take it back about the touch thing - it just happened to me in a settings menu and I'm not 100% sure why, and wasn't able to reproduce it.
I just tried putting another touch handler after and voila!
It seems 100% reproducible. So I think what was happening before was we completely re-wrote the list of event handlers when something was added/removed (and it was the list of handlers that got queued for execution). Now, we just modify that list so if you're iterating and you're not at the last entry when it executes it'll carry on.
So this needs fixing internally. I guess I'll go back to the old behaviour of making a whole new list of events for every modification - it's not so nice/efficient but I think it's more what people expect.