Closed Bug 564419 Opened 14 years ago Closed 8 years ago

HTTP request for manifest file (HTML5) is not associated with a DOM window.

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: Honza, Unassigned)

Details

(Whiteboard: [firebug-p2]) 

Currently Firebug doesn't display HTTP request that is made for a manifest file specified for the <html> element.

<html manifest="foo.manifest">

The problem is that Firebug displays only requests associated wit the current window.

Here is a snippet of code showing how Firebug gets the parent window:

var webProgress = getRequestWebProgress(request);
if (webProgress)
     return webProgress.DOMWindow;

function getRequestWebProgress(request)
{
    try {
        if (request && request.notificationCallbacks)
            return request.notificationCallbacks.getInterface(Ci.nsIWebProgress);
    }
    catch (exc) { }

    try {
        if (request && request.loadGroup && request.loadGroup.groupObserver)
            return request.loadGroup.groupObserver.QueryInterface(Ci.nsIWebProgress);
    }
    catch (exc) {}
    return null;
};

Is it possible to fix this, so Firebug shows even requests for manifest files?

Honza
Whiteboard: [firebug-p2]
You should probably use the loadGroup's notification callbacks instead of its group observer to get the webprogress.

Are you saying that the manifest load does not have a load group associated with it?
It indeed does not.  The load is started in nsOfflineCacheUpdateItem::OpenChannel as far as I can see, with a null loadgroup.

I should note that Firebug should be using nsILoadContext instead of the nsIWebProgress mess it's using, since it will NOT get nsIWebProgress for all sorts of loads that are in fact associated with a window (e.g. SVG external resources).  But it seems to me like offline cache updates should be placed in the right loadgroup too... or at least provide and nsILoadContext.
(In reply to comment #1)
> You should probably use the loadGroup's notification callbacks instead of its
> group observer to get the webprogress.
I tested this, but 
request.loadGroup.notificationCallbacks.QueryInterface(Ci.nsIWebProgress)
returns the following exception for XHRs:
EXCEPTION Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]

> Are you saying that the manifest load does not have a load group associated
> with it?
Yes

(In reply to comment #2)
> I should note that Firebug should be using nsILoadContext instead
Done

Honza
> request.loadGroup.notificationCallbacks.QueryInterface(Ci.nsIWebProgress)

You should be using GetInterface, not QueryInterface.
(In reply to comment #4)
> > request.loadGroup.notificationCallbacks.QueryInterface(Ci.nsIWebProgress)
> 
> You should be using GetInterface, not QueryInterface.
Ah, now it works, thanks!
Honza
Just to sum: goal of this bug is to associate the manifest and its items channels with the correct loadgroup/window?
(In reply to comment #6)
> Just to sum: goal of this bug is to associate the manifest and its items
> channels with the correct loadgroup/window?
Yes. As soon as the request knows its parent window, Firebug can display in the list of requests made by that window. This is the philosophy of Firebug: be tied with a specific (top) window/page.

Honza
Hold on.  Does the channel need to be in the "right" loadgroup?  Or does it just need an nsILoadContext that hands out the "right" window?  I'd think the latter would provide the information that Firebug wants without making us stop the manifest loads on Stop() and such. Assuming that's desirable behavior, of course.
(In reply to comment #8)
> Hold on.  Does the channel need to be in the "right" loadgroup?  Or does it
> just need an nsILoadContext that hands out the "right" window?  

Problem is that the update can be actually bound to several windows/loadgroups including iframes.  If we really want a window then it should probably be bound to the first document's window that requested the update.

> I'd think the
> latter would provide the information that Firebug wants without making us stop
> the manifest loads on Stop() and such. Assuming that's desirable behavior, of
> course.

It is desirable behavior.  There is nothing said in the spec that the update should be canceled by any user interaction as it is happening in the background, however we have implemented a capability to stop the update on XPCOM_SHUTDOWN notification.

Another question: how is this gonna work in the e10s scenario?
> it should probably be bound to the first document's window that requested the
> update.

Right.  This is a situation where the consumer's (Firebug's) mental model is just out of touch with reality; we can't give a "correct" answer that their model can handle.

> Another question: how is this gonna work in the e10s scenario?

Good question.  We're doing _something_ with nsILoadContext, but not clear what yet.  It might start handing out the tab the load is in or something.
(In reply to comment #10)
> > it should probably be bound to the first document's window that requested the
> > update.
> Right.  This is a situation where the consumer's (Firebug's) mental model is
> just out of touch with reality; we can't give a "correct" answer that their
> model can handle.
Yes. I think in most cases, users will test with just one page opened so, Firebug could provide expected results for them.

Honza
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.