Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Chrome flag --user-agent not being respected

See original GitHub issue

Bug

Lighthouse CLI doesn’t make requests with the useragent specified using the configuration options, ex --chrome-flags="--user-agent=lighthousebot" as seen from outbound network traffic.

Steps to reproduce

Run your network sniffer/inspector tool.
Run the following command lighthouse --output json --chrome-flags="--user-agent=lighthousebot" https://pwa.rocks/ > run1.json
Inspect the GET request for https://pwa.rocks/ in the tool launched in step 1.

Current behavior?

Useragent value is Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MRA58N) AppleWebKit/537.36(KHTML, like Gecko) Chrome/66.0.3359.30 Mobile Safari/537.36

Additionally, the JSON report shows the useragent as lighthousebot

Expected behavior?

Useragent request header should have the value lighthousebot.

Environment Information

Affected Channels: CLI
Lighthouse version: 2.9.4
Node.js version: 3.10.10
Operating System: Win10, Win Server 2016, macOS High Sierra Version 10.13.4
Chrome version: Version 66.0.3359.181 (Official Build) (64-bit)

Issue Analytics

State:
Created 5 years ago
Comments:13 (4 by maintainers)

Top GitHub Comments

3reactions

wildlyinaccuratecommented, May 25, 2020

Resurrecting this old thread because I think there are perfectly valid reasons to want device emulation (throttling, viewport) with a custom user-agent (getting around bot detection with a whitelisted UA modifier).

Keep in mind once you start changing user agent it can become clear to the site that you’re not mobile anymore 😉 things may not work as intended.

This seems to be the primary reason for LH trumping the UA on emulated tests. Would it be fair to say that passing in Chrome flags is an indication that the user knows what they’re doing? Webpage issues from a custom UA feel like an “expected” (or at least manageable) outcome. Chrome flags being ignored feels unexpected, and as far as I can tell doesn’t have any manageable workaround.

1reaction

patrickhulcecommented, Jun 11, 2018

Hm, I’m not sure just that caveat has a place at the moment, but if you want to add a “configuring chrome” doc or something that has some FAQs about common flags like --headless, this pitfall, our default flags, the full list of available flags, etc, I think that’d be really great!

Top Results From Across the Web

Set Chrome policies for users or browsers - Google Support

Enrolled browsers to enforce policies when users open Chrome browser on managed Microsoft Windows, Apple Mac, or Linux computers. Signing in is not...

User-Agent reduction - Chrome Developers

User-Agent (UA) reduction is the effort to minimize the identifying information shared in the User-Agent string which may be used for ...

Intent to Deprecate and Freeze: The User-Agent string

We want to freeze and unify (but not remove) the User Agent string in HTTP requests ... Google properties) being broken in some...

Chrome ignores autocomplete="off" - Stack Overflow

A user agent may allow the user to override an element's autofill field name, e.g. to change it from "off" to "on" to...

306104 - master_preferences not respected in Chrome 30

Chrome will create a new profile in step 3. Could you attach a copy of that profile's preferences file (~/.config/google-chrome/Default/Preferences)? Settings ...