Configurable browser launch options

[danielFesenmeyer]

Hi @orange-buffalo,

it seems like currently the browsers are started with default launch options. Would you accept a PR that supports to specify arbitrary launch options such as slowMo or headless?

I think about adding these launchOptions to the "launch request" and evaluating it here: https://github.com/orange-buffalo/testcontainers-playwright/blob/c8374a5cb7a2c126931098dea7b7fcd1ee1ee6b6/src/main/resources/playwright-server.js#L18

[orange-buffalo]

Hi there,

Yes, we can do that. Initially I was concerned that some of the launch options are not compatible with the container mode, e.g. executablePath, so either we need to maintain a sub-set of options that can be used with both local and container modes, or we allow to fail when incompatible option is passed (and potentially cause users' frustration), or we maintain a blacklist of incompatible options (and provide a user-friendly message instead of later unclear failures); hence delayed implementation of this feature.

Maybe it is also partially driven by the way we implement passing the options throughout the layers.

I am open to proposals here :)

[orange-buffalo]

I was thinking about this request, and so far my conclusions are the following:

• Supporting all options (pass through) would not be a good idea, since many of them make no sense in containerized environment and would only cause confusion as they would not work as intended. If we support this, then only on per-option basis after looking into value of passing particular option into the container.

• Specifically for headless and slowMo, I have doubts in their value when debugging against a container, as developer would not be able to observe the browser by default. It would additionally require something like a VNC server being added to the container, so developer could connect and observe. From my experience with Testcontainers Selenium VNC, it is a pain to connect - either you need to setup static port mapping (and then suffer from port conflicts), or inspect Docker containers after each test launch to grab the exposed port.

• A much more attractive alternative we are using in our teams is to run local browser when developing/debugging tests, which is already supported in this repo by means of LocalPlaywrightApiProvider. Currently it already runs in headed mode for this reason, we could potentially add slowMo, but frankly speaking this is just 65 lines of code that one could easily copy into their project and use instead of this simple implementation, then having full freedom to manipulate the Playwright options during development.

Having said that, I am inclining to close this issue without providing changes. Perhaps if we collect more details about the use cases for this request, we could make a better decision.

[danielFesenmeyer]

@orange-buffalo Thanks for your detailed explanation.

The idea of "slowMo" rather was to have a simple means to check whether a test failure might be caused by timing issues. (Might be the case when the test passes with "slowMo", but fails otherwise.) I wanted to use it for flaky tests, but found another way to handle those in the mean time.