On Sat, Aug 1, 2009 at 18:34, johnjbarton<[email protected]> wrote: > The SourceFile objects are created just after the JS source is > compiled. From Firebug's perspective it works like this: > > Suddenly a function arrives having just been compiled. We know a > URL associated with the source of the function but not the source or > window. Firebug tests the call stack to see if this function is an > outer function. Typically no, so we add it to a temp list. > More functions arrive then one passes the outer function test. We > set a break point in PC=0 and return. > A breakpoint hits. If it is on PC=0 we take the outer function > script and all of the inner functions on the temp list and create a > SourceFile. In the process we do analysis of the call stack to > determine if the source is in a .js file or from eval() or event > handler. That allows us to put the source into the SourceFile. Then we > remove the breakpoint and allow the outer function to complete.
Thank you, the whole process is much clearer after this. :-) > SourceFiles are then used to map jsdIScripts to source that is shown > to the user. (SourceFiles are defined in lib.js) Alright. I'm still unsure as to how i am going to deal with the fact that a single GM script may be composed of several JS source files (glued and run in the same sandbox), which i'd like to show separately in Firebug's script tab. But this can be dealt with later... > Since GM is also an extension it could easily help by providing a > method that returns the source so Firebug can copy it into its cache > and point from the SourceFile into the cache. Yes. And the file name seems to be needed as well, at least for the GUI: so far it shows webmonkey.js, which is the JS code creating the sandbox, not the script code running inside it. I guess this GM method should return the needed script's details, whatever they end up being. As far as i can see, the only reference to the running script we share between GM and FB is the Sandbox object it's running in -- that should be the method parameter. Overall, here is how i'm proceeding: i patch firebug-service.js:getFrameScopeWindowAncestor() to allow finding the right debugger for a GM script sandbox. It then flows as usual up to debugger.js:onTopLevelScriptCreated(), patched in order to delegate the work to onSandboxScriptCreated() in case of a Sandbox scope. Finally, this last method returns a lib.js:SandboxSourceFile object. Does it look ok so far? >> Just to make it clearer though, i meant: as i understand it, it >> usually is about linking "spawned" jsdIScripts to a SourceFile, while >> in the GM-script discovery step it is about creating several >> SourceFiles objects in the context of one on(JsdI)Script handler. > > The GM script is compiled in a sandbox, so the entire compile will be > one SourceFile. It's fine as long as we show all the JS source files composing a GM script as one big source file. I guess that, if we wanted to show them separately, Firebug.Debugger#onSandboxScriptCreated() should return an array of SourceFiles... >> But i did some (limited) testing of script Sandbox values poking >> around: it worked as mentioned. > > And did you find the content of the sandbox to be critical for > debugging the GM script or only helpful in understanding sandboxes? Well, i just tested that it worked, i haven't used it for real debugging. I kinda thought: "well, i could have a JS console to poke in that thing just the way FB allows poking in a window... hey, let's use FB's console for that!". :-) As i see it, what makes poking in Windows or Sandboxes (equally) interesting is that you actually are poking in a "top-level" JS scope. But i might be wrong... > I think you can get 80% of the value of Firebug for GM without viewing > the sandbox; viewing the sandbox will be 80% of a complete job. I'd > push on the first 20%. No problem: let's focus on the debugger then. :-) -- Olivier --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
