fix: Replaced classLoader in DriverJar

[ArcticFoox]

@yury-s
In some environments, such as Docker or the sbt plugin, accessing the ContextClassLoader is not reliable.
Because the driver package is bundled within the JAR, class.getClassLoader() is used instead.

issues: #1447 , #1803

[yury-s]

Since we could not reproduce it before, can you add a test that demonstrates the bug and that the fix actually resolves it?

[ArcticFoox]

Ok, I will try it

[ArcticFoox]

Hi, @yury-s
In our internal project, we use Playwright to take a screenshot asynchronously using CompletableFuture when Open Graph tags are not found on a given page. This setup works fine locally.

However, when running the same code inside a Docker container, the following issue occurs:

Thread.currentThread().getContextClassLoader() returns null
This causes failures when attempting to load resources (e.g., getResource(...)).

After investigation, I found that switching to:

this.getClass().getClassLoader()
resolves the issue both locally and in the Docker container.

To help reproduce and compare the issue, I’ve created a sample repo here:
👉 https://github.com/ArcticFoox/driverJar-test

You can build the Docker image using the included Dockerfile and test the endpoints:

http://localhost:8080/playwright?url=https://google.com (uses Thread.currentThread().getContextClassLoader())

-> You can check the error log in the console when accessing this endpoint.

http://localhost:8080/playwright2?url=https://google.com (uses this.getClass().getClassLoader())

This is my first open source contribution, so I’d appreciate any feedback or suggestions!

Thank you 🙇

[yury-s]

The test has quite some logic which make it not obvious wether the problem is in the test or in Playwright. Can you try to reduce it to a minimal example and drop all unrelated logic? Ideally it would be converted into one of the Playwright tests.

If the setup requires a custom environment (e.g. spring framework), you can put it in its own project. There is already a bunch of custom tests in the tools/ directory, particularly this one. You could convert yours into a similar one.

We also run Docker tests for our container on GitHub Actions: https://github.com/microsoft/playwright-java/actions/workflows/test_docker.yml. If the test requires Docker environment, we can run the new test inside the Playwright Docker image as part of the same test suite. Would that work?

Given that this PR change the core part of the project, I'd really like to have a test that covers it.

[ArcticFoox]

Sure, I’ll go ahead with that.

[ArcticFoox]

Hi, @yury-s
Not sure if this is the right approach, but I created a new test-classloader package under the tools directory for this.

The test consists of two approaches:
1. The first attempts to load the resource using Thread.currentThread().getContextClassLoader(),
2. and the second uses com.microsoft.playwright.impl.driver.jar.DriverJar.class.getClassLoader().

To verify the behavior in the Docker environment, I followed the test_docker.yml setup:
• Built the Docker image using utils/docker/build.sh --arm64 noble playwright-java:localbuild-noble
• Then ran the container via:

CONTAINER_ID="$(docker run --rm -e CI --ipc=host -v $(pwd):/root/playwright --name playwright-docker-test -d -t playwright-java:localbuild-noble /bin/bash)"

java -jar /mypath/playwright/tools/test-spring-classloader/target/test-spring-classloader-1.50.0-SNAPSHOT.jar

As a result, the first approach failed with an error, while the second one succeeded, confirming the issue.
Additionally, here’s the link to my repo with a minimal reproduction of the issue: https://github.com/ArcticFoox/driverJar-test

[ArcticFoox]

@microsoft-github-policy-service agree