We saw in the past a lot of users reporting issues like this. Maybe a
more readable error helps.
Before they just saw:
```
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'register')
at index.38834ec3.js:1:3775
at index.38834ec3.js:1:4006
```
Fixes https://github.com/microsoft/playwright/issues/27655
- remove `onlyStartedTests` in favor of explicit branch with comments;
- produce one "test not found" error per test instead of a single large
error;
- extract `_failTestWithErrors` from `_massSkipTestsFromRemaining`.
Before this fix, unhandled error during test.fail():
- marks this test as "interrupted";
- fails next test in the file with "fatal error".
After this fix:
- marks this test as "failed as expected";
- restarts worker for the next test.
**Description**
When a language port was using Inspector with the "Locator Picker"
feature, it only recognised JavaScript as a language by default. As a
workaround the user was able to click record, interact with the page and
then the language would be correctly used -> csharp e.g. would work in
the "Locator Picker".
**Why?**
Our language bindings are setting `PW_LANG_NAME=<sdkLanguage>` env var
-> good. Our recorder harness also uses this along its internal state
here:
b9b289b641/packages/playwright-core/src/server/recorder.ts (L369)
and it gets used here (no parameter means: we use the first language
aka. primary language):
b9b289b641/packages/playwright-core/src/server/recorder.ts (L95)
The only issue is that the Inspector frontend in the beginning does not
know which language it should use and pass over to the server side, it
then falls back to JavaScript.
**Proposed fix**
Instead of passing it over from the frontend to the server side, we just
always use it from the server side, aka. "currentLanguage". When the
user switches languages in the frontend, "currentLanguage" already gets
updated properly via the "fileChanged" event.
https://github.com/microsoft/playwright-dotnet/issues/2718
---------
Signed-off-by: Max Schmitt <max@schmitt.mx>
On Linux platforms, specifically check that process.arch is x64, rather
than treating it as 'not arm64'.
Treat Raspbian's /etc/os-release file as Debian.
Document the supported platforms somewhat.
Fixes#27453
This has recently regressed in #27429.
We now continue requests that are paused for the second time. However,
redirects share `networkId` with the original request, so we may confuse
paused redirect with a second pause for the original request.
This is covered by the flaky test `page-route.spec.ts:392 > should work
with redirects for subresources`
References #27294.
