1151500 - [jsdbg2] Setting a function's source

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[James Long (:jlongster)]

The Chrome protocol has a setScriptSource method (https://developer.chrome.com/devtools/docs/protocol/tot/debugger#command-setScriptSource) which takes a source and a string and literally sets the string to be the new source for the function, with all closures/variables/state/etc in tact.

I poked around their source and they seem to very literally gut out the function and inject new source contents, so the engine will see it as a normal function with that source. There isn't any runtime hackery going on (like checking if a new version of the func exists when called).

People are starting to build live editing tools around this: http://amokjs.com/. Chrome live editing is also built on this.

Eventually we want live editing in our debugger also. There is bug 771339 about that. That bug explains a hack where we patch functions in the devtools side by setting an internal breakpoint at the top of function, and when called, checking if a patched version exists and calling it instead.

I thought it was a good idea at first, but it wreaks havoc on the rest of the debugger. You can't reliably do anything any more with the source because locations will be all wrong. The user will see all the new code, with the function maybe being 5 lines longer now. If they want to set a breakpoint later in the file, our engine will set it in the wrong place because they are seeing a *different* source in the frontend editor from the actual source in the debugger.

We could potentially keep a sourcemap around, but since we're dealing with individual function patches, calculating the sourcemap would be difficult and it also just makes the whole thing hard to comprehend.

I think we either need to decide if we are ever going to have something like setScriptSource or not. If we don't have it, I don't think we can do live editing.

Comment 1

[James Long (:jlongster)]

A few details I think are important after talking with shu & luke: we do *not* need the ability to hot patch *live* functions, meaning anything on the stack. Live editing allows you to interactively develop apps, without the need to set breakpoint. I think the case for live editing while actually paused at a breakpoint and being able to step through the new code immediately is pretty weak. We just want to change the contents of a function, and if an instance is live on the stack, the patching can happen whenever it leaves the stack.

This is the kind of stuff live editing is used for, no active function patching needed: https://www.youtube.com/watch?v=YuwPi59Oig0

Comment 2

[James Long (:jlongster)]

We also have a chance to be better than Chrome here; there are a few bugs like this one (https://code.google.com/p/v8/issues/detail?id=3894) where patching a large function is pretty slow. I mean, we might run into the same problems, but if we don't we would be even better.

Comment 3

[Pomax]

This functionality would also greatly help other Mozilla projects in terms of running automated testing; we considered using amok in some of the Webmaker projects on the Foundation side, but had to give up on it because it only works in Chrome, with the authors stating that making it work for Firefox is too hard, and therefore just not worth doing. That feels like a clear signal that we need to meet people where they are by implementing the bits necessary to run an amok or the like using Firefox as well.

Comment 4

[Pomax]

3 years of inactivity, should this just be closed at this point?