Background: We have a problem right now where the thing representing a
"collection of loads" (a loadgroup) is attached to a docshell, not an
individual document. This causes issues like loads started from unload
events being blamed on the new page and whatnot, though it's possible
that loadinfo will help with some of those.
Proposal: We already have a concept of "document loadgroup"; right now
it's just the one for the docshell the document is in. I'm proposing
that we make it a separate loadgroup, whose parent is the docshell
loadgroup. That is, as you navigate a docshell, each document will get
its own loadgroup, all of these will be contained in the docshell's
loadgroup, and subresources loaded for each document will be placed in
the _document_'s loadgroup.
There is one conceptual problem here, which is where to put the document
request itself. I think there are two options:
1) Put it in the docshell loadgroup. This is probably the simplest
thing to do, but it does have one significant drawback: it means onload
handling has to either stay in the docshell loadgroup or needs hacks to
keep track of the document request if it's moved to the document
loadgroup, since the document request itself is not in the document
loadgroup.
2) Create the loadgroup when we're starting the document request. The
channel would just keep it alive while it's active; if we end up
creating a document, the document can grab it from the channel and store
it. This might just work out OK. It will require a bit more up-front
work to handle onload correctly.
In both cases, we will likely need to think a bit about the various
notification-firing docloader does (web progress listeners, basically)
and how to keep that working reasonably.
I do think we want to keep the docshell-level loadgroup, so we can do
things like cancel everything for all documents when the docshell is
torn down. Not that there should be much in the way of loads for
non-active documents, but I'm not _that_ confident in this.
I believe this setup can be implemented somewhat incrementally, in that
we can land an initial change and then start simplifying various stuff
separately...
Thoughts? Any obvious problems with this plan?
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform