Enforce 1 BrowserContext per iteration

[ka3de]

As part of the modifications to be made in order to integrate k6-browser more into the k6 "ecosystem/APIs", we should enforce the usage of a single "concurrent" browser context per iteration. Any interaction requiring more than one active browser context per iteration should be reorganized in order to take advantage of k6 scenarios features.

This issue should address:

• Limit browser implementation to hold for a single browser context.
• Remove exposed methods to create new browser contexts.
• Expose a new method in order to configure the iteration's browser context.

One possible outcome for the JS API that addresses these changes would be:

import { browser } from 'k6/x/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
            type: 'chromium',
        },
      },
    },
  },
};
  

export default async function () {
  // Note: If set, Browser Context must be set before
  // creating any new page. If not set, the page will
  // use the default Browser Context options
  browser.setupContext({
    isMobile: true,
    viewport: {
      'width': 768,
      'height': 1024,
    },
  })

  const page = browser.newPage();

  // Note: Uncommeting this would produce an error like:
  // "browser context can only be initialized once per iteration"
  // browser.setupContext({
  //   isMobile: false,
  // });

  try {
    await page.goto('https://test.k6.io/')
  } finally {
    page.close();
  } 
}

Tasks

Beta Give feedback

1. Can we setup properties on the fly (such as context;grantPermissions) with all context properties?
2. Limit browser implementation to hold a single browserContext PR
3. Prevent more than one context from being created in a single iteration PR
4. Expose a new method in order to configure the iteration's browser context only when the iteration starts.
5. Remove exposed methods to create new browser contexts. PR
6. Update Type Definitions Issue PR
7. Update k6-docs PR

[ankur22]

When creating a new browserContext, we have optional options that we can set to change the behaviour to suite our needs. Some of these options can be set after the browserContext has been created. It would make this change simpler if we could set the options after the browserContext was set, rather than only allowing the options to be set during setup. This would be a better model for working with our new approach where we only allow the creation of a single browserContext per iteration,.

First, we need to explore each of the options and whether these can be changed after the browserContext has been created:

Key
🟢 -- method exist on browserContext or page to change the property after creation.
🟠 -- there's currently no way of changing the property, but it looks possible.
🔴 -- cannot change the property once set.

Option	Notes
setBypassCSP	🟠 Could be done after creation. A new method needs to be created where setBypassCSP cdp command is called on each page
colorScheme	🟢 Can be set via page. emulateMedia. Will need a new method to apply for the whole context.
deviceScaleFactor	🟠 Could be done after creation. A new method needs to be created where setDeviceMetricsOverride cdp command is called once.
extraHTTPHeaders	🟢 Can be set via page. setExtraHTTPHeaders. Need to implement context.setExtraHTTPHeaders to apply to the whole context.
geolocation	🟢 browserContext.SetGeolocation
hasTouch	🟠 Could be done after creation. A new method needs to be created where setTouchEmulationEnabled cdp command is called once.
httpCredentials	🔴 We cannot update this after it has been set for the origin.
ignoreHTTPSErrors	🟠 Could be done after creation. A new method needs to be created where setIgnoreCertificateErrors cdp command is called once.
isMobile	🟠 Could be done after creation. A new method needs to be created where setDeviceMetricsOverride cdp command is called once.
javaScriptEnabled	🟠 Could be done after creation. A new method needs to be created where setScriptExecutionDisabled cdp command is called once.
locale	🟠 Could be done after creation. A new method needs to be created where setLocaleOverride (and possibly WithAcceptLanguage) cdp command is called once.
offline	🟢 browserContext.setOffline
permission	🟢 browserContext. grantPermissions
reducedMotion	🟢 Can be set via page. emulateMedia. Will need a new method to apply for the whole context.
screen	🟠 Could be done after creation. A new method needs to be created.
timezoneID	🟠 Could be done after creation. A new method needs to be created.
userAgent	🟠 Might be possible after creation, although requests could also be cached. A new method needs to be created.
viewport	🟢 Can be set via page. setViewportSize. Will need a new method to apply for the whole context.

Conclusion

Due to httpCredentials being cached by the browser, we feel that we cannot avoid the setupContext method.

[ankur22]

We've reanalysed this issue and we've come to the conclusion that we probably don't want to restrict the browserContext or change the APIs too much. What we have agreed on is:

1. We're going to allow the user to create a browserContext , close it, and create a new one in the same iteration (so sequentially have more than one browserContext per iteration, but not concurrently).
2. We're not going to rename NewContext to SetupContext.
3. I need to work on a "cleanup" PR to remove/amend APIs that don't make sense now.
4. We will NOT merge in PR #937 and probably close it if after a suitable period we're happy with the current behaviour.