Bug 183267 - Web Inspector: Typing Symbol.next() causes iterator advancement
Summary: Web Inspector: Typing Symbol.next() causes iterator advancement
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Local Build
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-01 15:47 PST by Daniel Bates
Modified: 2018-03-02 14:49 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bates 2018-03-01 15:47:41 PST
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.
Comment 1 Joseph Pecoraro 2018-03-01 15:53:37 PST
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.
Comment 2 Daniel Bates 2018-03-01 16:02:26 PST
(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.
Comment 3 Brian Burg 2018-03-01 16:09:18 PST
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.
Comment 4 Daniel Bates 2018-03-02 14:49:40 PST
(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.