A co-worker of mine suggested comparing browser objects for equality, which at first glance seems to work.
In my onStateChange() method, I save a reference to this.context.browser in the request object. Then, in my processRequests() method, I compare that browser object with context.browser (context being the argument passed into loadedContext ()). It seems that the browser objects are indeed equal (===) when the request was created by the current tab, and not equal otherwise. Does this sound reasonable? Are browser objects long-lived, and one- per-tab? If there has been a lot of thought on this topic already, I'm guessing I'm not coming across anything new, and there may be something wrong with my logic :) Ross On Jan 8, 5:29 pm, John J Barton <[email protected]> wrote: > You are correct: the context maps to the page and when the page is > destroyed so goes the context. > > The problem here is that the visual relationship between the new page > and the old one, created by the way Firefox usually shows the new page > in the same tab as the old one, has no basis in FF code. There is no > simple test to connect the old and new pages. The behavior is, as far > as I know, simply accidentally designed. Back in the day we did not > have tabs: new pages had to replace old pages. > > We speculate that analysis of net traffic would allow us to correlate > pages, identifying a connection between old and new pages. We even > have the technology to study and implement this (from the progress > listeners used in net panel). So if any one wants to take a shot at > this don't be shy! > > jjb > > On Jan 8, 7:44 am, ross <[email protected]> wrote: > > > Hi John, > > > Thanks for the quick reply. In fact, moving my list into the context > > object was the first thing I tried. However, it doesn't seem to work, > > and I think I'm running into the fact that the context is not > > persistent across page loads. > > > Below is a snippet of the log (dump() commands in my code) that > > illustrates the problem. They are in the exact order that they appear > > in the log (I've added lines describing the actions causing the events > > to happen): > > > #1: load the originating page > > initContext (uid=9268) > > showContext (uid=9268) > > loadedContext (uid=9268) > > > #2: click the link that has an attached handler, firing off an image > > request > > onStateChange: adding request (key=babb5f934417705886b92a6ebe63286e) > > to list (uid=9268) > > > #3: browser loads link URL > > destroyContext (uid=9268) > > initContext (uid=24269) > > showContext (uid=24269) > > loadedContext (uid=24269) > > processRequests: processing 0 requests (uid=24269) > > > onStateChange() is an overridden method on an nsIWebProgressListener, > > and it writes requests to an array attached to the context. > > processRequests() is a method on the module that gets called via > > loadedContext(), gets passed the context, and loops over the array to > > dump them to the panel. > > > As you can see, the old context is destroyed before the new one is in > > place, so processRequests() gets the new context with an empty array. > > This is exactly as I would expect, given the fact that the context > > doesn't persist. > > > I'm not sure now if my goal is even possible. Do you have any other > > thoughts or suggestions? > > > Thanks again, > > Ross > > > On Jan 7, 5:42 pm, John J Barton <[email protected]> wrote: > > > > Based on your example, 'context' is exactly what you want. In your > > > example 'context' for the page is available before step 1 and remains > > > through step 3. > > > > You should set yourself a workplace in context like, > > > context.<yourExtensionName>.<yourObjects>, > > > > The context object is not persistent across page loads. The two inter- > > > related key reasons are 1) that would cause memory to fill up with old > > > context objects, 2) there is no way to correlate two web pages in > > > Firefox. Specifically there is not relation between a page and a tab, > > > in fact in FF3.2 you will be able to move page between windows. > > > > jjb > > > > On Jan 7, 7:18 am, ross <[email protected]> wrote: > > > > > Hi, > > > > > I'm working on a Firebug extension which watches for certain sorts of > > > > outbound requests and does things with them (mainly parsing and > > > > displaying details in a panel). > > > > > I've run into a similar problem that's been reported here several > > > > times -- basically, I need a persistent storage area, per Firefox tab, > > > > where I can store a little data (short term). The use case is like > > > > this: > > > > > 1) Load a page > > > > 2) Click a link; that link has a javascript handler which generates an > > > > image request, before the browser follows the link > > > > 3) Browser follows the link and loads the new page > > > > > I need to capture the details of that image request described in #2, > > > > and display it in the panel after #3. > > > > > Currently, I do this by storing the requests in an array on my module > > > > (extended from Firebug.Module), then in loadedContext() I dump the > > > > contents of the list to the panel. However, it becomes a problem when > > > > a new tab gets opened (or if you have multiple tabs open). Since that > > > > list on the module is "global" (e.g. not tied to a particular tab), > > > > the first time any tab's loadedContext() runs, it will process all the > > > > entries. > > > > > So, my question is if there's any place to store this information, > > > > persistent across page loads, that's specific to the current tab. > > > > Failing that, do you have any thoughts on a different approach that > > > > would achieve the same result? > > > > > Thanks in advance, > > > > Ross --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/firebug?hl=en -~----------~----~----~----~------~----~------~--~---
