I've solved my problem for the time being, with a combination of checking equality of context browser, then throwing away "old" requests in initContext() -- that is, looping over the persistent list of requests in initContext() and throwing out any that are more than X seconds old. The idea is that any requests I want to keep are very recent (since these requests likely triggered the page load), and any that have been around for more than a second or two should be ignored.
This may not be exactly right, but all of my test cases now pass (and I've spent too much time on it already). One last question -- I'm a bit concerned about hanging on to references to contexts and browsers in my module, and any memory leaking that may cause. I was curious what sort of tools or practices other Firebug developers use to ensure they are not leaking anything. Thanks, Ross On Jan 8, 6:42 pm, John J Barton <[email protected]> wrote: > The equally of the context.browser objects should indeed tell you that > the context is in the same tab. But what does that mean? > > For example, type some thing in the google search box and hit enter. > Your extension will say the new page and old page are in the same > browser. So what? > > Unfortunately web apps can reuse the same tab or use different tabs; > other web actions can reuse your web app tab. I think you have to > track requests and correlate to windows (not tabs). > > jjb > > On Jan 8, 9:16 am, ross <[email protected]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
