Runtime.evaluate({expression: 'window.location.toString()'}) returns chrome-extension:/...

[oschrenk]

I'm not sure if this is intended behaviour, a limitiation of Chrome 59, or just plain wrong usage on my end but I expected the result of

chrome-remote-interface inspect
>>> Runtime.evaluate({expression: 'window.location.toString()'})

to return information about the current tab. But I always get some information about some extension:

{ result:
   { result:
      { type: 'string',
        value: 'chrome-extension://bikioccmkafdpakkkcpdbppfkghcmihk/background.html' } } }

In the latter case it's Signal Desktop. But disabling that I now get information from Vimium back (both extensions I have currently installed).

I had a brief moment when it was actually returning the current tab, so I'm assuming that the idea is correct, but something is wrong with the debugging. If not what would be the right approach to get the current tab (and the body of it)

Chrome 59.0.3063.4 dev (64-bit)
macos

[cyrus-and]

I've never experienced that because I usually inspect minimal Chrome instances, but you're right.

What happens when you do not specify the target (tab option) is that the first entry of CDP.List() (or chrome-remote-interface list) having the webSocketDebuggerUrl property set is used (note that this field is not available if the target is already being inspected).

Now there are several kinds of entries: background_page, service_worker, page (actual tabs, it seems), iframe, etc. which Chrome manages and reorder according to their activity.

I should probably fix the description in the README and in the the CLI help message, but since there are many use cases I'm not sure if I should prioritize actual tabs.

In any case, you can decide explicitly which target to inspect either by providing a raw WebSocket URL or a callback function which in your case it would look like this:

const options = {
    tab: targets => targets.findIndex(tab => tab.type === 'page')
};

CDP(options, (client) => {/*...*/});