"Tab Local" storage?

[ross]

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

[John J Barton]

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

[ross]

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

[John J Barton]

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

[ross]

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

[John J Barton]

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

[ross]

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

[John J Barton]

On Jan 14, 2:12 am, ross <simps...@gmail.com> wrote:
...

> 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.

Of course you know my answer Ross: don't hold any references to
contexts and browsers in your module ;-).

jjb