New issue
Advanced search Search tips

Issue 912128 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Dec 5
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Target.createBrowserContext rejects calls with "Error: Not allowed."

Reported by bart...@shopspring.com, Dec 5

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36

Steps to reproduce the problem:
1. Launch Chrome and keep it open:

google-chrome-stable --remote-debugging-port=9222 --headless --disable-gpu --window-size=1200,10000

2. Install the dev tools JS client using NPM:

npm install chrome-remote-interface

2. Execute the following script:

const CDP = require('chrome-remote-interface');
CDP({host: 'localhost', port: 9222})
  .then(client => client.Target.createBrowserContext())
  .then(() => console.log('success'))
  .catch(ex => console.log(ex));

What is the expected behavior?
I should see a "success" message.

What went wrong?
{ Error: Not allowed.
    at _enqueueCommand (/home/springdev/repro/node_modules/chrome-remote-interface/lib/chrome.js:90:34)
    at Chrome._handleMessage (/home/springdev/repro/node_modules/chrome-remote-interface/lib/chrome.js:252:17)
    at WebSocket._ws.on (/home/springdev/repro/node_modules/chrome-remote-interface/lib/chrome.js:230:22)
    at emitOne (events.js:116:13)
    at WebSocket.emit (events.js:211:7)
    at Receiver.receiverOnMessage (/home/springdev/repro/node_modules/ws/lib/websocket.js:741:20)
    at emitOne (events.js:116:13)
    at Receiver.emit (events.js:211:7)
    at Receiver.dataMessage (/home/springdev/repro/node_modules/ws/lib/receiver.js:417:14)
    at perMessageDeflate.decompress (/home/springdev/repro/node_modules/ws/lib/receiver.js:374:23)
  request: { method: 'Target.createBrowserContext', params: undefined },
  response: { code: -32000, message: 'Not allowed.' } }

Did this work before? Yes 70.0.3538.110

Chrome version: 71.0.3578.80  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

I suspect https://chromium-review.googlesource.com/c/chromium/src/+/1212089/ to be the culprit here. Maybe there's a way to set the "access mode" somehow?

Note that it currently impacts our production service that depends heavily on browser automation.
 
One more note: this bug is not Mac-specific; it works the same way on Linux.
Labels: Needs-Triage-M71
Labels: Needs-Bisect
Owner: dgozman@chromium.org
Status: Assigned (was: Unconfirmed)
Status: WontFix (was: Assigned)
This is intended. To create browser context, you need to connect to a browser-wide session, not to a page. Try using puppeteer, which does it for you: https://github.com/GoogleChrome/puppeteer.
Thank you, dgozman@! Because it's not an option right now for us to refactor a complex application to use Puppeteer, and we need to act fast, could you point us to any documentation that would explain what we need to do? What does "connect to a browser-wide session" mean? I tried executing client.Target.attachToBrowserTarget(), but this one also rejects with a "Not allowed" message.
Basically, you need a CDP object connected to a browser session. The url to that should be reported at localhost:9222/json/version in your example.

I don't know how chrome-remote-interface does it, but their maintainers should be able to help.
 Issue 912546  has been merged into this issue.

Sign in to add a comment