On Jul 30, 1:30 pm, Olivier Cornu <[email protected]> wrote:
> On Thu, Jul 30, 2009 at 17:25, johnjbarton<[email protected]> wrote:
> > On Jul 30, 2:35 am, Olivier Cornu <[email protected]> wrote:
> >> As noted in my previous mail, the source code run in the Sandbox
> >> appears at some point in the Firebug trace (step #86):
> >> script.functionSource logged by onScriptCreated() on line 1514.
> >> It is not the script source in its exact original form though (it
> >> lacks some metadata/comments, etc), so it might still be a good idea
> >> to make this original source available from GM somehow.
>
> > jsdIScript.functionSource is the so-called pretty-print, but it is
> > correctly called the decompiled function. The line number will not
> > match the source in your editor.
>
> That's right: it's true there's a real value in showing the script
> exactly as it is on-disk.
> This raises another question: a running script can actually be a
> bundle of JS files glued together thanks to a PHP-like @include
> directive. In other words, we're potentially dealing with a bunch of
> SourceFiles to be "spawned" out of a single jsdIScript.
> As, i guess, there usually is a one-to-one relationship between
> SourceFile and jsdIScript in Firebug, do you think this can be an
> issue?
No, because what ever happens on the server is someone else's problem.
We get what the browser sees, that is the problem we need to work on.
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.
>
> >> I guess that, if we rely on GM to provide the Sandbox source, that
> >> would be a GMSandboxSourceFile (as opposed to a general Sandbox
> >> mechanism)?
>
> > Sure. I suppose the correct distinction would be by how the SourceFile
> > object differs from other SourceFile objects, but GMSandbox is fine.
>
> 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.
>
> >> Then i'd just like to add a way for users to poke around in a script
> >> Sandbox/scope from the Firebug console tab, which implies a mean for
> >> users to select said scope -- cd(scope)?
>
> > Strictly speaking you can't poke around in the scope of a function X
> > unless X is being compiled or run. I suppose you would allow users to
> > examine the properties of the Sandbox object.
>
> Yes: as script global vars are Sandbox properties, i thought it could
> be helpful to explore their values...
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.
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
