I'm receiving onStateChange and onStatusChange events via my
nsIWebProgressListener iface implemenation in JS.
The onStatusChange events recevied from the network threads are all
mixed together and I'm trying to find a way to link these events back to
their associated parent document/subdocument or parent request so that I
can maintain a parent-child structure internally for all HTTP requests.
Let's say a URL entered into Firefox's location bar results in a page
being loaded containing 2 subdocument frames. I would like to separate
out the associated the onStatusChange events for each document like so:
(main document)
401 Authorization Required
302 Found (redirect)
302 Found (redirect)
200 OK (initial document load)
200 OK (.css file)
200 OK (.js file)
200 OK (.gif image)
(frame subdocument 1)
302 Found (redirect)
200 OK (subdocument load)
200 OK (.css file)
200 OK (.js file)
200 OK (.gif image)
(frame subdocument 2)
302 Found (redirect)
200 OK (subdocument load)
200 OK (.css file)
200 OK (.js file)
200 OK (.gif image)
I'm mainly trying to associate http events with documents (or parent
requests), so I'm not as concerned about maintaining a relationship
between the subdoc frames and their initial parent doc, but having that
relationship might be nice too.
To find these relationships, I can't use straight URL comparisons (e.g.,
referrer), since the same URL might be loaded into both subframes, or
may have been recently referenced in a previous document load. I really
need some kind of unique JS object reference that I can compare with
reliably.
So I've been trying to use the webProgress and request params passed
into the onStatusChange to determine this document relationship but
haven't had much luck. The loadGroup property of the request does not
appear to offer the solution. I've also looked into using the
nsIDocumentLoader and the docloaderservice, but the nsIDocumentLoader
iface seems to be depreciated in favor of nsIWebProgres, and I'm not
sure if using the docloaderservice is the answer. Any help would be
appreciated.
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
