playwright: [BUG] Using libsoup2 and libsoup3 in the same process is not supported.
System info
- Playwright Version: [v1.38.0]
- Operating System: Docker image
mcr.microsoft.com/playwright:v1.38.0-jammy - Browser: [WebKit]
- Other info: The image is ran on circle-ci. The same image as no problem with firefox and chrome browser. We don’t have any issue running the same code locally.
A similar issue exists and is closed : https://github.com/microsoft/playwright/issues/26653 This issue should be fixed with Playwright 1.38.0 but we still have it but only with the safari browser.
If you clone the repo, you should not have any error locally, you can test by running the following command :
$ make bootstrap
$ make e2e
You can also check the result on circle-ci with the following link : https://app.circleci.com/pipelines/github/openfun/marsha/14253/workflows/28f88761-d423-43c1-b4c1-4702c879a09f/jobs/421630
Both libsoup 2 and 3 are indeed installed in this image:
$ docker run --rm -it mcr.microsoft.com/playwright:v1.38.0-jammy /bin/bash -c "dpkg -l | grep libsoup"
ii libsoup-3.0-0:amd64 3.0.7-0ubuntu1 amd64 HTTP library implementation in C -- Shared library
ii libsoup-3.0-common 3.0.7-0ubuntu1 all HTTP library implementation in C -- Common files
ii libsoup2.4-1:amd64 2.74.2-3 amd64 HTTP library implementation in C -- Shared library
ii libsoup2.4-common 2.74.2-3 all HTTP library implementation in C -- Common files
If libsoup2 is removed (just for testing), it also deletes gstreamer plugins that seems used by webkit.
Source code
Link to the GitHub repository with the repro
This commit is part of this PR: https://github.com/openfun/marsha/pull/2433
Expected
The test suite should run without issue with libsoup. Libsoup compatibility issue is fixed with version 1.38.0 and we don’t have this issue with firefox and chrome browsers.
About this issue
- Original URL
- State: closed
- Created 9 months ago
- Reactions: 11
- Comments: 21 (9 by maintainers)
Commits related to this issue
- chore: fix Ubuntu 22.04 WebKit on 20.04 host (#28068) https://github.com/microsoft/playwright/issues/27313 — committed to microsoft/playwright by mxschmitt 8 months ago
We have the same issue in a Jenkins pipeline. We use mcr.microsoft.com/playwright:v1.38.1-jammy as a base image. Using
FROM mcr.microsoft.com/playwright:v1.38.1-jammyRUN apt-get remove -y libsoup2.4in our docker image fixes our problem for now. Not sure if the mentioned gstreamer plugins are actually no problem or if they just aren’t necessary in our concrete use-case. (We also use webkit.)@mxschmitt Thanks for looking into this. If I understand correctly the docker image has a fix, but the issue persists if we run the tests directly on a CI (I’m still seeing this even with v1.40 on CircleCi when running tests inside
cimg/openjdk:17.0-browsers).Will there be a fix for those of us who run tests outside of the playwright docker image?
It gets released as part of 1.40.
Looks like here we fallback here to their default loader which is in-process compared to their out-of-process loader as per here:
out-of-process will then not clash with libsoup version mismatch I believe.
Looks like as per gst_registry_scan_path_level we don’t have much control about which plugins get loaded or not. plugin_loader_create_blacklist_plugin seems too late.
Based on that I see two ways of proceeding:
This seems to solve all the leftover questions.
Ah good find. libgupnp also switched to libsoup3 as of 1.5.0 (dev) / 1.6.0 (stable).
Though just disabling
libgstwebrtcmakes a lot of sense too.I can’t imagine any reason that would matter.
The solution is just using the
soupmodule from GStreamer 1.20 or newer as it detects which version of libsoup is in use and only uses that one. Earlier versions could only be built against a single version, thus breaking anything mixing the other version.Same on Buildkite CI using
mcr.microsoft.com/playwright:latest. So it seems the issue exists even in 1.39 version.No we reproduce it only on circleci.