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.
On Dec 3, 8:32 pm, John J Barton <[EMAIL PROTECTED]> wrote: > 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. > > On Dec 3, 6:22 pm, Manoj <[EMAIL PROTECTED]> wrote: > > > > 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. > > > Regards, > > Manoj > > > > On Dec 3, 4:54 pm, Manoj <[EMAIL PROTECTED]> wrote: > > > > > Confirmed after building latest > > > > fromhttp://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 -~----------~----~----~----~------~----~------~--~---
