Properly determine bfcache integration strategy

[rakuco]

https://w3c.github.io/compute-pressure/#handling-change-of-fully-active lists what to do when a Document either (1) stops being fully active or (2) starts being fully active again.

The steps for (1) basically say that data delivery must stop, which is pretty vague: should any hardware resources or platform handles be released, for example?

The steps for (2) are even more unclear: if telemetry collection is stopped at the platform level in (1), it means that reactivating collection would mean going through most of https://w3c.github.io/compute-pressure/#the-observe-method without calling the method itself. This includes the fact that starting telemetry data collection may fail for multiple reasons.

Maybe (2) shouldn't exist at all; however, if we do this the API should have a way to signal that it's no longer going to provide updates so that when the document is restored by the bfcache existing PressureObserver instances just remain existing without providing any data.

It's also curious that there doesn't seem to be a way to distinguish between a document not being fully active because e.g. it's in an iframe that got detached (and thus will never become fully active again, so we could just drop all resources without caring) and it becoming fully active because it's entering the bfcache (in which case we could care about gathering data automatically again).

[rakuco]

Also unclear: when a document stops being fully active, should each PressureObserver's internal slots get reset?

[kenchris]

should any hardware resources or platform handles be released, for example?

I guess it is implementation defined. A lot of time people click back and then forward again by mistake, in which case an implementation would probably use some timeout before releasing the hardware resources, depending on the cost of reinstating them.

Maybe (2) shouldn't exist at all;

So you are thinking a bit like WakeLock where it is the developers responsibility to start observation again. I guess that could work.

[rakuco]

So you are thinking a bit like WakeLock where it is the developers responsibility to start observation again. I guess that could work.

Ideally, we could take of all this behind the scenes and just start providing data again once the document becomes fully active, I just don't know how to do it properly from a spec perspective:

• No other spec seems to add steps to "reactivate a document" at the moment
• If attempting to get pressure data again fails, there is no way to notify users
• From a spec perspective, there isn't a way to differentiate between "this document is going into the bfcache and may be reactivated in the future" and "this document is going away forever", which I thought would be necessary to decide whether to fully release resources or not.

Pragmatically, merging #276 helps move #265 forward, but it'd be nice to revisit this issue later.