I didn't find a bug on file for this and I wanted one to refer to in protocol code. Spec: https://wiki.mozilla.org/Debugger#Function_Properties_of_the_Debugger.Frame_Prototype_Object

This bug blocks the implementation of issue 6857 (Give the ability to modify the returned value) in Firebug : http://code.google.com/p/fbug/issues/detail?id=6857 Florent

I have two ideas on how to implement this. Both are pretty gnarly. First, a spec proposal: any non-observed frames between the to-be-popped frame and the newest frame (different compartments, say), causes this method to throw. Strategy 1: Meshuga frame surgery again. That is, we *actually* pop the frames and patch the return address. This will be gnarly and a second kind of OSR in addition to the existing JIT debug mode OSR, which is obviously a lot more added maintenance burden. General algorithm below: - Let frame be the caller of the frame to be popped. - If frame is a Baseline frame, patching the return address is easy. - If frame is an Ion frame, we have to: 1. Unwind the stack so that the Ion frame is on top. 2. Bailout to Baseline now that it's on top. 3. Resume in baseline. - If frame is an Interpreter frame, we have to futz with the interpreter register file in the activation. I don't know enough about the interpreter to say if this will be hard. Strategy 2: Record the completion value and force unwind to the to-be-popped frame's caller. This is not any easier to implement. 1. The invariant that Debugger.Frames are synched on frame push/pop no longer holds. If we called |frame.pop()|, |frame| now has to be considered no longer observable according to the Debugger. 2. In order to unwind all the way to the to-be-popped frame's caller, Baseline and Interpreter have to somehow check for forced return now *even when debug mode is off*. This is a perf hit I don't want to have to take. Feel free to chime in if anyone has any bright ideas.

I don't think Debugger.Frame.prototype.pop should be implemented as specified. It's kind of insane to be removing stack frames *below* the currently executing frame, which is what D.F.p.pop calls for: live-editing your own continuation. Code using the Debugger API can get almost the same effect, at the cost of more co-ordination, by setting an onPop handler H on the frame that they want to pop to, and then returning 'null' as the resumption value from the currently running handler. H can then catch the termination and the Debugger-using code can continue with whatever it was doing.

Comment on attachment 8421122 [details] [diff] [review] Remove documentation for unneeded Debugger.Frame.prototype.pop and .replaceCall. Review of attachment 8421122 [details] [diff] [review]: ----------------------------------------------------------------- Alas, live editing your own continuation seemed real neato.

(In reply to Shu-yu Guo [:shu] from comment #5) > Alas, live editing your own continuation seemed real neato. Okay, that's completely true.