Add support for browser & context options via config

[vigneshshanmugam]

There are lot of ways we can configure the Playwright Browser and the context that is used to creating page objects in Playwright.

1. Browser launch options - chromium.launch(options) - https://playwright.dev/docs/api/class-browsertype?_highlight=launch#browsertypelaunchoptions

   • This would let us control the browser with timeouts, headless, sandbox, slowMo and also browserName in the future - Add slowMo flag for playwright #169

2. Browser Context options - browser.newContext(options) - https://playwright.dev/docs/api/class-browser#browsernewcontextoptions

   • These options allow for ignoreHttpsError, Throttling, Offline emulation, device emulation etc - Add ignoreHTTPSError option on journeys and CLI #171 Emulate device type (UA String and Viewport) #209

To make it easier for users, We can introduce new flags in the synthetics.config.ts instead of adding CLI option for each and every config out there in the playwright.

This Proposal is as allow configuring browser and context options to the synthetic config in addition to the existing params support.

{
import {devices} from "playwright-chromium"

export default env => {
  return {
    params: {
      url: 'non-dev',
    },
    browser: {
      ...// browser options
    },
    context: {
      ...devices['Pixel 5'] // uses chromium
    }
  };
};
}

We could also merge them under playwrightOptions instead of separating them out and provide a validation that allowss only a restrictive list of options to keep things cleaner as well.

import { devices } from 'playwright-chromium';

export default env => {
  return {
    params: {
      url: 'non-dev',
    },
    playwrightOptions: {
      ignoreHttpsError: true,
      slowMo: true,
      timeout: 1000,
      ...devices['Pixel 5'],
      screenshots: true, // validate and throw error as we capture it ourselves
    },
  };
};

@andrewvc @paulb-elastic Thoughts?

[andrewvc]

All these options should be overridable from heartbeat via flags etc.

[andrewvc]

We also need to think about the fleet UI for them

[vigneshshanmugam]

Was thinking to mirror them in heartbeat.yml, something like pwOptions or browserOpts like how we do params. Another thing we can do from the heartbeat side is to create a synthetics.config.ts a temp file we can invoke for each test that would reduce the need of passing CLI args to the synthetic runner.

[paulb-elastic]

I agree, having these options available to pass in gives us the flexibility to add config options as and when supported by newer versions of Playwright, without having to support them with specific params in HB/Synthetics.

Does it makes sense to initially have these as free form configuration options in the Fleet UI, and then add specific UI (e.g. checkbox) for some of these (e.g. ignore HTTPS errors, or device emulation), or will this create too much of a migration problem (mixed up config JSON and 'tick boxes'?

Maybe they are available like params are if you use heartbeat.yml in the first instance (nothing in Fleet), and then we add specific capabilities into the Fleet UI over time (e.g. device emulation etc.), as we view that configuration in the result UI as well (e.g. show the device type against the result).

/cc @drewpost @liciavale