enhancement: call graphs

[Manoj]

I was wondering if it would be possible to enhance FB to capture and
display runtime call graphs along with event information and XHR
communication. The use for such an option would be to rapidly
understand web application logic (especially when dealing with 3rd
party applications) and be able to focus on the relevant script.

I've installed the trace enabled version and will be playing with it
some more to gain a better understanding of the internals (FWIW, I'm a
newbie to FF extension development, XUL etc.) I'm willing to invest
my time into this and should be able to convince my employer as well.
Would appreciate if someone more qualified can comment on the
feasibility of such a project and/or point me in the right direction.

Thanks,
Manoj

[Jan Odvarko]

Hi,
sound interesting, could you provide more info about how the
"runtime call graphs" should look like within Firebug's UI?
Honza

[Manoj]

Hi Jan,

As far as the UI is concerned, I was thinking of a collapsible folder-
view not unlike the one you find in most common file directory
browsers. This could be displayed in a seperate panel much like how
the callstack is displayed currently.

for e.g.

function a()
{
...
b();
...
c();
}

function b()
{
...
c();
...
}

function c()
{
...
d();
...
XHR.send();
...
}

function d()
{
...
e();
...
}

function e()
{
...
}

a();


For the above, a folder-style UI would look like:

GLOBAL
|
- a()
|
- b()
| |
| - c()
| |
| - d()
| | |
| | - e()
| |
| - XHR.send()
|
- c()
|
- d()
| |
| - e()
|
- XHR.send()

If a() was registered as an event handler, then the Event
which triggered the callback would be displayed on top.

[John J Barton]

Something like this is feasible, you probably know the potential
problems. The two big ones are UI (as Honza suggested by asking) and
performance. The interesting cases for this kind of feature are large
complex systems which generate lots of call stack information. I
think a highly interactive tool would be more promising and fun,
versus batch processing record/playback.

You might have to try a couple of approaches. Also the same technology
could be applied to get code coverage as well.

jjb

[Manoj]

I looked at the XUL tree and seems like it would be appropriate for
displaying this type of information. I plan to spend some more time to
understand Firebug's existing UI to see if I can get something going.
Basically, I'll be working along creating a separate panel which will
have a call tree display akin to the current DOM or HTML panels.

Regards,
Manoj

[Manoj]

So now I know why y'all thought developing the UI would be a
challenge. :-) This will certainly take more time than I had
initially anticipated. There are a couple of other crinkles I will
have to think about:

1. The frame for the FUNCTION_CALL callback does not include the
current function being called. So I will have to use the
FUNCTION_RETURN callback to complete the picture. This can present
some challenge in keeping an accurate timeline w.r.t the XHR requests
that happened in this function.

2. The event listener will have to be registered on every DOM node. It
will have to be re-registered incase the tree is dynamically altered.
Still, AFAIK there is no guarantee that my event listener will get
triggered *before* those of the web application itself. Again, this
will present a problem from tracking these events from a timeline
perspective.

There could be more but these are the deal-breakers I can think of
now.

Regards,
Manoj

[John J Barton]

On Nov 19, 6:21 pm, Manoj <kawi...@gmail.com> wrote:
> So now I know why y'all thought developing the UI would be a
> challenge. :-)   This will certainly take more time than I had
> initially anticipated. There are a couple of other crinkles I will
> have to think about:
>
> 1. The frame for the FUNCTION_CALL callback does not include the
> current function being called. So I will have to use the
> FUNCTION_RETURN callback to complete the picture. This can present
> some challenge in keeping an accurate timeline w.r.t the XHR requests
> that happened in this function.

? I don't know what callbacks you are using here.
If you use jsdICallHook you get the stack frame on call and return.

>
> 2. The event listener will have to be registered on every DOM node. It
> will have to be re-registered incase the tree is dynamically altered.
> Still, AFAIK there is no guarantee that my event listener will get
> triggered *before* those of the web application itself. Again, this
> will present a problem from tracking these events from a timeline
> perspective.

You might take a look at
https://bugzilla.mozilla.org/show_bug.cgi?id=448602
With this you get some better information.

[John J Barton]

On Nov 19, 10:02 am, Manoj <kawi...@gmail.com> wrote:

> I looked at the XUL tree and seems like it would be appropriate for
> displaying this type of information. I plan to spend some more time to
> understand Firebug's existing UI to see if I can get something going.
> Basically, I'll be working along creating a separate panel which will
> have a call tree display akin to the current DOM or HTML panels.

The current panels are all HTML (not XUL) and their contents are
generated by "domplates", a fun, undocumented Javascript template
expansion mechanism.

If you have too much 'fun', you might need to consult with Dr.
Domplate, Jan Odvarko....

jjb