Bug 1342484 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I think there are two relevant mechanisms here.
1. The load group. I think fetch requests go in the loadgroup of the page it's created from, so when that gets unloaded, fetch requests would get cancelled. I think it is definitely possible to have a different loadgroup for keepalive requests, so we don't cancel them on unload.
2. The channel actors. PHttpChannel is managed by PNecko which is managed by PContent. If the user closes the tab and that destroys PContent, the channels should also get destroyed. Though I'm not 100% sure that is what we do right now.

A keepalive channel manager would indeed be necessary to enforce the limits and make sure we properly clean up after the channels.
I think there are two relevant mechanisms here.
1. The load group. I think fetch requests go in the loadgroup of the page it's created from, so when that gets unloaded, fetch requests would get cancelled. I think it is definitely possible to have a different loadgroup for keepalive requests, so we don't cancel them on unload.
2. The channel actors. PHttpChannel is managed by PNecko which is managed by PContent. If the user closes the tab and that destroys PContent, the channels should also get destroyed. ~~Though I'm not 100% sure that is what we do right now.~~ Right now, the signal to close the channel when the tab dies is sent from [HttpChannelChild::ActorDestroy](https://searchfox.org/mozilla-central/rev/aec3a901e6f6b3041b5ec457c9111a042cef1fb1/netwerk/protocol/http/HttpChannelChild.cpp#3029) so it should be easy to exclude keepalive requests.

A keepalive channel manager would indeed be necessary to enforce the limits and make sure we properly clean up after the channels.

Back to Bug 1342484 Comment 13