3

Is it possible, from within the "http-on-modify-request" event, to identify which requests are coming from a PageWorker object, as opposed to those coming from visible tabs/windows?

Note: Because of redirects and subresources, the URL here is NOT the same URL as the pageWorkers contentURL property.

require("sdk/system/events").on("http-on-modify-request", function(e) {

    var httpChannel = e.subject.QueryInterface(Ci.nsIHttpChannel), 
        url = httpChannel.URI.spec, 
        origUrl = httpChannel.originalURI.spec;

    ...         
});
nmaier
  • 32,336
  • 5
  • 63
  • 78
rednoyz
  • 1,318
  • 10
  • 24

1 Answers1

4

I don't know of any way to actually distinguish page-worker requests from "regular" ones.

Current, page workers are implemented like this:

  • The SDK essentially creates an <iframe> in the hiddenWindow (technically, in sdk/addon/window, which creates a hidden window in the hiddenWindow). The hiddenWindow in mozilla applications is more or less an always-present top-level XUL or HTML window that is simply hidden.
  • The worker page is loaded into that iframe.
  • The page-worker will then operate on the DOM on that iframe.

It is possible to identify requests originating from the hidden window and the document within the hidden window.

But identifying if the request or associated document belongs to a page-worker, let alone which page-worker instance, doesn't seem possible, judging from the code. The SDK itself could map the document associated with a request back to a page-worker, as it keeps some WeakMaps around to do so, but that is internal stuff you cannot access.

You only can say that a request is not coming from a page-worker when it is not coming from the hiddenWindow.

Also, keep in mind that there are tons of requests originating neither from a tab nor page-worker: Other (XUL) windows, add-ons, js modules and components, etc...

If it a page-worker created by your add-on that you're interested in: The contentURL property should reflect the final URI once the page is loaded.

Community
  • 1
  • 1
nmaier
  • 32,336
  • 5
  • 63
  • 78
  • This seems a quite common use-case, where you launch a PageWorker and then want to monitor what its doing with event listeners (e.g., for 'http-on-modify-request'). Perhaps this is worth submitting as an enhancement ticket? – rednoyz Jan 03 '14 at 07:11
  • The hack I'm currently using is to modify the source of page-worker.js and make the view property an accessible field of the Page object. After constructing a Page p, I can give it an attribute: `p.view.setAttribute("MY-TAG", "xxx");` which I can then check in the listener methods, by accessing the request's chromeEventHandler. This seems to do what I want, but its just a temporary hack... – rednoyz Jan 03 '14 at 07:15
  • Lastly, a question: what do you mean by "the final URI"? When listening to 'http-on-modify-request' or 'http-on-examine-response' events, the contentURL of the PageWorker is the FIRST request I see, followed by many others (redirects, sub-resources, etc). I'm not sure, actually, how to tell when the page has fully loaded... – rednoyz Jan 03 '14 at 07:33
  • `http-on-modify-request` is not an event listener FWIW. "final URI" as in the URI the page/frame gets to after it is done loading (after any redirects and so on). Also, I don't really get what you're intending to solve here... It sounds more and more to me that you might be trying to use the wrong tool to solve your problem... – nmaier Jan 03 '14 at 10:41
  • Its pretty simple actually. I want to visit pages with the PageWorker, and then potentially cancel some of the subrequests that result (images, sound, redirects, etc.) – rednoyz Jan 03 '14 at 14:58