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
On Dec 3, 3:43 pm, John J Barton <[EMAIL PROTECTED]> wrote:
> The readme.txt should say, you only need svn and firefox, but ant
> makes some things easier.
>
> On Dec 3, 2:20 pm, Manoj <[EMAIL PROTECTED]> wrote:
>
> > 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
>
> > On Dec 2, 10:46 pm, John J Barton <[EMAIL PROTECTED]> wrote:
>
> > > 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.
>
> > > On Dec 2, 5:24 pm, Manoj <[EMAIL PROTECTED]> wrote:
>
> > > > > 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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
