Nope, it's not just that. The loader is not shown all the time and removed when there is nothing else to load any more; rather, it is only added when the endless scrolling element is actively loading, and this state does not appear to be applied synchronously. We're probably going to have to wait an arbitrary time for it to appear, I guess.

After a bit of poking, it doesn't seem like it's a good idea to try to use some understanding of the timing and order of when certain things happen in the scroll process to precisely target when the loader should be checked for. I could probably figure out what's occurring on each frame of this process, but something like "wait n requestAnimationFrames" isn't that robust, and more importantly, it seems like our resize observer can be triggered multiple times during this process due to the whole mess about how cell repositioning and resizing works on a delay, so it would be meaningless anyway.

(image is for flavor)

Thinking about a technique that doesn't really care about event order at all... maybe one could, like:

• in the resize observer, set a timer that stops scrolling after n milliseconds (if there are no loaders at that time)
• register a pageModifications callback for loaders being added to the page. in the callback, if currently scrolling, kill the timer.
• in stopScrolling, kill the timer
• also, in the resize observer itself, kill the (previous) timer

So the scroll gets cancelled if we scroll, and in the next n milliseconds, no scroll occurs, no loader gets added and no loader exists. The scroll doesn't get cancelled if there is still a loader (timeline v1) or if a loader gets added or removed, or if a — yeah.

Pretty sure there are no race conditions in that.