Pause command bug when used inside state-changing conditions and target selectors

[bob2517]

Found a juicy bug in the pause command logic today...

If a pause command is being run in an @if statement, and a variable then changes prior to the pause command being run, which would, if the event ran again, would stop that same condition from running once more, the pause will not resume. Basically the core iterates through the statements and commands in an event to find where it left off, and then resumes after the pause command, which is the hidden magic in the core for that. Minor fatal flaw though, in its implementation.

The most performant solution without rewriting the inner core of the core is to track the successful and unsuccessful conditions on the way to every pause event, and on returning after the delay use true/false on those conditionals on the way to the pause command so that the same place is gotten to and resumed from.

Will do this one after the intersect event implementation which is almost done. This issue has been around for a while and no one has shouted for it, so obviously no one has run into it, obviously because I've received no bugs reports :)

Note to self: I think this is already handled, but check that the pause event re-enters after selector selection. I'm pretty sure it does already, but make sure, for the case of attribute/class changes on the target element for handlings done prior to the pause or during the pause. Also will need to track while and anything else that has a potentially changeable aspect.

[bob2517]

This now fixed offline, but in testing I've found another scenario now related to target selectors and not conditionals and loops. Inside a loop and a conditional, if using a last-of-type on a div selection to get a target range, and a new div element is added to the list inside there, followed by a pause, on resumption of the pause it appears to be getting confused as to the correct div it should be using, which makes sense as the last-of-type is now a new element. So the original element needs to be used when resuming a pause to get back into the correct place. This should hopefully be the last scenario, as currently I believe there are only really loops, conditionals and target selector states to remember. Actually - @media needs checking too. Will have a crack at fixing that scenario before committing as so far it's only a partial fix and handlings are related.

Note to self: Same strategy as before - same place for clean-up and var settings. Store complete collection of target objects as evaluation of the selector, like conditions, may be different. Any elements no longer present on resumption would fail the resumption of the pause so no further action will be necessary.

[bob2517]

Using the pause command in target selectors that may change element state during the pause is now fixed offline, along with cancel-pause: all; changes to keep that working. Fixed a minor memory leak whilst doing this. I think by doing this I've also fixed a related issue to do with the await command working in conditions/target selectors that have changeable states during the await pause, which I'm now thinking was also busted, as in hindsight I can't see how it would have worked without the changes I've made.

All that's left is to fix a weird side effect with media queries. But once that is sorted I'm thinking that may be a wrap. Not ready to do a commit yet because of this side effect potentially causing problems with the branch.

[bob2517]

Fix is now on the branch. I've tested this with some complex scenarios, so I'm hoping that should be good. Will test it further on production sites before release.

[bob2517]

There was an issue with while statements which is now mostly fixed- nested whiles with pause are still an issue. Nested whiles appear to operate as expected though when there are no pause commands.

Outstanding on this issue: Nested while statements in combination with pause gets into a recursion overload. There is a parsing issue with continue; when it has no whitespace regardless of a linebreak. Will fix that next.

[bob2517]

A fix for the specific parsing error with "continue;" is now on branch. It affected the other loop control commands too.

[bob2517]

The known loop and pause resumption errors are now all fixed offline. Will do a final, really complex series of loop types and pauses over concurrent standard and custom events next and see if anything rears its head. I can see why there isn't a straightforward pause command in JavaScript - it's definitely not the easiest thing to set up.

[bob2517]

Happy with this, for now at least with the tests I've done - will commit today and see where we're at on the intersect event before doing a release.

Note to self: make a call for testers on the main docs site.

[bob2517]

Fixes now on branch. Will test new fixes on production this week and if fine gear up for official release next weekend. Should be a slight speed improvement on the next release - removed a couple of unnecessary processing steps in the general event flow.

[bob2517]

Closing pending release.