[Feature]: natively support consoleapi in none debugging scenario

[peteryongzhong]

🚀 Feature Request

Allowing consoleAPIs to be injected programmatically from creating a new browserContext

Example

No response

Motivation

There is no doubt that the playwright consoleAPI is quite powerful. However, right now it is only injected on debugMode being console, which by #36771 could not be used a la carte.

If there is an option in the browserContext to have console APIs injected without setting the debugmode, developers get a wealth set of APIs for free.

[mxschmitt]

Could you help us to understand how you are using the consoleApi? Is it mostly for debugging/development or also when running the tests?

[peteryongzhong]

I am trying to use playwright in an user-interactive environment. One of our use case requires dynamically figuring out the locators strings on the fly based on elements. Debugmode, since it can't be turned off mid way, complicates things quite a bit. For example, it turns off headless and messes with time out a bit more.

This is a pull request for this btw:
#36782

[mxschmitt]

What is a user-interactive environment? Could you help us to understand how this is related to Playwright's end-to-end testing? We'd love to understand the exact user-flow first before exposing a new API. Maybe there are better solutions for it / its not intended like that.

[peteryongzhong]

The user is interacting at the same time as an AI system is interacting with a browser environment. The agent is doing so solely through playwright while the user is interacting by clicking the same UI in an collaborative fashion. The agent needs to understand the nature of the user's interaction through getting the locators.

[Skn0tt]

let's always expose the object, and allow opt-out via PWDEBUG. let's also ensure we don't override any existing playwright object on the window.