[Project_owners] Getting Source Tab When Listening to http-on-modify-request

eric.jung at yahoo.com eric.jung at yahoo.com
Fri Mar 2 17:48:26 PST 2007


To clarify what I mean by this last statement, think of how client code instantiates XmlHttpRequest:

  var req = new XmlHttpRequest();

Even if we write our own nsIXmlHttpRequest implementation, I don't see how we can correlate instances of our implementation to a window/tab or an index, as you describe below. The best we could do is perhaps use XmlHttpRequest.caller to get the calling context's object. From there, we might be able to get to the window or tab. However, it's not clear to me whether or not XmlHttpRequest.caller is null when XmlHttpRequest is instantiated from the top-level window -- see the example at the bottom of http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Function:caller where the function returns "The function was called from the top!"


----- Original Message ----
From: "eric.jung at yahoo.com" <eric.jung at yahoo.com>
To: Mozdev Project Owners List <project_owners at mozdev.org>
Sent: Friday, March 2, 2007 6:10:46 PM
Subject: Re: [Project_owners] Getting Source Tab When Listening to http-on-modify-request

And how would you correlate the appropriate index for a given XmlHttpRequest?


----- Original Message ----
From: Adam Judson <adamsplugins at gmail.com>
To: Mozdev Project Owners List <project_owners at mozdev.org>
Sent: Friday, March 2, 2007 4:46:39 PM
Subject: Re: [Project_owners] Getting Source Tab When Listening to http-on-modify-request

The assumption here was that you (or rather Kyle) already had an array
of open tabs.  As a new tab is created, increment the index and
hardcode "magic_header=index" into the new XmlHttpRequest class for
that tab.

A

On 02/03/07, eric.jung at yahoo.com
 <eric.jung at yahoo.com> wrote:
>
> The question then becomes what to put in the header on in the custom
> nsIXMLHttpRequest implementation that uniquely identifies the window/tab on
> which the request originated. I thought I could use arguments.callee in the
> constructor of my XmlHttpRequest imlpementation to get to the window/tab,
> but that doesn't appear to be so. Remember that AJAX code creates the object
> simply with new XmlHttpRequest()... no arguments or any way I can see to get
> contextual information; e.g., the window/tab in which the object is created.
>
>
>
> ----- Original Message ----
> From: Adam Judson <adamsplugins at gmail.com>
> To: Mozdev Project Owners List <project_owners at mozdev.org>
> Sent: Friday, March 2, 2007 2:52:50 PM
> Subject: Re: [Project_owners] Getting Source Tab When Listening to
>
 http-on-modify-request
>
>
> Overwrite the XMLHttpRequest class in the the window with your own
> that delegates to the original, but adds an extra header with some
> magic number in it (jar number?).  Then parse and drop the header in
> your observer.
>
> I believe there are a few greasemonkey scripts that do similar things.
>
> Adam
>
> On 02/03/07, Kyle Wilgus <wigginz at gmail.com> wrote:
> > Here's what I have so far on the AJAX requests, I'm a bit worried that
> > there may not be an easy solution, and I'll have to get creative.
> > Hopefully this explanation makes sense.
> >
> > Basically in the case when the request it is a XMLHttpRequest (AJAX),
> > the interface requester (see my previous code in the thread) is an
> > instance of the XMLHttpRequest interface, and only supports the
> > following
 interfaces:
> >
> > nsIXMLHttpRequest, nsIInterfaceRequestor, nsIClassInfo,
> > nsIJSXMLHttpRequest, nsIDOMEventTarget, nsISupports
> >
> > >From here, if I cannot get an nsIDOMWindow instance from the interface
> > requester, I assume it's an XMLHttpRequest. I don't see any possible
> > way to get query an interface from this object that will give me
> > access to the source document or window. This is where I'm stuck now.
> >
> > I thought of pulling out the host name from the URI returned by the
> > XMLHttpRequest.name attribute and then cycling through all of the tabs
> > locations until I get a match. Only drawback with this solution is
> > that more than one tab may have have the same host so the first tab in
> > the array would always be picked. At the moment, it's at least better
> > to do this than not support AJAX at
 all.
> >
> > I'm struggling with finding another approach at the moment. I haven't
> > flushed out any code yet. I'm thinking about trying to find some event
> > that I can receive specifically for XMLHttpRequests that will give
> > access the DOM and then attach some meta data (tab Id) to the request
> > (header value for example) that I can pick up when I observe the
> > http-on-modify-request topic.
> >
> > I'll keep you updated on my progress.
> >
> > Kyle
> >
> >
> >
> > On 3/2/07, Arturo 'Buanzo' Busleiman <buanzo at buanzo.com.ar> wrote:
> > > Regarding AJAX, I'm currently testing that, too. Could you post any of
> > > your findings, Kyle?
> > > _______________________________________________
> > > Project_owners mailing list
> > > Project_owners at mozdev.org
> >
 > http://mozdev.org/mailman/listinfo/project_owners
> > >
> > _______________________________________________
> > Project_owners mailing list
> > Project_owners at mozdev.org
> > http://mozdev.org/mailman/listinfo/project_owners
> >
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> http://mozdev.org/mailman/listinfo/project_owners
>
>
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> http://mozdev.org/mailman/listinfo/project_owners
>
>
_______________________________________________
Project_owners mailing list
Project_owners at mozdev.org
http://mozdev.org/mailman/listinfo/project_owners





_______________________________________________
Project_owners mailing list
Project_owners at mozdev.org
http://mozdev.org/mailman/listinfo/project_owners




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mozdev.org/pipermail/project_owners/attachments/20070302/06bd53a1/attachment.html 


More information about the Project_owners mailing list