Allow certain tasks to run even when document is not fully active?

[rakina]

Currently Chrome's implementation of BFCache allows certain tasks to run even when its document is not fully active, as long as it doesn't expose any web-observable behaviors (e.g. events). In particular, we allow in-flight network requests to continue loading, but not new network requests.

However, I think currently fetch tasks are posted with an associated document, which aren't runnable if the document is not fully active (CMIIW!)

I wonder if it's possible to change the spec to allow Chrome's behavior here? Or maybe even just a note that it's possible that some user agents don't 100% follow the "runnable" rule?

cc @domenic @fergal

[domenic]

When I looked into something similar for https://wicg.github.io/page-lifecycle/, we found that none of the tasks that Chrome runs while a document is frozen exist in the spec; they all just happen to use similar "task runner" infrastructure.

I suspect something similar is the case here. I.e., there is no observable difference between the spec's behavior (of running no tasks) and Chrome's behavior (of running some tasks, but only if they don't do anything observable). In that case there wouldn't be anything to change in the spec.

Are there cases you have in mind where there are specific tasks that exist in the spec, but which Chrome runs in non-fully active documents? Like, could you point to the "queue a task" line in the spec?

[rakina]

Thanks! The tasks that I'm concerned about are all the various fetch tasks (example), but maybe as you say since it's not really observable we don't need to update the spec. I guess it's not really 100% not observable in that the server that sends the resource would notice that the page still continues the fetch, but that's probably out of scope of the spec?

[domenic]

Hmm, that's still sorta in scope. I'd be curious about @annevk's take, as he was changing that area of the spec recently.

Interestingly, other fetch tasks are completely not observable, e.g. the ones to process end of body. It's just the chunk-reading one that you linked to, I think, which the server would observe.

[annevk]

So for downloading (step 19 of https://fetch.spec.whatwg.org/#concept-http-network-fetch) I think we are okay. That currently does not but should queue a task to enqueue the ArrayBuffer, but it queues it after obtaining the bytes. I.e., network retrieval would continue, but task side effects would happen once the document becomes active again. (Unless network tasks are discarded? It would be good to have tests around this.)

For uploading we could make it work for non-actual stream cases (which is currently all of them; what is the plan for upload streams? cc @yutakahirano @yoichio) in a similar manner I suspect, but it would require having a more abstract stream concept. I'm having a hard time recalling if we have notes around some of the JavaScript streams stuff being hand-wavy (especially when in parallel), but that might suffice here (except it would not for upload streams I think).

Hope that helps.

[rakina]

Thank you!
I talked with @fergald about this earlier today and I think Chrome does not support continuing the upload when a page is in bfcache (at least, intentionally - we're gonna add tests to make sure). Then I think we're good here!