New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 806333 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug

Blocking:
issue 705916



Sign in to add a comment

window.chrome object not available in "headless" mode

Reported by c.newho...@gmail.com, Jan 26 2018

Issue description

Chrome Version       : 64.0.3282.119
URLs (if applicable) : n/a
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari:
    Firefox:
       Edge:

What steps will reproduce the problem?
(1) Run Chrome headless with remote debugging on, e.g: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless --disable-gpu --remote-debugging-port=9222 --window-size=1920,1080 https://yahoo.com
(2) In another browser, go to 'http://localhost:9222' and then choose the Yahoo page.
(3) Type `chrome` or `window.chrome` into the console and it will not be available.

What is the expected result?
It is expected that `chrome` and `window.chrome` will be available. I am running e2e tests that do things like "determine if I should show a User a link to our Chrome Extension" based on (among other things) whether `window.chrome && window.chrome.webstore` is truthy in Javascript.

What happens instead?
Both `window.chrome` and `chrome` are `undefined`.

Please provide any additional information below. Attach a screenshot if
possible.
For some of our test cases, this breaks things b/c, as I mentioned above, some things that are supposed to happen on the site are depending on whether `window.chrome` is detected or not.
 
2018-01-26_1150.jpg
113 KB View Download
Components: Internals>Headless
Labels: Needs-Triage-M64
FYI - here's a link to the same issue that I filed over at ChromeDevTools:
https://github.com/ChromeDevTools/devtools-protocol/issues/83

They mention that they'd like to watch what happens here on this issue, and 1 comment points to a portion of the Chromium code that is pulls in the `LoadTimesExtension`, which apparently initially creates the `window.chrome` object.
Cc: sc00335...@techmahindra.com
Components: Platform>DevTools
Labels: Triaged-ET M-66 FoundIn-66 Target-66 Proj-Headless OS-Linux OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on reported version 64.0.3282.119 using Mac 10.13.1,Ubuntu 14.04 and Windows 10. On clicking Yahoo link and typing chrome or window.chrome returned Undefined.

This issue is seen from M60. Hence considering this issue as Non-Regression and marking as Untriaged.

Could someone from devtools team please have a look at this issue.

Thanks!
Status: Available (was: Untriaged)
Given that we don't intend to support extensions in headless mode and there aren't that many other useful things behind the chrome object, I don't think implementing it is a very high priority.
Components: -Platform>DevTools -Blink

Sign in to add a comment