On Aug 1, 4:13 am, Olivier Cornu <[email protected]> wrote:
> On Thu, Jul 30, 2009 at 22:59, johnjbarton<[email protected]> wrote:
>
> > The jsdIScript object corresponds to a function in Javascript.
> > SourceFile is a Firebug invention that tries to group all of the
> > jsdIScript objects that logically belong together. Firefox has no such
> > grouping, it just a big pile.
>
> Well, my question was more: how is the jsdIScript/SourceFile relation
> constrained in the Firebug framework? But i should probably get more
> familiar with Firebug SourceFiles before going there...
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.
SourceFiles are then used to map jsdIScripts to source that is shown
to the user. (SourceFiles are defined in lib.js)
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.
> 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.
>
> >> SandboxSourceFile is good, especially if Firebug defines some kind of
> >> interface allowing tiers components to provide sources for their
> >> Sandboxed scripts (and GM complies to that). ;-)
>
> > You lost me here. Firefox compile, we watch.
>
> We watch but i understand we don't usually watch sandboxes which, i
> suppose, are particular.
Ok, I see what you meant. Firebug watches the compile as I described
above.
> I'm assuming Firebug usually builds SourceFiles out of JS script DOM
> elements. In the case of a Sandbox (i.e. without corresponding DOM
> element), there seem to be no way for Firebug to build a proper
> SourceFile alone, when one is needed as is the case with GM scripts.
As above, the SourceFile does not use the window except to figure out
which context to add the SourceFile into. We get all of our info from
the compiler.
> It can only do so if it's provided with proper data by the Sandbox
> owner -- GM here.
> If that's the case, why not take it as an opportunity for Firebug to
> support Sandbox debugging? The idea being to provide an interface
> tiers chrome code can use to register Sandboxes they want to debug.
> I understand Firebug is focused on web page debugging (as opposed to
> chrome debugging), yet it makes sense to include chrome code
> dynamically altering said page, doesn't it?
I think the Sandbox itself is not very interesting, by design. The
whole point of the sandbox is to avoid having the left over bits of
the outer function hang out in the web page. What value do we get
from being able to look at those left over bits? Not too much I
guess. Sure it would be nice to have, but since Firebug is not set up
to show it the implementation could be harder.
>
> > You could try to see if Chromebug will show you the sandbox values.
> > Firebug is not really set up to deal with them. I suppose we could go
> > in that direction, but honestly I don't expect to do that.
>
> I've been unlucky with Chromebug: i tried to install it once but it
> was making FF crash (FF could not even start, iirc).
> 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?
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%.
jjb
> --
> 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
-~----------~----~----~----~------~----~------~--~---
