Help needed on extending firebug!

[Manoj]

I followed the excellent introduction to getting started with firebug
extensions (Part I - IV) written by Honza. As you may recall my
interest is to develop a utility which collates the network,
javascript and DOM event activity for a page and ultimately produce a
usable display.

To achieve this, i'm trying to figure out how my extension will be
able to listen in on the following:

1. JavaScript function calls/returns
2. Network requests/responses
3. DOM events

Is there a writeup on *how* such existing Firebug functionality can be
re-used?
Any pointers would be appreciated.

In the meantime, I'm overriding the module and panel methods one by
one in an effort to understand when they are being called and the most
appropriate way I can attach / detach my listeners into Firebug.

[John J Barton]

On Nov 24, 11:48 am, Manoj <kawi...@gmail.com> wrote:
> I followed the excellent introduction to getting started with firebug
> extensions (Part I - IV) written by Honza. As you may recall my
> interest is to develop a utility which collates the network,
> javascript and DOM event activity for a page and ultimately produce a
> usable display.
>
> To achieve this, i'm trying to figure out how my extension will be
> able to listen in on the following:
>
> 1. JavaScript function calls/returns
> 2. Network requests/responses
> 3. DOM events

Generally you'll listen to Firefox for these, just like Firebug does.
Firebug events are at a higher level, more like "debugger stopped"
than "function call".

The function call and return will require addition to the firebug-
service (jsd interface). Its not difficult as long as we can figure
out how to avoid colliding with single stepping.

For network and DOM we need more information, their are a lot of them.

>
> Is there a writeup on *how* such existing Firebug functionality can be
> re-used?
> Any pointers would be appreciated.
>
> In the meantime, I'm overriding the module and panel methods one by
> one in an effort to understand when they are being called and the most
> appropriate way I can attach / detach my listeners into Firebug.

A good place to start is the Firebug Tracing Console, (or Chromebug if
you are very brave).
Set Options DISPATCH to or PANELS one at a time and operate the UI.

[Manoj]

On Nov 24, 5:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> On Nov 24, 11:48 am, Manoj <kawi...@gmail.com> wrote:
>
> > I followed the excellent introduction to getting started with firebug
> > extensions (Part I - IV) written by Honza. As you may recall my
> > interest is to develop a utility which collates the network,
> > javascript and DOM event activity for a page and ultimately produce a
> > usable display.
>
> > To achieve this, i'm trying to figure out how my extension will be
> > able to listen in on the following:
>
> > 1. JavaScript function calls/returns
> > 2. Network requests/responses
> > 3. DOM events
>
> Generally you'll listen to Firefox for these, just like Firebug does.
> Firebug events are at a higher level, more like "debugger stopped"
> than "function call".
>
> The function call and return will require addition to the firebug-
> service (jsd interface). Its not difficult as long as we can figure
> out how to avoid colliding with single stepping.

Hmm, I feared that this was going to be the case. Since my listeners
will be 100% read-only I would hope there won't be any trouble with
existing functionality.

> For network and DOM we need more information, their are a lot of them.

For network my extension will need to observe:
1. the http requests made by the browser when the document loads (html
+css+script+images+objects etc)
2. any subsequent XHR calls.
3. the server responses to the above

I'm only interested in the status and headers not the actual content
itself.


For DOM:
I'm not 100% certain which events my extension will need to listen to
but it will be a significant portion.
Basically, anything that reflects user action on the page would have
to be a part of it. Plus, any event that indicates modification of the
DOM tree itself (for re-attaching the listeners)

Again, all this is read-only, I don't anticipate doing anything to
disrupt/modify the event flow.

> > In the meantime, I'm overriding the module and panel methods one by
> > one in an effort to understand when they are being called and the most
> > appropriate way I can attach / detach my listeners into Firebug.
>
> A good place to start is the Firebug Tracing Console, (or Chromebug if
> you are very brave).
> Set Options DISPATCH to or PANELS one at a time and operate the UI.

I have a better understanding of the module and panel operations than
I did at the beginning of the day so I'm encouraged :-)

Tomorrow, I will do what you suggested and re-affirm things. Is there
a FF option to redirect the console output to a file btw? Actually,
having them both would be ideal.

Thanks,
Manoj

[John J Barton]

On Nov 24, 5:36 pm, Manoj <kawi...@gmail.com> wrote:
> On Nov 24, 5:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:

...

>
> > The function call and return will require addition to the firebug-
> > service (jsd interface). Its not difficult as long as we can figure
> > out how to avoid colliding with single stepping.
>
> Hmm, I feared that this was going to be the case. Since my listeners
> will be 100% read-only I would hope there won't be any trouble with
> existing functionality.

The jsd layer only allows one listener, so read-only or not, we need
to deal with it.

>
...

> > A good place to start is the Firebug Tracing Console, (or Chromebug if
> > you are very brave).
> > Set Options DISPATCH to or PANELS one at a time and operate the UI.
>
> I have a better understanding of the module and panel operations than
> I did at the beginning of the day so I'm encouraged :-)
>
> Tomorrow, I will do what you suggested and re-affirm things. Is there
> a FF option to redirect the console output to a file btw? Actually,
> having them both would be ideal.

Firebug console? Firebug tracing console? OS console? Both of which?

I guess you mean "window.dump()"? You can use normal OS redirection on
the command line or open a file an write into it.

You can write to the FBTrace console and/or window.dump() from your
code.

jjb

[Jan Odvarko]

> For network my extension will need to observe:
> 1. the http requests made by the browser when the document loads (html
> +css+script+images+objects etc)
> 2. any subsequent XHR calls.
> 3. the server responses to the above

I think you could utilize "@joehewitt.com/firebug-http-observer;1"
component. This XPCOM notifies listeners about http-on-modify-request
(request started) and http-on-modify-request (response received) (all
headers info accessible).

Here is an example:

const httpObserver = CCSV("@joehewitt.com/firebug-http-observer;1",
"nsIObserverService");

Firebug.MonitorModel.HttpMonitor = extend(Firebug.Module,
{
initializeUI: function(detachArgs)
{
// Register HTTP observer
httpObserver.addObserver(HttpObserver, "firebug-http-event",
false);
},

shutdown: function()
{
httpObserver.removeObserver(HttpObserver, "firebug-http-
event");
}
});


The "HttpObserver" should implement nsIObserver interface, where
observe method could be something like:

observe: function(subject, topic, data)
{
try
{
var request = subject.QueryInterface(Ci.nsIHttpChannel);
if (topic == "http-on-modify-request") {
// Request start
} else if (topic == "http-on-examine-response") {
// Response received
}
}
catch (err)
{
if (FBTrace.DBG_ERRORS)
FBTrace.sysout("observe EXCEPTION", err);
}
},

Honza

[Manoj]

Your suggestion works like a charm.

Is it appropriate to use context.uid as the key to associate all the
data (network/DOM/JS).
In that case, how do I map the initial request (root document) into
the appropriate firebug context. This is because, the first time, I
try to get the context in observe() using:

var win = getWindowForRequest(subject);
var context = TabWatcher.getContextByWindow(win);

starting with about:blank, the first navigation results in context
being null.

Subsequent navigations, return the previous context (the one about to
be destroyed.) The framework calls initContext() after the initial
request.

Thanks,
Manoj

[John J Barton]

On Nov 25, 5:11 pm, Manoj <kawi...@gmail.com> wrote:
> Your suggestion works like a charm.
>
> Is it appropriate to use context.uid as the key to associate all the
> data (network/DOM/JS).

No, context.uid is just a sanity check for when I'm confused about
contexts. For example the contextUID appears in the panelNode in
chromebug.

> In that case, how do I map the initial request (root document) into
> the appropriate firebug context. This is because, the first time, I
> try to get the context in observe() using:
>
>       var win = getWindowForRequest(subject);
>       var context = TabWatcher.getContextByWindow(win);
>
> starting with about:blank, the first navigation results in context
> being null.

I'm not sure what you mean by starting with about:blank.
Do you see the initContent in the trace? If you issue
FBTrace.sysout(..);
in your code and see trace option DISPATCH and WINDOWS you should see
your event relative to the context creations.

Or win is not what you think...
FBTrace.sysout("your text", win);
to look at it.

>
> Subsequent navigations, return the previous context (the one about to
> be destroyed.)  The framework calls initContext() after the initial
> request.

Sorry you lost me here.

[Manoj]

On Nov 24, 5:46 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> On Nov 24, 5:36 pm, Manoj <kawi...@gmail.com> wrote:
>
> > On Nov 24, 5:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> ...
>
> > > The function call and return will require addition to the firebug-
> > > service (jsd interface). Its not difficult as long as we can figure
> > > out how to avoid colliding with single stepping.
>
> > Hmm, I feared that this was going to be the case. Since my listeners
> > will be 100% read-only I would hope there won't be any trouble with
> > existing functionality.
>
> The jsd layer only allows one listener, so read-only or not, we need
> to deal with it.

How are you using the onCall() callback currently?
Will it be safe to chain it to other listener(s)?

> ...
> > > A good place to start is the Firebug Tracing Console, (or Chromebug if
> > > you are very brave).
> > > Set Options DISPATCH to or PANELS one at a time and operate the UI.
>
> > I have a better understanding of the module and panel operations than
> > I did at the beginning of the day so I'm encouraged :-)
>
> > Tomorrow, I will do what you suggested and re-affirm things. Is there
> > a FF option to redirect the console output to a file btw? Actually,
> > having them both would be ideal.
>
> Firebug console? Firebug tracing console? OS console? Both of which?

The firebug tracing console. for e.g. all the messages from
FBTrace.sysout() etc. that appear as "FTS0: ..."
I figured it out, initially my command line was:

"C:\Program Files\Mozilla Firefox\firefox.exe" -console -no-remote -P
dev > log.txt

which results in log.txt being created but nothing goes there.

After removing the "-console" option the redirection to the log file
works. Any FF option to specify both console and output file?

Thanks,
Manoj

[John J Barton]

On Nov 25, 5:43 pm, Manoj <kawi...@gmail.com> wrote:

>
> How are you using the onCall() callback currently?
> Will it be safe to chain it to other listener(s)?
...

Well this is supposed to support monitoring calls, but I've never seen
it in action.

From what I can tell, the result should be these calls for monitored
methods:
frame = getStackFrame(frame, context);
Firebug.Console.log(frame, context);
which is close to what you need for raw input.

Seems like we should move that code to Firebug.console, make it a
debug listener, and dispatch "onCall" with [context, frame].

>
> > Firebug console? Firebug tracing console? OS console? Both of which?
>
> The firebug tracing console. for e.g. all the messages from
> FBTrace.sysout() etc. that appear as "FTS0: ..."
> I figured it out, initially my command line was:
>
> "C:\Program Files\Mozilla Firefox\firefox.exe" -console -no-remote -P
> dev  > log.txt
>
> which results in log.txt being created but nothing goes there.
>
> After removing the "-console" option the redirection to the log file
> works. Any FF option to specify both console and output file?

None that I know of, but FTS0 means you did not succeed in opening the
Firebug tracing console. You probably want Firebug Menu > Options >
Always Open Firebug Tracing.

>
> Thanks,
> Manoj

[Manoj]

On Nov 25, 5:36 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> On Nov 25, 5:11 pm, Manoj <kawi...@gmail.com> wrote:
>
> > Your suggestion works like a charm.
>
> > Is it appropriate to use context.uid as the key to associate all the
> > data (network/DOM/JS).
>
> No, context.uid is just a sanity check for when I'm confused about
> contexts. For example the contextUID appears in the panelNode in
> chromebug.
>
> > In that case, how do I map the initial request (root document) into
> > the appropriate firebug context. This is because, the first time, I
> > try to get the context in observe() using:
>
> >       var win = getWindowForRequest(subject);
> >       var context = TabWatcher.getContextByWindow(win);
>
> > starting with about:blank, the first navigation results in context
> > being null.
>
> I'm not sure what you mean by starting with about:blank.
> Do you see the initContent in the trace? If you issue
> FBTrace.sysout(..);

My development profile has the start page option set as "Show a blank
page" (Tools->Options->Main)
When FF starts here is the trace:

FTS0: Registered: object Firebug.myModule
FTS0: Registered: function myPanel() {
}
FTS0: INSIDE myModule.initialize()
FTS0: INSIDE myModule.initializeUI()

No context is initialized.
Then if I initiate navigation to a URL (test_1.html for e.g.)

FTS0: onModifyRequest() *** NO CONTEXT *** context=undefined
uri=http://.../test_1.html
FTS0: INSIDE myModule.initContext() context=(39138) uri=http://.../
test_1.html persistedState = null
FTS0: INSIDE myModule.watchWindow() context=(39138)
FTS0: INSIDE myModule.loadedContext() context=(39138)
FTS0: INSIDE myModule.showContext() context=(39138)

Then if I initiate navigation to another URL (test_2.html for e.g.)

FTS0: onModifyRequest() context=(39138) uri=http://.../test_2.html
FTS0: INSIDE myModule.unwatchWindow() context=(39138)
FTS0: INSIDE myModule.destroyContext() context=(39138)
FTS0: INSIDE myModule.initContext() context=(47689) uri=http://.../
test_2.html persistedState = null
FTS0: INSIDE myModule.watchWindow() context=(47689)
FTS0: INSIDE myModule.loadedContext() context=(47689)
FTS0: INSIDE myModule.showContext() context=(47689)


Hope this clarifies rather than confuses!
Basically, the context creation is happening after the initial
request. However, since I cannot use the context.uid as a "key" it may
not be significant.

What else can I use to group up all the data I'm gathering and
associate it with a particular browsing tab (and therefore, by
extension, a FB panel)?

Thanks,
Manoj

[John J Barton]

On Nov 25, 6:08 pm, Manoj <kawi...@gmail.com> wrote:
>
> What else can I use to group up all the data I'm gathering and
> associate it with a particular browsing tab (and therefore, by
> extension, a FB panel)?

Yea, the context is exactly the gathering spot. However the data
comes in before we know what window object Firefox is using. And the
context is a side-table for the window (one to one).

So we have growing list of pre-groupings. This is a bug: what index do
we use to insure that all of the data is bound together? We really
need Firefox to fix this by giving an explicit Window creation event.

In the meantime Honza will tell you how to use his pre-context context
I hope...

jjb

[Jan Odvarko]

> Subsequent navigations, return the previous context (the one about to
> be destroyed.) The framework calls initContext() after the initial
> request.

Yes, this very confusing piece in Firebug. Unfortunately I don't
knowhow to improve that. I have tried that the other day, but gave up,
we need more support from Firefox here:
I think following bugs are directly related:
https://bugzilla.mozilla.org/show_bug.cgi?id=391177
https://bugzilla.mozilla.org/show_bug.cgi?id=342715

The biggest problem here is the tabWatcher.js that is creating the
context (using tabContext.js) too late.

So, at the time when http-on-modify-request event is fired, the
current window is still associated with a context (which is, as you
saying the previous one).

See my logs (shortened) showing order of important events (copied from
tracing-console, generated by my helper monitor extension). These logs
have been generated when I went from http://www.softwareishard.com/blog/index.php/blog/index.php
to http://www.google.cz/ page.

httpObserver.observe http-on-modify-request, http://www.google.cz/
httpObserver.observe http-on-examine-response, http://www.google.cz/
MonitorModel.unwatchWindow: http://www.softwareishard.com/blog/index.php/blog/index.php
MonitorModel.destroyContext for: http://www.softwareishard.com/blog/index.php
MonitorModel.initContext for: http://www.google.cz/
MonitorModel.watchWindow: http://www.google.cz/
httpObserver.observe http-on-modify-request,
http://www.google.cz/intl/en_com/images/logo_plain.png
httpObserver.observe http-on-modify-request,
http://www.google.cz/extern_js/f/CgJjcxICY3orMAo4CywrMBg4Ayw/7xn1JbUoKiE.js
MonitorModel.loadedContext for: http://www.google.cz/
MonitorModel.showPanel: net
etc...

You can clearly see that the previous context (softwareishard.com) is
destroyed *after* the new page (google.cz) started to load. Also the
new context is initialized (initContext) after the http-on-* events.
All the other page requests (logo_plain.png, etc.) are done properly
when the new context (google.cz) is ready to be used. But the first
document request is done to early.

This explains why:

var win = getWindowForRequest(subject);
var context = TabWatcher.getContextByWindow(win);

returns the about:blank (I believe it was the previous page, perhaps
when you started FF) if it's used within onModifyRequest. Yes there is
still the previous context.

Of course, you can do the same as Firebug. In order to monitor (and
store) all requests made by a page, the net panel is creating
temporary context within onModifyRequest (http-on-modify-request
handler) method. This temp context is created for the first document
request and all info stored into it is merged with real context in
initContext.

See net.js for more info how it's done.
http://code.google.com/p/fbug/source/browse/branches/firebug1.4/content/firebug/net.js

I have used the same for Firecookie (this code could be perhaps easier
to explore)
http://code.google.com/p/firecookie/source/browse/trunk/chrome/content/firecookie/fireCookie.js

I welcome any suggestions and improvements!

Honza

[John J Barton]

On Nov 26, 6:45 am, Jan Odvarko <odva...@gmail.com> wrote:
...

> So, at the time when http-on-modify-request event is fired, the
> current window is still associated with a context (which is, as you
> saying the previous one).

> ...

Maybe this is a blessing in disguise? One of our other problems is the
mismatch between the page-oriented debugging model of Firebug and the
application-oriented model of Web 1.0 applications. We currently have
poor support for a page that replaces itself with another page from
the same 'application'.

>
> You can clearly see that the previous context (softwareishard.com) is
> destroyed *after* the new page (google.cz) started to load. Also the
> new context is initialized (initContext) after the http-on-* events.
> All the other page requests (logo_plain.png, etc.) are done properly
> when the new context (google.cz) is ready to be used. But the first
> document request is done to early.

> ...

What if we attached the http-on-* event results to which ever context
it maps to, then when we get the initContext we attempt to analyze
whether this request is a new app or not. We could make this
explicit, and for the new page we issue "reInitContext(context,
oldURL, newURL)" rather than destroyContext and initContext. Then
reInitContext can be in charge of moving pre-destroyContext info into
the right places for the new page.

jjb

[Manoj]

I've got the workaround sorted for now, similar to how firecookie and
the network panel. There appears to be a chance that network requests
will be mismatched. I experienced some already with what appeared to
be late network requests (possibly being fired when the document is
unloaded) of the previous page getting associated with the next
navigation. Will try to develop a concrete test case and post later.

A minor question I had was w.r.t firecookie.js not using the existing
firebug-http-observer interface. Accoding to the comments in firebug-
http-observer.js:

/**
* This service is intended as the only HTTP observer registered by
Firebug.
* All FB extensions and Firebug itself should register a listener
within this
* servise in order to listen for http-on-modify-request and http-on-
examine-response.
* See also: http://developer.mozilla.org/en/Setting_HTTP_request_headers
*/

Other than that, I will shift focus to capturing the DOM events next.

Regards,
Manoj

On Nov 26, 6:45 am, Jan Odvarko <odva...@gmail.com> wrote:
> > Subsequent navigations, return the previous context (the one about to
> > be destroyed.)  The framework calls initContext() after the initial
> > request.
>
> Yes, this very confusing piece in Firebug. Unfortunately I don't
> knowhow to improve that. I have tried that the other day, but gave up,
> we need more support from Firefox here:

> I think following bugs are directly related:https://bugzilla.mozilla.org/show_bug.cgi?id=391177https://bugzilla.mozilla.org/show_bug.cgi?id=342715

>
> The biggest problem here is the tabWatcher.js that is creating the
> context (using tabContext.js) too late.
>
> So, at the time when http-on-modify-request event is fired, the
> current window is still associated with a context (which is, as you
> saying the previous one).
>
> See my logs (shortened) showing order of important events (copied from
> tracing-console, generated by my helper monitor extension). These logs
> have been generated when I went fromhttp://www.softwareishard.com/blog/index.php/blog/index.php
> tohttp://www.google.cz/page.
>
> httpObserver.observe http-on-modify-request,http://www.google.cz/

> httpObserver.observe http-on-examine-response,http://www.google.cz/

> MonitorModel.unwatchWindow:http://www.softwareishard.com/blog/index.php/blog/index.php
> MonitorModel.destroyContext for:http://www.softwareishard.com/blog/index.php
> MonitorModel.initContext for:http://www.google.cz/
> MonitorModel.watchWindow:http://www.google.cz/
> httpObserver.observe http-on-modify-request,http://www.google.cz/intl/en_com/images/logo_plain.png

> httpObserver.observe http-on-modify-request,http://www.google.cz/extern_js/f/CgJjcxICY3orMAo4CywrMBg4Ayw/7xn1JbUo...

> MonitorModel.loadedContext for:http://www.google.cz/
> MonitorModel.showPanel: net
> etc...
>
> You can clearly see that the previous context (softwareishard.com) is
> destroyed *after* the new page (google.cz) started to load. Also the
> new context is initialized (initContext) after the http-on-* events.
> All the other page requests (logo_plain.png, etc.) are done properly
> when the new context (google.cz) is ready to be used. But the first
> document request is done to early.
>
> This explains why:
> var win = getWindowForRequest(subject);
> var context = TabWatcher.getContextByWindow(win);
> returns the about:blank (I believe it was the previous page, perhaps
> when you started FF) if it's used within onModifyRequest. Yes there is
> still the previous context.
>
> Of course, you can do the same as Firebug. In order to monitor (and
> store) all requests made by a page, the net panel is creating
> temporary context within onModifyRequest (http-on-modify-request
> handler) method. This temp context is created for the first document
> request and all info stored into it is merged with real context in
> initContext.
>

> See net.js for more info how it's done.http://code.google.com/p/fbug/source/browse/branches/firebug1.4/conte...

>
> I have used the same for Firecookie (this code could be perhaps easier

> to explore)http://code.google.com/p/firecookie/source/browse/trunk/chrome/conten...

[Manoj]

> Well this is supposed to support monitoring calls, but I've never seen
> it in action.
>
> From what I can tell, the result should be these calls for monitored
> methods:
>         frame = getStackFrame(frame, context);
>         Firebug.Console.log(frame, context);
> which is close to what you need for raw input.
>
> Seems like we should move that code to Firebug.console, make it a
> debug listener, and dispatch "onCall" with [context, frame].
>

Hi John,

Will this be similar to the firebug-http-observer service?
A single point for firebug to attach to the Firefox jsd and interested
parties can register appropriate listeners.

In either case, it will be great if something workable can be agreed
upon and released soon. I'm almost done with my network and DOM work
and look forward to wrapping up this final item before I move onto the
UI challenge :-O

Regards,
Manoj

[John J Barton]

Ok if you issue
Firebug.Debugger.addListener(this);
on an object with

// Firebug.Debugger listener

onCall: function(context, frame)
{
Firebug.Console.log(frame, context);
},

you should get called. You can test by using the command line
monitor(foo)
for a page that has a function foo().

This is not satisfactory: you'll probably want to suppress the output
the console. Seems to me that we should adopt the DOM model for
firebug events, with extensions surrounding the core modules. That
would allow you to assert "capture" true and then abort the event
dispatch chain.

But start with this and give feedback.

John.

[Manoj]

I applied your patch to my existing 1.4X.0a6 revision.

It doesn't seem to work i.e. myObserver.onCall() is not getting called
and by the looks of it, Firebug.Debugger.onCall() is not getting
invoked either. :-(

I need to update to the latest 1.4 but before I do that I have to
setup the build environment. Which utilities are recommended for
building Firebug on a Windows system?

Regards,
Manoj

[John J Barton]

The readme.txt should say, you only need svn and firefox, but ant
makes some things easier.

[Manoj]

Confirmed after building latest from http://code.google.com/p/fbug/source/browse/#svn/branches/firebug1.4
The callback isn't triggered. The problem seems to be that
jsd.functionHook is not being set in firebug service. AFAICS, it is
only being set when single-stepping (see FirebugService.hookFunctions
() in firebug-service.js)

This will require a little more hacking. We need to have the
Firebug.Debugger.onCall() callback registered with jsd. Then we can
ensure the existing functionality does not impact us by modifying
FirebugService.hookFunctions() to save the existing jsd.functionHook
callback and restore it in stopStepping(). Also modify, functionHook()
to chain to the saved callback.

jsdICallHook interface specifies two arguments for onCall() the frame
and type (i.e. FUNCTION_CALL | FUNCTION_RETURN etc.) My extension
needs the type information as well. So Firebug.Debugger.onCall()
should be updated to accept and pass on both the arguments.

Regards,
Manoj

[John J Barton]

Here is how I tested it:
http://getfirebug.com/tests/script/Event.html
open firebug , enable all
Click To Fire on the page one time
Firebug > Console > Command line: monitor(fire);
Click to Fire on the page again.
You should see
fire()....Event.html(line 11)
If you click on the function name you will go to the definition.

The onCall is a special kind of breakpoint, maybe its not what we want
after all.

On Dec 3, 4:54 pm, Manoj <kawi...@gmail.com> wrote:
> Confirmed after building latest fromhttp://code.google.com/p/fbug/source/browse/#svn/branches/firebug1.4

[Manoj]

>
> The onCall is a special kind of breakpoint, maybe its not what we want
> after all.

Yes, this is not what I want. I'm interested in the "onCall" callback
of the jsdICallHook interface implemented by the jsdIDebuggerService.
Making this available will allow my extension to observe all
JavaScript function calls/returns.

[John J Barton]

Ok it looks like the onCall related code is somewhat misnamed. The
'monitor' function could allow any source line to trigger a call back
but the front end (debugger.js) wires this to the first line of a
function. So we need to decouple some of this, rename some, and
reimplement some.

[Jan Odvarko]

> A minor question I had was w.r.t firecookie.js not using the existing
> firebug-http-observer interface. Accoding to the comments in firebug-
> http-observer.js:

Firecookie is traing to support all versions of Firebug and the
firebug-
http-observer.js is new in 1.3. The correct solution should be to
check
existence of the observer service in FB and use it if it's available.
Honza

[John J Barton]

Ok after R1473, branches/firebug1.4 implements traceCalls. Same test
case as above, with traceCalls() in place of monitor(). The output is
incorrect, but I *think* its just the console.onFunctionCall() code.

[Manoj]

The latest revision cleans up the confusing naming but it still does
not provide any way to *automatically* monitor all the JavaScript
activity. The user (or extension) has to explicitly enable function
call tracing / monitoring by identifying the target functions.

AFAICS, the only way to automatically monitor *all* JavaScript
activity is to setup hooks for jsdIDebuggerService.functionHook and
jsdIDebuggerService.topLevelHook.

Or is there a way for the extension to identify and setup traceFunction
() for *all* javascript functions? That would still not tell me when
the top level script starts and completes it's execution.

In either case, I think exposing these two hooks of the
jsdIDebuggerService would be beneficial.

Regards,
Manoj

[John J Barton]

You definitely don't want to automatically monitor all javascript
activity. The browser runs on javascript. We have to have some
selection mechanism. I just implemented one (by function) that I knew
would be quick to implement so you can start with it while we work out
other selection mechanisms.

Some time ago I tried topLevelHook and found it always crashes
Firefox. Someone advised me that it did not work; as I recall Venkman
does not use it. That is why the breakOnNext feature does not use it.

[Manoj]

On Dec 4, 11:16 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> You definitely don't want to automatically monitor all javascript
> activity. The browser runs on javascript.  We have to have some
> selection mechanism.

I was thinking of filtering the frames using the jsdIStackFrame's
isNative property and further distinguishing scripts based on http/
https/file: schemes (using jsdIScript's fileName property) and
ignoring everything else (chrome: etc.) I think that would work.

>  I just implemented one (by function) that I knew
> would be quick to implement so you can start with it while we work out
> other selection mechanisms.

Unfortunately, I haven't thought through this type of approach so I'm
not sure how it would work. If there was an easy way to identify all
functions, my extension could register for all of them. Otherwise, it
requires that the user know which JS functions need to be monitored.
Whereas the assumption of my extension is that the user does not know
and is infact going to use my extension to figure out which JS
functions / events etc. matter in any given interaction with the
application.

Regards,
Manoj

[John J Barton]

On Dec 4, 3:05 pm, Manoj <kawi...@gmail.com> wrote:
> On Dec 4, 11:16 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
>
> > You definitely don't want to automatically monitor all javascript
> > activity. The browser runs on javascript.  We have to have some
> > selection mechanism.
>
> I was thinking of filtering the frames using the jsdIStackFrame's
> isNative property and further distinguishing scripts based on http/
> https/file: schemes (using jsdIScript's fileName property) and
> ignoring everything else (chrome: etc.)  I think that would work.

Don't you want just the frames from a single web page? (Not the other
tabs/windows?)

I think Firebug's API should be based on the 'context', that is it
should give you data marked with or filtered by window. A year from
now the windows will be in separate processes so we want to isolate
code the deals with multiple windows.

>
> >  I just implemented one (by function) that I knew
> > would be quick to implement so you can start with it while we work out
> > other selection mechanisms.
>
> Unfortunately, I haven't thought through this type of approach so I'm
> not sure how it would work. If there was an easy way to identify all
> functions, my extension could register for all of them. Otherwise, it
> requires that the user  know which JS functions need to be monitored.
> Whereas the assumption of my extension is that the user does not know
> and is infact going to use my extension to figure out which JS
> functions / events etc. matter in any given interaction with the
> application.

Sure, but while I am adding support for that I wanted to give you a
start.

>
> Regards,
> Manoj

[Manoj]

On Dec 4, 5:30 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> On Dec 4, 3:05 pm, Manoj <kawi...@gmail.com> wrote:
>
> > On Dec 4, 11:16 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
>
> > > You definitely don't want to automatically monitor all javascript
> > > activity. The browser runs on javascript.  We have to have some
> > > selection mechanism.
>
> > I was thinking of filtering the frames using the jsdIStackFrame's
> > isNative property and further distinguishing scripts based on http/
> > https/file: schemes (using jsdIScript's fileName property) and
> > ignoring everything else (chrome: etc.)  I think that would work.
>
> Don't you want just the frames from a single web page? (Not the other
> tabs/windows?)
>

Yes, I'm assuming the context will be passed along as well! :-)
So the callback would have (frame, type, context) with the frame and
type being provided by jsdIDebuggerService.

> I think Firebug's API should be based on the 'context', that is it
> should give you data marked with or filtered by window.  A year from
> now the windows will be in separate processes so we want to isolate
> code the deals with multiple windows.

Agree. I'm counting on FB to pass back the context in the callback.

> > >  I just implemented one (by function) that I knew
> > > would be quick to implement so you can start with it while we work out
> > > other selection mechanisms.
>
> > Unfortunately, I haven't thought through this type of approach so I'm
> > not sure how it would work. If there was an easy way to identify all
> > functions, my extension could register for all of them. Otherwise, it
> > requires that the user  know which JS functions need to be monitored.
> > Whereas the assumption of my extension is that the user does not know
> > and is infact going to use my extension to figure out which JS
> > functions / events etc. matter in any given interaction with the
> > application.
>
> Sure, but while I am adding support for that I wanted to give you a
> start.

Oh, OK. Thanks. :-)

[John J Barton]

Well I have good news and bad news.

The good news is that in theory "traceAll()" from R1479 on branches/
firebug1.4 is what you want. It filters the functionHook calls to
allow any from the URLs on the context and none others, then turns on
the call back.

The bad news is that the code crashes FF3.0.4.
http://crash-stats.mozilla.com/report/index/18be1d90-ff17-4a14-a9f1-adc0d2081204
I'll see if I can find a workaround.

jjb

[Manoj]

Thanks John!
Once this is working, it would be exactly what I need.

I'll try to spend sometime next week to figure out why FF is crashing.

Regards,
Manoj

On Dec 4, 10:17 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Well I have good news and bad news.
>
> The good news is that in theory "traceAll()" from R1479 on branches/
> firebug1.4 is what you want. It filters the functionHook calls to
> allow any from the URLs on the context and none others, then turns on
> the call back.
>

> The bad news is that the code crashes FF3.0.4.http://crash-stats.mozilla.com/report/index/18be1d90-ff17-4a14-a9f1-a...

[Manoj]

I've also posted this issue in the JS discussion group incase anyone
there has pointers.

http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/3ef6b338c80ec273#

Regards,
Manoj

[Manoj]

John, Honza,

Thanks for all the help so far, I've achieved the first major
milestone. I now have a Firebug extension which tracks and
consolidates network, DOM and JavaScript activity into a single
representation.

The following is a screenshot of how it looks so far:

http://www.filedropper.com/second/dfabbbd43bc9f80c27da19e28f5c6427.png

blue = network activity (AJAX request in this case)
purple = Javascript
green = DOM events

Current Status: Demo quality and requires a hack to get the JS call
tracing.

To avoid the Firefox crash which happens when we try to match the
browser tab for the stack frame, I prevented firebug from trying to
extract this information thereby restricting my addon to working with
a single context.

Unfortunately, this issue remains a showstopper and will likely
prevent my addon from being released if it doesn't get addressed.

Next steps:

1. Ability to save the trace information to a file (need to settle on
some type of xml format)
2. Improve the UI and make it leverage other Firebug panels such as
"Net" and "Script" for e.g. when you double-click a network trace it
switches to the "Net" panel and displays the details.
3. Possibly add a side panel to display more details about the
individual trace items.
4. Options to enable/disable the tracing and configuration options
w.r.t monitoring DOM events.
5. Performance issues.

Any comments/suggestions are welcome.

Regards,
Manoj

On Dec 8, 5:47 pm, Manoj <kawi...@gmail.com> wrote:
> I've also posted this issue in the JS discussion group incase anyone
> there has pointers.
>

> http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thre...

[John J Barton]

On Dec 15, 2:41 pm, Manoj <kawi...@gmail.com> wrote:
...

> To avoid the Firefox crash which happens when we try to match the
> browser tab for the stack frame, I prevented firebug from trying to
> extract this information thereby restricting my addon to working with
> a single context.

> ...
To get a fix we need a small test case and a bugzilla report to start
working on getting Firefox help. A one page extension with a single
content/test.xul file is ideal. But I guess you need the jsd stuff to
create the crash. If you create a tiny Firebug extension that crashes
I will make it in to a standalone crasher.

jjb

[Manoj]

Done and sent to your email address. Let me know incase of any
problems.

Regards,
Manoj

[John J Barton]

Sent to mozilla land:
Bug 469924 - [crash][jsd] js_GetArgsObject crash from frame.scope

jjb