Bug 152682 – Web Inspector: Show upcoming values of non-native iterators

• Status: NEW
• Component: Web Inspector

[Nikita Vasilyev]

Created attachment 268178 [details]
[Animated GIF] Actual/expected

Web Inspector neatly shows upcoming values for native iterators.
https://webkit.org/blog/3516/web-inspector-console-improvements/
Unfortunately, it doesn't do it for developer defined iterators.

Custom data structures such as linked lists, ordered sets, ordered maps, 
sorted arrays and many others that you can find in Immutable.js[1]
and Collections.js[2] would benefit from better console logging.

Web Inspector could show upcoming values for all objects that have
Symbol.iterator property.

Reduction: http://nv.github.io/webkit-inspector-bugs/iterators-custom/

[1]: http://facebook.github.io/immutable-js/docs/
[2]: http://www.collectionsjs.com/all

[Radar WebKit Bug Importer]

<rdar://problem/24036632>

[Blaze Burg]

I think this could backfire if the iterators are not side effect-free. We can always do this for native iterators because we know how they are implemented.

Perhaps we could hide it behind the getter "eyeball button".

[Joseph Pecoraro]

(In reply to comment #2)
> I think this could backfire if the iterators are not side effect-free. We
> can always do this for native iterators because we know how they are
> implemented.

Correct!

> Perhaps we could hide it behind the getter "eyeball button".

Even this might be difficult. We may need to have some way to duplicate an iterator, as peeking forward will actually advance the iterator and we can't advance the actual iterator without then breaking execution.

--

An entirely alternative solution would be allowing developers to provide their own previews for their own objects. See:
<https://webkit.org/b/142656> Web Inspector: Expose a way for developer provided object previews

I rather like this idea here. The Collections.js object could provide its own JSON preview, which would peek at the next upcoming values.

  class LinkedList {
    constructor() {
      // ...
    }
    get [console.previewSymbol]() {
      // peek at the next values and return something useful
      // for example: return ["one", "two", "three", "..."]
    }
  }

This would replace the Inspector's property based preview with the library defined preview. For iterators in particular we might need to do something extra. Perhaps:

    [console.iteratorPeekSymbol](n) {
      // return the next `n` values
    }

[Blaze Burg]

(In reply to comment #3)
> (In reply to comment #2)
> > I think this could backfire if the iterators are not side effect-free. We
> > can always do this for native iterators because we know how they are
> > implemented.
> 
> Correct!
> 
> > Perhaps we could hide it behind the getter "eyeball button".
> 
> Even this might be difficult. We may need to have some way to duplicate an
> iterator, as peeking forward will actually advance the iterator and we can't
> advance the actual iterator without then breaking execution.
> 
> --
> 
> An entirely alternative solution would be allowing developers to provide
> their own previews for their own objects. See:
> <https://webkit.org/b/142656> Web Inspector: Expose a way for developer
> provided object previews

If they use iterators, why are they going to have any less trouble duplicating the iterator state than we are?

cc: Yusuke, what do you recommend doing to implement peeking at next iterator values?

[Joseph Pecoraro]

> If they use iterators, why are they going to have any less trouble
> duplicating the iterator state than we are?

Our native iterators have a wrapper and an internal object. When we peek, we create a new wrapper, with the same data as the original wrapper, advance the new wrapper, then drop it on the floor. See JSMapIterator::clone, JSSetIterator::clone, etc.

I don't think we can make the same assumptions about any user script's object. And I'm not sure we can call execute _anything_ on the user object in a way that will guarantee no side-effects, as anything can be a getter.

The cop-out, which is what I'm suggesting, is a public function with a contract of "don't do side-effects, if you do it is your fault". The inspector can then call these. Problem is it requires libraries to author those functions.

[Yusuke Suzuki]

(In reply to comment #4)
> cc: Yusuke, what do you recommend doing to implement peeking at next
> iterator values?

I think cloning the user crafted iterator completely is impossible. For example,


function generateIterator() {
    var capturedValue = 0;
    var iterator = {
        [Symbol.iterator]() { return this; }
        next() {
            return { value: capturedValue++, done: false };
        }
    };
    return iterator;
}

In the above case, deeply cloning the given iterator object is not enough.
I'm +1 on console.previewSymbol :)

[Saam Barati]

previewSymbol sounds awesome