window.chrome object not available in "headless" mode

[newhouse]

Perhaps this is not the correct place for this (I've also filed this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=806333 but I wasn't sure where to dig in.

I'm finding that when I run my Nightwatch tests with Chrome in "headless" mode, that certain odd tests are failing consistently that pass when run "not in headless" mode. Upon digging in, it appears that the window.chrome and/or chrome objects are not available/present to webpages loaded in "headless" mode.

This is a problem for us because some of the things we test for are dependent on whether or not a User's browser as window.chrome && window.chrome.webstore, which should both be truthy in any version of Chrome, headless or not I would think.

Is this expected behavior? Anything that can be done?

[paulirish]

Let's use your crbug as the canonical issue for this.

Headless is a slightly different embedder of Chromium content than Chrome/Chromium, and one difference is the window.chrome object.
btw, Here's where chrome's content embedder pulls in the LoadTimesExtension which creates the window.chrome object.

[newhouse]

Thanks, @paulirish . Still "triaging" the issue over there. We'll see what happens. I'll update this issue with whatever happens over there.

[paulirish]

FWIW I don't expect it to be fixed anytime soon.

Why do you rely on window.chrome && window.chrome.webstore ? Honestly can't think of a legit reason. It's probably a browser sniff, but it's a bad one and Chrome team is not gonna help you misuse it. :)

(cross-linking the related pptr issue: puppeteer/puppeteer#1026 )

[newhouse]

@paulirish

Automated browser tests we are running check to see if an element reminding the User of our site’s chrome extension is being displayed or not. Our app displays that reminder element based on whether, among other things, the window.chrome.webstore Is truthy or not. The headless tests are not being shown that element as a result, while the non-headless executions are. We offer an in-line install and it requires a call to window.chrome.webstore so we check for it.

I would consider this use case legitimate and this behavior a “bug”.

Currently I have to have our front end code mock it out when running headless chrome. Which is lame.

[JoelEinbinder]

There are no extensions in headless, so having a chrome.webstore property feels wrong. There are lots of ways for Blink to appear in the wild without Chrome.

Mocking window.chrome might be lame, but it’s the same as what we would be doing to fix it on the browser side.

[paulirish]

i suppose the ultimate bug here is that chrome headless doesn't support extensions. people are requesting that, but it'll be some time before that happens (if it ever does).

agree with joel that it doesn't make sense for chrome.webstore.install() to be present if extensions aren't implemented.

i assume it's possible to use nightwatch with a headful chrome? if so, then do that for your extension-dependent tests.

[newhouse]

Thank you both for your responses. That comment was definitely not directed at this (or any other related project), but was certainly poorly phrased. Apologies if it came across as a dig. The fact that it took me basically 1 line of code to go from running headful to headless and have only 1 test fail is a pretty amazing testament to this project, Chromium, and others, for sure.

I was surprised to find this question only asked a handful of times and, IMO, not thoroughly answered, so I started asking around. I'm even on the issue that was linked to this one by Paul. I think there are starting to be others like me that are discovering the ease of running headless Chrome with their testing frameworks, and eventually some of them will also encounter this issue. The fact that you guys are dropping knowledge about which lines of code in the Chromium build creates the window.chrome object, and that extensions don't run in headless, etc, to me is already a win for understanding this issue and where it comes from.

As @paulirish explained earlier and stated more directly just above here, it seems to stem from how Chrome runs headless, and we'll have to wait and see what develops there.

@paulirish Yes, I can definitely work around this in a manner like you suggested and I may just do that. Thanks!

@JoelEinbinder Without it being added to DevTools explicitly (I agree that that feels wrong given what I now know), are there any hooks/configs/options where mocking window.chrome could be done on my end outside of the front-end application code doing a check?

Thanks again to you both

[JoelEinbinder]

Look into how puppeteer does evaluateOnNewDocument: https://github.com/GoogleChrome/puppeteer/blob/master/lib/Page.js#L658

[newhouse]

Latest comment from Chromium team:

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.

Given my naiveté on the underlying subject matter (why no extensions allowed in headless, etc) I'm afraid to touch this issue any more and seems like a "case closed" for me. If anyone here more suited would like to tack on any questions/comments to that issue, please be my guest!

[aslushnikov]

This is a problem for us because some of the things we test for are dependent on whether or not a User's browser as window.chrome && window.chrome.webstore, which should both be truthy in any version of Chrome, headless or not I would think.

@newhouse the absence of window.chrome is an implication of headless architecture.

Chromium consists of layers:

A few things on this diagram are important:

• content layer is the API to build "browsers". So if you're building a browser, you're embedding content.
• Chromium is a browser and a typical content embedder. A lot of Chromium functionality, e.g. extensions and window.chrome, lives in the chrome layer
• headless is, in fact, another browser - a different content embedder. Since extensions are in the chrome layer, they're naturally missing in the headless browser.

Hope this helps.

[newhouse]

@aslushnikov very helpful, indeed. Thank you for providing that insight!