Chromium

This flag is no longer necessary on Linux or macOS. It will become unnecessary on Windows as soon as https://crbug.com/chromium/729961 is fixed.

Ah sweet.
Can you help me find what crrev this was made unnecessary on Linux and Mac? AFAIK it's needed on stable, just want to update documentation. :)

It was this one: https://chromium-review.googlesource.com/522068, i.e., M61: https://storage.googleapis.com/chromium-find-releases-static/d99.html#d99a9664c873fc38e226e33bc92da974fb852da3

Any updates on this for Windows?

Nope, sorry, still on my backlog.

Any updates so far for Windows ?

[Empty comment from Monorail migration]

Do you have the optimal settings we should be running headless chrome on Windows, Linux, Mac etc? I have been copying what I see in Puppeteer and running that on Windows with the remote debugging port and ip binding added in. Then using the devtools socket to control it. But you guys probably know the optimal flags / settings we should be using when launching it. Perhaps even variations to make certain aspects better such as screen shot or as we do mostly to generate PDF's. Thanks!

I current run with these settings on Windows:
--headless --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --disable-background-networking --disable-background-timer-throttling --disable-breakpad --disable-client-side-phishing-detection --disable-default-apps --disable-dev-shm-usage --disable-extensions --disable-features=site-per-process --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --disable-translate --metrics-recording-only --no-first-run --safebrowsing-disable-auto-update --enable-automation --password-store=basic --use-mock-keychain --user-data-dir=.\temp --hide-scrollbars --mute-audio

Note that the 0.0.0.0 binding is probably unsafe but needed as of a week ago ; some windows security update is blocking communication to the WS socket when chrome dev tools binds to 127.0.0.1 by default

Since https://bugs.chromium.org/p/chromium/issues/detail?id=729961 is fixed, should we assume that `--disable-gpu` is no longer necessary on Windows as well?

`--disable-gpu` seems to be still necessary on Linux inside a Docker container:

chrome_cmd=(
    google-chrome
        # --disable-gpu
        --no-sandbox
        --no-first-run
        https://google.com
)

$ docker run --rm \
    --network host \
    --volume ~/.Xauthority:/root/.Xauthority:ro \
    --env DISPLAY \
    cypress/browsers:node12.6.0-chrome77 \
    "${chrome_cmd[@]}"

...
libGL error: MESA-LOADER: failed to retrieve device information                                      
libGL error: unable to load driver: i915_dri.so                                                      
libGL error: driver pointer missing                                                                  
libGL error: failed to load driver: i915                                                            
libGL error: failed to open drm device: No such file or directory                                    
libGL error: failed to load driver: i965
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
[35:35:1214/153301.681608:ERROR:gl_context_glx.cc(227)] Couldn't make context current with X drawable.
[35:35:1214/153301.681753:ERROR:gpu_info_collector.cc(78)] gl::GLContext::MakeCurrent() failed

+Ken, any chance you could triage this bug?

This is predicated on having GPU acceleration available on all of headless Chrome's platforms per https://crbug.com/chromium/765284.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Closing as obsolete, since this flag is currently not required. This remains internally as an implementation detail on certain platforms (e.g. Fuchsia), but should not be a concern for the end user.

That still doesn't invalidate the usefulness of #3:
> 3. Can we make it unnecessary? Basically, if we're in --headless and no libobmesa is found, then we proceed as if --disable-gpu is set?

Surely dynamically adjusting to the lack of presence of that library is superior to explicit statement of such, even if this is solely relevant internally.

This issue was migrated from crbug.com/chromium/737678?no_tracker_redirect=1

[Monorail blocked-on: crbug.com/chromium/729961, crbug.com/chromium/765284]
[Monorail components added to Component Tags custom field.]