Bug 59474 – Web Inspector: [protocol] evaluate* methods should accept 'additional context' param

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Peter Rybin]

When evaluating expression client should be able to refer to a particular remote object that cannot be accessed by name. Additional binding objectID -> name in local scope should be provided.
Protocol commands "evaluate*" should accept 'additional context' parameter in form
[
  {
    "name": <name>,
    "objectID": <objectID>
  }
]

The expression should be evaluated with additional names/values binded to a local scope.

E.g.
user expression "nextRandomColor()" evaluated to object with id 5.
Protocol let explore its properties. Protocol should also let evaluate string representation of the object:
  non-user expression "String(val)" with additional context [ { "name":"val", "objectID": 5 } ].

[Patrick Mueller]

In your example, where is the user getting the objectId value of 5 from?  From exploring some other object?  I find it hard to imagine that people would use this sort of functionality.

Here's what I'd run, in the console.

   x = nextRandomColor()
   String(x)

After typing the first line, you can explore the result a bit.  Then type the second line and explore that a bit.

It has the side effect of setting an "x" variable in some scope (presumably global scope).  But I rarely care about that.

Do you have another use case?

[Peter Rybin]

(In reply to comment #1)
> In your example, where is the user getting the objectId value of 5 from?  From exploring some other object?  I find it hard to imagine that people would use this sort of functionality.
> 
> Here's what I'd run, in the console.
> 
>    x = nextRandomColor()
>    String(x)
> 
> After typing the first line, you can explore the result a bit.  Then type the second line and explore that a bit.
> 
> It has the side effect of setting an "x" variable in some scope (presumably global scope).  But I rarely care about that.
> 
> Do you have another use case?

It is needed for Eclipse-based client, which doesn't have console. The Eclipse UI assumes that you can point to any value (in Variables or Expressions views) and you see its string representation. Other feature is to "pin-point" any value as a global object property
( http://code.google.com/p/chromedevtools/wiki/EclipseDebuggerFeatures ).

The "non-user expression" (one with id) is generated. That's how Java client manipulates values (except for looking up properties, which is done by a dedicated protocol command).

[Patrick Mueller]

(In reply to comment #2)
> It is needed for Eclipse-based client, which doesn't have console. ...

I see.  I was confused, I thought you were expecting this to be exposed somehow through the console.  Exposed just through the protocol APIs makes a lot more sense.

[Peter Rybin]

This feature was considered harmful (?) in discussion as too powerful.