Bug 183267 – Web Inspector: Typing Symbol.next() causes iterator advancement

• Status: NEW
• Component: Web Inspector

[Daniel Bates]

Perform the following:

1. Open Web Inspector console view.
2. Evaluate the following: var it = "abcdef"[Symbol.iterator]();
3. *Type* (read: do not copy and paste) the following: it.next().value
4. Press the return key on the keyboard.

The result evaluates to "b". But it should be "a".

This issue seems to only occur when typing in the inspector the expression in (3). It does not occur if you copy and paste the expression in (3) and then press the return key on the keyboard.

[Joseph Pecoraro]

Just autocomplete greedily evaluating functions. We should not do this in cases where there could be side-effects but generally it is useful to evaluate a function if there are no side-effects.

For example typing:

  js> alert(1).|

Will trigger an alert. Same issue, ")." will trigger autocompletion of the function preceding the parens.

[Daniel Bates]

(In reply to Joseph Pecoraro from comment #1)
> Just autocomplete greedily evaluating functions. We should not do this in
> cases where there could be side-effects but generally it is useful to
> evaluate a function if there are no side-effects.
>

Can we do this then and avoid autocompleting known functions with side-effects?

> 
> For example typing:
> 
>   js> alert(1).|
> 
> Will trigger an alert. 

This is another example of a function where auto-evaluating it while typing is not useful.

[Blaze Burg]

If we are able to evaluate the receiver and figure out its type, then yes we could blacklist some evaluations for autocomplete for further expressions. In some case it may be possible to automatically generate this information if it's encoded in IDL, otherwise we'll need to compile a list manually.

[Daniel Bates]

(In reply to Joseph Pecoraro from comment #1)
> Just autocomplete greedily evaluating functions. We should not do this in
> cases where there could be side-effects but generally it is useful to
> evaluate a function if there are no side-effects.
> 

This bug does not have as much to do with the general implementation strategy of autocomplete to greedily evaluating functions (*) as it does with the fact that this implementation throws away the result of the evaluation (**) such that it is not possible to ever see this result or operate on it.

(*) Though this strategy as it is currently implemented without saving and restoring program state or bookkeeping of intermediary results is problematic. How does Chrome DevTools accomplish autocompletion?

(**) Obviously we keep the type information of the result so as to provide autocompletion and suggestions.