[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 21:59:31 PST 2007

>>I've been able to uniquely identify tabs by the value returned by "tab.linkedPanel" which, in my tests, has been unique and sticky to a given tab. I haven't seen much detailed documentation about what the behavior of this value is, but it does seem to be unique and work as I expect. I'm using this value as a key in a hash map to point to the jar reference associated with a given tab.<<

Kyle, think this through. I tried to get this across in my replies to Adam's posts, but I'm not being successful. Just because you can uniquely identify tabs and store them in some global variable, doesn't help. When you process an XmlHttpRequest, how are you going to associate that request with one of your uniquely identified tabs? There is no information in the request to make this association. Even if you register your own nsIXMLHttpRequest implementation (delegating methods to the mozilla implementation), where does that get you? You still don't have a means to store information which correlates to a window/tab because client code instantiates XmlHttpRequest with a zero-arg constructor; i.e., there is no information from the client relating this request to a window.

The only possibility I can think of to associate a request with a window/tab is, as I wrote, to use XmlHttpRequest.caller in the nsIXMLHttpRequest proxy. If caller allows you to get to the window/tab (e.g., XmlHttpRequest.caller.parentNode.parentNode?), you *still* have no use for unique tab identifiers or the "magic headers" which Adam describes.

Please keep me informed on your work as I need to do the exact same thing for one of my extensions.

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

More information about the Project_owners mailing list