Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make a way to listen to "fully active" state changes #8872

Closed
rakina opened this issue Feb 9, 2023 · 3 comments
Closed

Make a way to listen to "fully active" state changes #8872

rakina opened this issue Feb 9, 2023 · 3 comments
Labels
integration Better coordination across standards needed

Comments

@rakina
Copy link
Member

rakina commented Feb 9, 2023

In the "Supporting Back/Forward Cached Documents" guide, we suggest spec authors to explicitly listen to changes to the "fully active" state, so that it can react accordingly when documents gets into/restored from the BFCache.

In https://github.com/w3ctag/bfcache-guide/pull/1/files#r1069432963, @annevk suggested that we add a hook for "fully active" state changes, somewhat like the "update the rendering" hook. I think I'm a little bit confused here, because it seems like the "update the rendering" is a hook that gets called by other specs to run the algorithms defined in HTML spec (to update rendering after changes in the external spec occurred), while for the fully active state we kinda want the reverse: the HTML spec will update the fully active state, and we want other specs define what they will do in response to that. So maybe something like "unloading document cleanup steps" will fit better here? With that, other specs can define what they will do in case the fully active state changes. I vaguely remember that we want to steer away from that pattern though, but I'm not 100% sure.

@annevk, do you think adding something like "fully active state change steps" that other specs can define will be OK here? If not, what would be a better option? Sorry if I misunderstood the "update the rendering" suggestion, please let me know if that can help us here. Thanks in advance!

also cc @fergald @domenic @smaug----

@annevk
Copy link
Member

annevk commented Feb 9, 2023

That would be okay as long as those steps are not allowed to execute script. If they are allowed to execute script (e.g., dispatch events) we'd need something closer to https://html.spec.whatwg.org/#update-the-rendering as at that point ordering becomes important. (I suppose ordering could still be important if APIs have interdependencies but they could define a shared set of steps in such a case.)

I'm guessing we don't want to allow more script opportunities so your suggestion is probably fine, but I don't have the full picture.

@annevk annevk added the integration Better coordination across standards needed label Feb 9, 2023
@rakina
Copy link
Member Author

rakina commented Feb 10, 2023

Thanks! Yeah we probably don't want scripts to run outside of the pagehide etc event handlers. Is there a way to require that the steps shouldn't allow scripts? Or should we just add a note?

@annevk
Copy link
Member

annevk commented Feb 10, 2023

"These algorithms must not run script." is okay. We sometimes require things from specifications in that way. (It would be even better if we could assert it, but that doesn't seem possible.)

rakina added a commit to rakina/html that referenced this issue Feb 16, 2023
These steps will be run when a document regains full activity after restoring it from BFCache. This does not currently introduce any behavior changes within the HTML spec, but allows other specs to define the steps they will take when a document becomes fully active again, e.g. send updates to the renderer about the current Geolocation state, etc.

Fixes whatwg#8872.
rakina added a commit to rakina/html that referenced this issue Feb 16, 2023
These steps will be run when a document regains full activity after restoring it from BFCache. This does not currently introduce any behavior changes within the HTML spec, but allows other specs to define the steps they will take when a document becomes fully active again, e.g. send updates to the renderer about the current Geolocation state, etc.

Fixes whatwg#8872.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration Better coordination across standards needed
Development

No branches or pull requests

2 participants