Target.createBrowserContext not supported
Reported by
potoms....@gmail.com,
Jan 9 2017
|
|||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Steps to reproduce the problem:
1. Running container:
docker run -p 9222:9222 justinribeiro/chrome-headless --no-sandbox --disable-gpu --remote-debugging-address=0.0.0.0 --remote-debugging-port=9222
2. Running following node script against it:
var chrome = require('chrome-remote-interface');
chrome({ port: 9222 })
.then(devtools => devtools.Target.createBrowserContext())
.catch(e => console.error(e));
What is the expected behavior?
an object with a new contextId is returned
What went wrong?
it returns
{ code: -32000, message: 'Not supported' }
Did this work before? N/A
Chrome version: 57.0.2970.0 Channel: dev
OS Version:
Flash Version: Shockwave Flash 24.0 r0
I see the same behaviour in "chrome --headless"
,
Jan 10 2017
,
Jan 10 2017
This module is not a Chromium project. Please report the issue on the project bug tracker - https://github.com/cyrus-and/chrome-remote-interface/issues
,
Jan 10 2017
I just used this module to illustrate the problem.
{ code: -32000, message: 'Not supported' } is the direct reply of the devtools debugging protocol.
,
Jan 10 2017
here it's reproduced with https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblngboilpfeibdedpjgfnlcodoo?hl=en
,
Jan 11 2017
Moving this back to Unconfirmed until someone in our team (headless) has time to try and reproduce.
,
Jan 11 2017
Which headless browser are you using here? Regular Chrome doesn't support Target.createBrowserContext() unless you start it with the --headless command line flag.
,
Jan 11 2017
Easiest to reproduce is running it against this container: https://hub.docker.com/r/justinribeiro/chrome-headless/~/dockerfile/ which runs a headless_shell build: https://storage.googleapis.com/chrome-builds/headless/chrome-headless.deb But I've also run it against Chrome 57.0.2970.0 --headless with the same outcome I just fetch a webSocketDebuggerUrl from .../json, open the connection and send {"id":1,"method":"Target.createBrowserContext"}
,
Jan 12 2017
,
Jan 12 2017
I think this is already correctly triaged. I'll have a fix up soon.
,
Jan 12 2017
Fix here: https://codereview.chromium.org/2630533002/ As a workaround pass an empty parameter object (devtools.Target.createBrowserContext({})) to the createBrowserContext command.
,
Jan 12 2017
nice! This works. Strange behaviour though, since things like '{"id":1, "method":"Network.enable"}' work without a "params" property.
,
Jan 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5a4de2c40720151cff5143b3f684698932a82af4 commit 5a4de2c40720151cff5143b3f684698932a82af4 Author: skyostil <skyostil@chromium.org> Date: Fri Jan 13 17:39:14 2017 headless: Don't require parameters for all commands Some DevTools clients omit the "params" object for commands that don't take any parameters. Be less strict about requiring it to support these clients. BUG= 679350 Review-Url: https://codereview.chromium.org/2630533002 Cr-Commit-Position: refs/heads/master@{#443598} [modify] https://crrev.com/5a4de2c40720151cff5143b3f684698932a82af4/headless/lib/browser/headless_devtools_manager_delegate.cc
,
Jan 13 2017
,
Jan 16
This seems to be broken as of Chrome 71. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by eseckler@chromium.org
, Jan 9 2017Labels: Proj-Headless