Handle deferred processing when document is hidden

[afshin]

This PR does the following.

• Modifies the behavior of the polls' when-hidden standby to tick once after being hidden (the default options.linger value of 1 time can be overridden at instantiation time)
• Modifies the MessageLoop to use a new promise-based implementation of schedule for immediate deferral to support always running in background tabs
• Modifies Poll to export a protected hidden attribute to indicate to sub-classes when the document is hidden.

We can backport this to 1.x as well.

CC: @thetorpedodog – I kept your suggested setTimeout for Poll instances because almost all polls have a nonzero interval anyway and it simplifies that code. I updated MessageLoop to work in the background without having to resort to setTimeout.

---

Fixes #400

[blink1073]

Thanks!

[vidartf]

[...] schedule uses setTimeout when the window is hidden and uses requestAnimationFrame/setImmediate otherwise

What are the nuances of this? If a window is visible, and I requestAnimationFrame and then hide the window, will the trigger fire the next time I show the window? If that is the case, it seems like this will cause some inconsistent behavior?

Also: Do we know what was the motivation for choosing requestAnimationFrame rather than setTimeout for the message loop originally? It seems like not driving the page when it is hidden is considerate of system resources, and this will change that.

[afshin]

I think the primary original motivation wasn't about consideration of system resources so much as it was about responsiveness. Consider this example somebody created that is very illustrative: https://codepen.io/YOONBYEONGIN/pen/RwxrEPN

It seems pretty unlikely that you could hide the window in the time between when you invoke requestAnimationFrame and the time the function actually fires.

[vidartf]

It seems pretty unlikely that you could hide the window in the time between when you invoke requestAnimationFrame and the time the function actually fires.

@afshin It might be unlikely, but if it happens once a month for a heavy user, and the consequence is catastrophic, then it still matters. So the question the becomes, what will be the failure mode if one callback gets stuck waiting on an animation frame while other callbacks keep firing with timeouts? Do we end up processing messages out of order? I don't think "probably nothing bad will happen" is an ok answer in this case. Waiting a bit for something after resuming a browser tab is in general a more ok user experience than undefined behavior (you can fit a lot into "undefined behavior").

[afshin]

I should have stated that more strongly: you have <1ms to switch tabs from the time you have invoked an animation frame to the time it fires. The only time unschedule() is invoked by the message loop logic, it is in the flush() function, which is invoked by Lumino code only to support older IE and Edge. It's not actually invoked otherwise, so I am not coming up with a scenario I can imagine where it causes loop events ever firing in the incorrect order or leading to a catastrophic outcome.

I'll give it some more thought.

Does anyone else who has considered this part of the code base have any thoughts?

[afshin]

if one callback gets stuck waiting on an animation frame while other callbacks keep firing with timeouts

Hm. You're right, @vidartf. This is possible. I put the PR back in draft mode.

Perhaps client code needs to specify whether it wants to run when the document is hidden (slower because it is setTimeout but runs in background tabs as well), or be strictly tied to animation frames and only run when the document is visible.

[afshin]

After a lot of back and forth, this is ready for review.

[blink1073]

LGTM!

[fcollonval]

Thanks @afshin

I have two comments.

[fcollonval]

@afshin should we move forward with this one?

[vidartf]

As mentioned in last weeks lab dev meeting, using a Promise or async will schedule the task as a microtask, compared to requestAnimationFrame / setTimeout etc that will schedule it as a macro task. This difference is likely to be significant (@afshin has the details).

[afshin]

It is safe in this circumstance because message propagation is both lightweight and synchronous. This is the reason why the same technique is unavailable to us in Poll.

[afshin]

@afshin should we move forward with this one?

Yes, I wanted to give @vidartf a chance to look, but I'm happy to move ahead.