Properly determine bfcache integration strategy #275
Comments
|
Also unclear: when a document stops being fully active, should each PressureObserver's internal slots get reset? |
rakuco
added a commit
that referenced
this issue
Jun 3, 2024
Related to #275, where it is explained that the current model of activating data delivery again when a document becomes fully active is unclear. Furthermore, doing the same thing to workers based on whether they are active needed workers or not does not have precedent in other specs and it is not clear if the current steps even work or not. Instead, do the following: - Remove the steps that handle a document becoming fully active again and point to #275. - Remove the steps that handle a worker becoming an active needed worker again for symmetry (and also because it is not clear if it _can_ become an active worker again once it it stops being so). - Merge the "Handle unloading document and closing of workers" section into the "Handling change of fully active" one. - For documents, the former was basically duplicating the latter. In fact, the "unloading document cleanup steps" are how specs are supposed to react to a document no longer being fully active. - For workers, the "active needed worker" references have been replaced by a check for the value of the `closing` flag in WorkerGlobalScope. - Use proper algorithm steps instead of prose to outline the steps that must be performed in both cases.
rakuco
added a commit
that referenced
this issue
Jun 4, 2024
Related to #275, where it is explained that the current model of activating data delivery again when a document becomes fully active is unclear. Furthermore, doing the same thing to workers based on whether they are active needed workers or not does not have precedent in other specs and it is not clear if the current steps even work or not. Instead, do the following: - Remove the steps that handle a document becoming fully active again and point to #275. - Remove the steps that handle a worker becoming an active needed worker again for symmetry (and also because it is not clear if it _can_ become an active worker again once it it stops being so). - Merge the "Handle unloading document and closing of workers" section into the "Handling change of fully active" one. - For documents, the former was basically duplicating the latter. In fact, the "unloading document cleanup steps" are how specs are supposed to react to a document no longer being fully active. - For workers, the "active needed worker" references have been replaced by a check for the value of the `closing` flag in WorkerGlobalScope. - Use proper algorithm steps instead of prose to outline the steps that must be performed in both cases.
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.
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:
Pragmatically, merging #276 helps move #265 forward, but it'd be nice to revisit this issue later. |
rakuco
added a commit
that referenced
this issue
Jun 4, 2024
Related to #275, where it is explained that the current model of activating data delivery again when a document becomes fully active is unclear. Furthermore, doing the same thing to workers based on whether they are active needed workers or not does not have precedent in other specs and it is not clear if the current steps even work or not. Instead, do the following: - Remove the steps that handle a document becoming fully active again and point to #275. - Remove the steps that handle a worker becoming an active needed worker again for symmetry (and also because it is not clear if it _can_ become an active worker again once it it stops being so). - Merge the "Handle unloading document and closing of workers" section into the "Handling change of fully active" one. - For documents, the former was basically duplicating the latter. In fact, the "unloading document cleanup steps" are how specs are supposed to react to a document no longer being fully active. - For workers, the "active needed worker" references have been replaced by a check for the value of the `closing` flag in WorkerGlobalScope. - Use proper algorithm steps instead of prose to outline the steps that must be performed in both cases.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
PressureObserverinstances 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).
The text was updated successfully, but these errors were encountered: