r/Playwright

Hello there ! I need some help with filling up a form in chrome as soon as possible. To give you a little bit of context i'm currently trying to get an appointment at the german embassy in sri lanka for my student visa but it's really really hard to book an appointment online. Just after couple of seconds of appointments appearing in the website it gets booked down completely so i want some way to try to book the appointment as fast as possible using some automation. I'm no computer scientist and my computer knowledge is not the best so can anyone tell me how i can automate and get my booking done as soon as possible ? so down below is the website, first you have to fill in the captcha which takes you to the appointment page. There you have to click in the link to fill up the personal details for the appointment. You have to fill in your First name, Last name, Contact no, Passport no, Email and you have to re enter your email in another separate field. and after filling up all the personal details there'll be another captcha similar to the one down below which you have to fill in before submitting the details. You have to do it as quickly as possible because within 1 minute the appointments get booked down (appointments appear exactly on 3.30 am my local time). Can anyone help me out with this please ?

https://preview.redd.it/iciyouawxckh1.png?width=2940&format=png&auto=webp&s=9f6456810b8de46ffab5ef5ca6f83fce89366bcd

Hello,

I am unable to use applications like Opera, Opera GX, Blitz (a gaming app), and Discord; none of them will launch. About a month ago, I was working on projects involving "Antigravity" and virtual Chrome windows—experimenting with and modifying components like Playwright and Chromium. Immediately after doing this, applications like Discord and Opera GX stopped opening entirely. For instance, when I try to launch Opera, it opens and closes four times in rapid succession but fails to actually start. I’ve discovered through research that all these applications rely on Chromium, but despite consulting various AI tools, I haven't been able to resolve the issue. Is there any way to fix this without resetting my computer?

I’m a career changer about 5 years ago hired for manual tester and offered the chance to learn Selenium and Python. Self taught, but created a test suite for the project I manually tested and caught the coding bug. Ended up moving into a PO role last year but my heart is in QA and coding. With the rise of AI, I see a gap where Manual testers can’t keep up with faster dev output and I believe automation fills this gap. Of course, it does. No, the dev team won’t touch automation despite it being the obvious solution. Thats neither here nor there.

I’ve decided I want to return to automation, learn PW, transition the current test suite and fill in the gap. I just need to learn PTS and PW.

I have to much to learn and catch up on. Where do you recommend I start? AI didn’t exist when I was using Selenium. I know a little TS and a little PW, but it’s been a year since I did any automation. I’d love to hear you’re must watch videos, tutorials, blogs, etc. what helped you learn?

I'm experimenting with an AI-driven QA workflow for an enterprise application using Playwright + TypeScript.

The workflow is roughly:

Feed the AI our API definitions + business flow definitions

AI analyzes them and generates a comprehensive API test plan

AI generates executable Playwright API test scripts from that plan

Playwright executes the generated tests

The interesting part is that test plan generation works surprisingly well. Using the business flow (which is the happy path), the AI can identify most of the test scenarios like validation cases, authentication scenarios, boundary cases, etc.

However, I'm running into a major problem at the test script generation/execution stage.

The happy-path tests generally work, but almost all of the other tests fail during execution..

Is anyone here using AI/agents to generate executable Playwright API tests for large/enterprise applications?

I ship a PR review app built on Tauri. Last week a dialog that was green in every test shipped as a header, a clipped search input, and a footer. The body rendered at height zero.

The cause is the flex: 1 shorthand. It expands to flex-basis: 0%, and a percentage basis needs a definite parent height, which an auto-height panel capped by max-height does not have. The spec says the fallback is content. Chromium does that. WebKit keeps the zero.

The part that cost me the evening: Playwright's WebKit is their own recent build, not the WKWebView you actually ship in, and neither engine in my harness reproduced it. Screenshot tests, all green, app broken.

Wrote up the mechanics, the spec citation, and what I changed about testing: https://nodreview.com/blog/wkwebview-flex-collapse/

Fix is flex: 1 1 auto. Curious if anyone has found a CI-friendly way to test against the real system webview, because Playwright clearly is not it.

Has anyone measured the real cost of Playwright +claude? In terms of human time, tokens, gains. Or its just a bubble?

we're having the inevitable conversation:

Cypress is flaky

Playwright is faster

let's rewrite everything

and I keep asking a boring question nobody seems excited to answer:

what exactly are we trying to improve?

because our current failures are roughly:

● selectors tied to implementation details

● shared test data

● random third-party/API delays

● huge setup flows before every test

● tests nobody knows why we still run

● CI workers getting murdered by parallel jobs

Playwright may absolutely improve parts of this.

auto-waiting is better in a lot of cases. multi-tab/multi-context flows are cleaner. browser support

is strong. parallelism model is nice.

but moving:

cy.get('.checkout-button-v4')

to:

page.locator('.checkout-button-v4')

did not modernize anything lol. before rewriting I'd want actual numbers:

flaky failures by root cause

not “Cypress feels flaky”

median/p95 suite time

CI cost

time spent debugging failed runs

locator churn per release

tests requiring capabilities Cypress genuinely handles poorly for us

how many tests are still valuable

that last one is probably the uncomfortable metric.

I suspect if we audited 1,500 tests properly we'd delete 400 before migrating anything.

I've also been thinking about whether framework migration is even the right lever for locator maintenance.

KaneAI/TestMu is interesting here because you can keep the test closer to business intent, use

Reviewable self-healing when UI mappings change, then export/keep code in the underlying

Automation framework where needed.

Not “framework doesn't matter anymore”.

It obviously does.

More like: maybe we shouldn't rewrite a mature suite solely because maintaining selectors sucks.

and self-healing still needs boundaries.

if:

“Continue” moved from one container to another, fine.

if:

“Approve payment” disappeared and the healer found “Cancel payment” nearby...

Please turn the build red and ruin my morning.

I'm not anti-Playwright at all. I'm anti spending six months rewriting a bad test architecture into a newer bad test architecture

Without measuring whether anything actually got better.

People who actually migrated Cypress → Playwright:

What metric improved enough that you can say the rewrite was worth it?

For instance if you need to run a test procedure like a regression test that goes from dashboard, clicks hamburger, then goes to search page searched for a project of record, then clicks time slice and then does only certain test from the test procedure.

What’s the best way to go about this.

My senior engineer gave me an SVG image but when I opened it and saw its XML content then i found it was not a true SVG. It was a PNG image that was encoded into base 64 inside the image tag in XML. So, I told this to my mentor and my mentor said do you have any best mechanism to get HTML Dom into SVG.

He suggested that use playwright or find a mechanism but i didn't get any mechanism.

I would be very happy if you guys help me regarding it.

Coming from a Selenium background, I honestly love Playwright for test development.

Writing tests is faster, debugging is better, auto-waiting is great, and overall the developer experience is much better.

But when it comes to distributed testing at scale, Playwright is painful.

With Selenium Grid, distributing tests across multiple machines feels straightforward. You have a Grid and multiple nodes, and the infrastructure handles the distribution.

With Playwright, once you start running thousands of tests across multiple machines/pods, you have to deal with sharding, uneven test distribution, idle machines, retries, report merging, artifact handling, etc.

Playwright is amazing for writing tests, but distributed execution takes that joy away.

been running claude code for like 3 weeks on a price monitoring agent and i actually like it.. until i wired up playwright mcp

one session yesterday ate through my whole weekly budget and it hadnt even finished checking two product pages?? dumps full page snapshots and accessibility trees into context every step and claude just keeps chewing tokens like its free

tried playwright cli instead thinking mcp was the problem. still brutal. needed like 40 steps to compare prices across 6 sites and i stopped halfway because the api bill was already stupid

also my girlfriend asked why i was yelling at my laptop during dinner which.. fair

browser automation through claude feels like a toy unless youre doing one page and calling it done

Playwright MCP has an --extension mode that attaches to the Chrome you actually use instead of launching a throwaway one. Real profile, real logins, real fingerprint. I checked what the browser reports and there is nothing left to fix: navigator.webdriver is a native false, the UA has no automation token, and the languages, timezone, GPU and core count are all genuinely mine.

A detector still called it a bot, and pointed at exactly 3 signals out of 22:

isAutomatedWithCDP:              true
isAutomatedWithCDPInWebWorker:   true
hasInconsistentTimingResolution: true
every other signal:              false

isPlaywright, hasWebdriverTrue, isHeadlessChrome, hasInconsistentChromeObject, isWebGLInconsistent, hasInconsistentClientHints: all false. Nothing about the browser gave it away. The protocol did.

The two probes

The first is the known console leak. A client with Runtime.enable gets console calls forwarded, and forwarding an Error makes V8 format its stack, which consults Error.prepareStackTrace. So the page sets that hook itself and watches it fire:

let seen = false
const original = Error.prepareStackTrace
Error.prepareStackTrace = function () { seen = true; return original }
console.log(new Error(''))
// seen === true only while something is listening on the protocol

The same test runs inside a web worker, because Playwright attaches to workers too.

The second one surprised me. Despite the name, hasInconsistentTimingResolution has nothing to do with timer granularity, which measured a completely normal 0.1 ms. It recurses 10 to 200 frames deep, times new Error() plus reading .stack, and regresses cost against depth. An inspector collecting full stacks makes that cost grow with depth, and the linear fit gives it away.

Where it comes from

I drove Chrome over raw CDP on scratch profiles so I could enable exactly one thing at a time, and had the page measure itself and POST the result, so the measurement did not need Runtime either. Three samples per row. Low r2 means the cost does not track call depth, which is what an unattached browser looks like.

what was done to Chrome            console   r2 x3               total cost
nothing, plain Chrome              false     0.01 0.00 0.00      0.16 0.17 0.07 ms
debugging port open, no client     false     0.00 0.00 0.00      0.18 0.18 0.15 ms
attached, no domain enabled        false     0.00 0.04 0.03      0.07 0.08 0.05 ms
Runtime.enable                     TRUE      0.35 0.79 0.80      0.94 0.40 0.46 ms
enable, then Runtime.disable       false     0.03 0.00 0.05      0.21 0.18 0.06 ms

So attaching a debugger costs nothing and hides nothing. Runtime.enable causes both signals, and disabling it restores baseline completely. Error.stackTraceLimit is not a way out either: at 0 the slope stays positive, so the inspector's own capture ignores the JS-visible limit.

Fixing it without losing the API

Two parts. An init script that leaves Error.prepareStackTrace alone and instead makes sure no Error object ever reaches the native console binding, so there is no stack to format, prepended into worker blobs as well. Every hook is a Proxy over the native function, so name, length, prototype and toString stay honest.

Then the cause itself. rebrowser-patches is the maintained fix for the Runtime.enable leak and its analysis is what pointed me the right way, but its patcher edits lib/server/chromium/crPage.js and current Playwright ships everything inside one lib/coreBundle.js, so it exits with "cannot find file to patch". I ported their technique 3 by hand: enable Runtime, let the execution contexts announce themselves, disable it again immediately, repeat on every committed navigation.

Worth knowing if you try this yourself: deleting the Runtime.enable call outright breaks 7 of 10 tools. Playwright learns its execution contexts from exactly those events, so evaluate, snapshot, screenshot and console all time out and only navigation survives. The toggle is what keeps the API working.

Result on the finished setup, six page loads out of six, plus a 10-point functional test that matched a stock server on everything except one thing:

You are human!   isBot false, all 22 signals false

The exception: with Runtime off while the page runs, CDP no longer forwards console messages, so browser_console_messages comes back empty. The init script keeps a 300 entry in-page buffer instead.

What this does not touch, since it always comes up: IP reputation, TLS and HTTP/2 fingerprints, behavioural signals, CAPTCHAs. It fixes protocol-level detection and nothing else.

It is all MIT on GitHub, including the script that reproduces that attribution table from scratch on your own machine. Link in the first comment.

Hi everyone,

I’m currently working as a QA Engineer with 1.5 years of experience. In my current project, I work with Playwright + TypeScript for Dynamics 365 CRM UI automation.

I’m planning to move toward an SDET role and would like to understand what SDETs actually do in real-world IT companies.

I’d really appreciate advice from experienced SDETs:

• What does your day-to-day work look like?
• What technical skills are actually expected from an SDET?
• Beyond UI automation, how important are API testing, SQL, CI/CD, Git, Docker/cloud, DSA, and system design?
• Which skills/tools are commonly expected in SDET interviews?
• With around 1.5–2 years of experience, what should I realistically be good at to apply for SDET roles?
• What skills helped you grow into higher-paying SDET positions?

I’m mainly looking for real-world experience and practical advice about the role and skill expectations.

Thanks.