On Wed, Aug 17, 2011 at 4:15 PM, Brendan Eich <brendan at mozilla.com> wrote:
Mozilla has evalInSandbox built-ins.
Unfortunately I have quite a lot of experience with evalInSandbox.
If you mean Firebug vs. evalInSandbox, if I recall correctly, the problem is that a debugger doesn't want as much isolation as the security use-cases that motivated evalInSandbox want. Is that right?
From corresponding with John, this seems like a combo of out of date MDC docs on evalInSandbox (it uses proxy-based membranes aggressively for security, but the docs predate that), and the common line number problem with all eval variants, where multiple lines in the eval'ed source do not have usable line numbers:
We have discussed various fixes to propagate accurate, invertible source coordinates through nested evals in bugzilla bugs in the past. Firebug has tried crypto-hashing source strings, IIRC. Does anyone have a solid solution?
/be
Regarding hashing source: In the case that the dev has set a
breakpoint in an eval buffer and Firebug has no other option, then the
buffer is MD5 hashed. That way the debugger can reset the breakpoints
if exactly the same buffer is submitted to the compiler again, say on
reloading the page. I guess it takes more time to hash the buffer than
compile it and the scheme fails if the dev changes the buffer in any
way. But it was the only solution I could find with the Firebug/jsd
design.
Regarding solution: I still believe my proposed approach to dynamic
compilation remain valid,
bugzilla.mozilla.org/show_bug.cgi?id=449464. In thinking about
this, keep in mind: the browser and web page user have no use for the
"filename", it only has meaning for development. In the compiler
simply converts text to JS objects. A "filename" is just tag it is
given and re-emits for the benefit of devtools. In a static system
this tag is enough because time is not important. In a dynamic system
the devtool needs events so it can correlate compilation with buffers
and so it can track the ultimate source of JS objects. My proposal is
simple: before and after compilation events that supply references to
the DOM elements or JavaScript statements that cause compilation.
jjb
> On Aug 17, 2011, at 4:39 PM, Brendan Eich wrote:
>
>> On Aug 17, 2011, at 4:25 PM, John J Barton wrote:
>>
>>> On Wed, Aug 17, 2011 at 4:15 PM, Brendan Eich <brendan at mozilla.com> wrote:
>>>>
>>>> Mozilla has evalInSandbox built-ins.
>>>
>>> Unfortunately I have quite a lot of experience with evalInSandbox.
>>
>> If you mean Firebug vs. evalInSandbox, if I recall correctly, the problem is that a debugger doesn't want as much isolation as the security use-cases that motivated evalInSandbox want. Is that right?
>
> From corresponding with John, this seems like a combo of out of date MDC docs on evalInSandbox (it uses proxy-based membranes aggressively for security, but the docs predate that), and the common line number problem with all eval variants, where multiple lines in the eval'ed source do not have usable line numbers:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=307984
>
> We have discussed various fixes to propagate accurate, invertible source coordinates through nested evals in bugzilla bugs in the past. Firebug has tried crypto-hashing source strings, IIRC. Does anyone have a solid solution?
>
> /be
Regarding hashing source: In the case that the dev has set a
breakpoint in an eval buffer and Firebug has no other option, then the
buffer is MD5 hashed. That way the debugger can reset the breakpoints
if exactly the same buffer is submitted to the compiler again, say on
reloading the page. I guess it takes more time to hash the buffer than
compile it and the scheme fails if the dev changes the buffer in any
way. But it was the only solution I could find with the Firebug/jsd
design.
Regarding solution: I still believe my proposed approach to dynamic
compilation remain valid,
https://bugzilla.mozilla.org/show_bug.cgi?id=449464. In thinking about
this, keep in mind: the browser and web page user have no use for the
"filename", it only has meaning for development. In the compiler
simply converts text to JS objects. A "filename" is just tag it is
given and re-emits for the benefit of devtools. In a static system
this tag is enough because time is not important. In a dynamic system
the devtool needs events so it can correlate compilation with buffers
and so it can track the ultimate source of JS objects. My proposal is
simple: before and after compilation events that supply references to
the DOM elements or JavaScript statements that cause compilation.
jjb
Regarding hashing source: In the case that the dev has set a breakpoint in an eval buffer and Firebug has no other option, then the buffer is MD5 hashed. That way the debugger can reset the breakpoints if exactly the same buffer is submitted to the compiler again, say on reloading the page. I guess it takes more time to hash the buffer than compile it and the scheme fails if the dev changes the buffer in any way. But it was the only solution I could find with the Firebug/jsd design.
Regarding solution: I still believe my proposed approach to dynamic compilation remain valid, bugzilla.mozilla.org/show_bug.cgi?id=449464. In thinking about this, keep in mind: the browser and web page user have no use for the "filename", it only has meaning for development. In the compiler simply converts text to JS objects. A "filename" is just tag it is given and re-emits for the benefit of devtools. In a static system this tag is enough because time is not important. In a dynamic system the devtool needs events so it can correlate compilation with buffers and so it can track the ultimate source of JS objects. My proposal is simple: before and after compilation events that supply references to the DOM elements or JavaScript statements that cause compilation.
jjb