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. On Dec 4, 11:06 am, Manoj <[EMAIL PROTECTED]> wrote: > 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 > > On Dec 4, 9:30 am, John J Barton <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
