795916 - Support evaluating multiple client expressions at once

Status: NEW

(DevTools :: Debugger, task, P5)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

The remote protocol uses "clientEvaluated" packet to evaluate an expression on the back-end. Since the evaluation invalidates all pause-life-time grips - including previously evaluated expression - this way can't be used if there is more expressions (e.g. in the Watch panel).

There should be a way how to evaluate more expression at once (using one round trip and one resume-pause trip) and get all the results back in an array.

Honza

Comment 1

[Victor Porof [:vporof][:vp]]

(In reply to Jan Honza Odvarko from comment #0)
> The remote protocol uses "clientEvaluated" packet to evaluate an expression
> on the back-end. Since the evaluation invalidates all pause-life-time grips
> - including previously evaluated expression - this way can't be used if
> there is more expressions (e.g. in the Watch panel).
> 
> There should be a way how to evaluate more expression at once (using one
> round trip and one resume-pause trip) and get all the results back in an
> array.
> 
> Honza

I think we discussed some workaround for this last week. Is there some inherently wrong with doing:
clientEvaluate("[eval('first expression'), eval('second expression', ...]")

However, I do agree that this is far from ideal and not convenient.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

Yes, I thought that we were confident that using the array form wouldn't present us with any problems. If Jim likes adding a separate packet as sugar around that, I'm not going to complain though.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Just to note that Victor's idea works for me as well.
So, let's see what's Jim's opinion.

Honza

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

Jim, what do you think?

Comment 5

[Jim Blandy :jimb]

What should happen when one of the 'eval' expressions causes a breakpoint hit?

Comment 6

[Jim Blandy :jimb]

The answer might be, "We abort evaluation of that expression, and proceed to the next."

Comment 7

[Jim Blandy :jimb]

Similarly, what should happen if some of the expressions throw? What's the user-visible behavior we're going for here?

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

Here is the current implementation of this idea in Firefox:

http://mxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/debugger-controller.js#921

I think we could improve error handling a bit by returning the error object instead of a string, but that seems to work.

I hadn't thought about hitting a breakpoint though. Trying it out shows that we have some bugs in there to fix. I want to say that we should not add any smarts to the server and just treat such a breakpoint hit as a regular one, but I'm afraid that might uncover other potential gotchas that I haven't thought of.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Panos Astithas [:past] from comment #8)
> I hadn't thought about hitting a breakpoint though. Trying it out shows that
> we have some bugs in there to fix.

Filed bug 815537 about this.

Comment 10

[Jim Blandy :jimb]

This is a little perverse, but: I think that code won't cope well with expressions like:

throw { get name() { throw "Another error" } }

Comment 11

[Victor Porof [:vporof][:vp]]

(In reply to Jim Blandy :jimb from comment #10)
> This is a little perverse, but: I think that code won't cope well with
> expressions like:
> 
> throw { get name() { throw "Another error" } }

The code tries (in its primitive ways) to guard itself from faulty expressions, when the client evaluation throws: http://mxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/debugger-controller.js#506

Comment 12

[Jim Blandy :jimb]

Okay, so it'll just drop that watch expression.