273760 - Solve the SetLoadCookie issue (specify nsIURILoader context behavior)

Status: NEW

(Core :: DOM: Navigation, task)

Description

[Boris Zbarsky [:bzbarsky]]

This is spun off bug 272471.

The issue with SetLoadCookie raised in that bug is only an issue for callers
that call nsIURILoader and pass something other than a docshell as the context.
 So I think the right solution is to clearly define what interfaces the context
should support and what should happen when it doesn't support them.

At the moment, the only such caller in the tree that uses the loadcookie is
nsURLFetcher.cpp.  It watches the progress notifications and uses them to call
its own OnStopRequest if it gets a OnStateChange() with an error status.  Given
that it's also the nsIContentListener for the channel, this seems unnecessary...

In any case, the loadcookie currently provides three things: an nsIWebProgress,
an nsIDocumentLoader, and an nsILoadGroup (from the document loader).

So what we need to decide is how and whether non-docshell callers should come up
with a loadgroup and a webprogress.

There are two basic options:

1)  If the caller's context does not GetInterface an nsIWebProgress, create an
    nsDocLoader and set it as the caller's loadcookie.  Similar for
    nsILoadGroup.
2)  Make it the caller's responsibility to manage nsIWebProgress/nsILoadGroup
    issues (in which case we should probably expose a way to create reasonable
    nsIWebProgress instances on the caller side).

Thoughts?

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

This has nothing to do with http cookies; it's totally a DOM thing.