Codecov Report

Merging #684 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #684   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines         166    176   +10     
  Branches       52     58    +6     
=====================================
+ Hits          166    176   +10

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 483ea05...5081bed. Read the comment docs.

Partly? :D

Partly for it being untested.

Further modification is needed because tests are failed by now.

Gotcha. This is a nice attempt. Thanks!

Ultimately, storing the element in the virtual node will solve the problem, help simplify diffing and improve performance, so while this is fun and you are free to keep doing your best, this is not the route I want to choose.

As of commit infinnie@b12f9bd tests could be passed now. But I still don’t know why it even works.

@infinnie Because there's no test documenting the said onremove bug.

@jorgebucaran I mean the original tests.

Also maybe @mindplay-dk could help me document the onremove() bug and write tests for it.

@jorgebucaran ok I’ve added a preliminary test for that purpose.

Thanks, @infinnie! Can you create a new PR with the failing test case only?

But @jorgebucaran I was wrong.
The new test runs for the original code as well.
But there is reordering in the browser if the original code were run.
I am looking for a better test.
:(

Seems that much of the original problem of reordering should have been fixed (accidentally and partly!) as of #663, but that brought forth a problem as I stated in #681 (comment):

Just by the way: what would we expect to happen if two asynchronous element removals happen consecutively, so that when one element is being removed we start to remove the second one?

And this PR then seems to have solved that problem but by reverting #663 (as of 7f79f08) as well as adding my own code. So it is still far from done.

Can you create a new PR with the failing test case only?

@jorgebucaran #685

@infinnie did you try this on the nightmare fiddle I came up with to ruin Jorge's day? 😀

@mindplay-dk See also https://jsfiddle.net/y7a2jc55/ that shows where the original Ultradom is wrong.

@infinnie I wrote this test a while back to document the reordering issue with deferred removals:

mindplay-dk/picodom@2b0784b

I'm not sure if this covers the more complex issue demonstrated by the nightmare fiddle - it was a long time ago and my attentions are elsewhere at the moment.

I wrote a more aggressive test (for my own dead project) for reordering, but that doesn't cover the issue with deferred removals.

Probably what's needed is a more minimal/controlled test of some sort, along the lines of this fiddle, which you could probably turn into a test by hoisting the removal callbacks, same as I did in my first test.

@mindplay-dk What about multiple element removals?