Evaluate default browser flags differences with Playwright

[ka3de]

After the removal of a few deprecated flags as default for chrome browser, a few differences were observed between Playwright's implementation and k6 browser. We should consider and evaluate the impact of these differences:

Flags only present in PW:

• disable-field-trial-config: Disable field trial tests configured in fieldtrial_testing_config.json
• disable-back-forward-cache: Disables the BackForwardCache feature (avoids surprises like main request not being intercepted during page.goBack()).
• disable-component-update: Avoids unneeded network activity after startup.
• allow-pre-commit-input: Allows processing of input before a frame has been committed. TODO(schenney): crbug.com/987626. Used by headless. Look for a way not involving a command line switch.
• disable-client-side-phishing-detection: -> Deprecated.
• disable-sync: -> Deprecated.
• export-tagged-pdf: -> Deprecated.

Flags only present in k6 Browser:

• no-startup-window: Does not automatically open a browser window on startup (used when launching Chrome for the purpose of hosting background apps).
• no-sandbox: Disables the sandbox for all process types that are normally sandboxed. Meant to be used as a browser-level switch for testing purposes only.
  -> I'm particularly concerned on why do we use this flag. (?) -> Replaced by Remove --no-sandbox as default browser flag #813

Additionally. There is a difference in the value set for the disable-features flag, as PW includes a few functionalities extra to be disabled compared to k6. The diff is:

• DialMediaRouteProvider
• AutoExpandDetailsElement
• CertificateTransparencyComponentUpdater
• AvoidUnnecessaryBeforeUnloadCheckSync
• Translate

Possible replacements:
There is also a consideration in regards of the deprecated flag disable-client-side-phishing-detection. As mentioned in the chromium project issue, we should evaluate the usage of safebrowsing-enable-enhanced-protection by default as a replacement for its functionality.

Related: #771.

[ankur22]

An observation I've made while working on Dockerizing a browser is:

1. I can't seem to run a browser under a new user in a Docker container, which leads to
2. If running a browser as root, the browser will not start under root unless --no-sandbox is added.

My assumption then is that --no-sandbox has been added as a default to overcome issues where the browser was being started under root. I tried running a browser on my local machine as my own user (not root) and I was able to to start it without --no-sandbox.

[inancgumus]

@ankur22

Yes, I've noticed Playwright does something similar. See this for more information.

By default, the Docker image will use the root user to run the browsers. This will disable the Chromium sandbox which is not available with root. If you run trusted code (e.g. End-to-end tests) and want to avoid the hassle of managing separate user then the root user may be fine. For web scraping or crawling, we recommend to create a separate user inside the Docker container and use the seccomp profile.