Shim in Playwright

[fcollonval]

Fixes #44

[fcollonval]

As mentioned in the associated issue, the main blocker for now is the absence of page.queryObjects.
I did not dive too much in the tests failing due to that feature missing.

[nolanlawson]

Thank you for the proof-of-concept! I think though, that my statement in #44 (comment) still stands: I'm hesitant to add the complexity of supporting both Puppeteer and Playwright, especially since I'm relying on Chromium-specific APIs, so the value-add of Playwright (as I understand it), which is supporting non-Chromium browsers, does not really apply here.

[fcollonval]

I'm hesitant to add the complexity of supporting both Puppeteer and Playwright, especially since I'm relying on Chromium-specific APIs, so the value-add of Playwright (as I understand it), which is supporting non-Chromium browsers, does not really apply here.

I agree with your statement. I think if it becomes possible in the future, a good way forward could be to split fuite into multiple packages to choose between the web driver tool:

graph TD
    A[Core] --> B[Puppeteer]
    A --> C[Playwright]

Loading

The question of the browser is not really important - this is a requirement (by the way you can use Firefox with Puppeteer but I guess that won't work with fuite neither). But the ability to write scenarios using test helpers from the integration tests is of primary value for us to test JupyterLab.

[nolanlawson]

@fcollonval That's definitely a possibility. Just out of curiosity – from Jupyter's perspective, what is the main benefit of Playwright over Puppeteer, if Chromium is the only supported browser engine under the hood? Removing an additional dependency?

[fcollonval]

The scope of Playwright is broader than Puppeteer as it is an integration tests framework (its competitor is more Cypress than Puppeteer). The nice consequence is a much easier wait of writing scenarios (they have a codegen tool to record actions), more powerful selectors and better tooling to debug scenarios (producing videos, recording a trace to be analyze with a dedicated tool,...).

As we were looking to add integration tests we went for Playwright in Jupyter. And to ease testing, we have created a bunch of helpers (to set the app in a certain state). So the main benefit using Playwright for memory leak analysis would be to ease scenarios writing and maintenance - the plan is to have a recurrent job checking memory leak is not worsen by future changes.

Avoiding the additional dependency is a good side-effect but not the primary reason.

[nolanlawson]

Ah interesting, thanks for the explanation.

Assuming that Playwright supports page.queryObjects someday, I guess it wouldn't be a big deal to support both, as long as we have some kind of well-defined abstraction over both APIs, and Puppeteer is still the default. (Unless there's a good reason to change the default.)

I'm definitely nervous about the added complexity, though. I wonder if eventually it will make sense to refactor fuite into @fuite/core, @fuite/puppeteer, @fuite/playwright, etc. Lots of refactoring, though. 😅

[TylersTech2020]

Hey