🖱️ Basic Actions — Selenium Comparison

Basic Actions — Selenium Comparison: Playwright actions work like a GPS navigation system's four-layer confirmation protocol: you enter a destination, the system calculates the r

Playwright actions work like a GPS navigation system's four-layer confirmation protocol: you enter a destination, the system calculates the route, confirms the vehicle is moving, and alerts you on arrival — every step involves automatic waiting and verification. So why did Selenium require so much manual waiting code? Selenium works like a taxi meter: it simply relays the command and doesn't wait for an outcome; if the element has entered the DOM but isn't yet interactable, you get "element not interactable" and all responsibility falls on you. In Java, driver.findElement(By.id("btn")).click() crashes if the element exists in the DOM but is hidden or disabled; with Playwright, page.locator("#btn").click() waits on its own until the element is visible, enabled, and in a stable position. The QA reality: in Single Page Application tests, moving to the next action before an API response arrives creates race conditions — the test passes sometimes and fails others. Playwright's built-in actionability checks eliminate that uncertainty.

All Actions — 3-Language Comparison

Micro Lab: Playwright — Locator selection

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

How Many Steps Does fill() Actually Do in One Line?

page.locator('#email') finds the element…

page.locator('#email') finds the element but doesn't touch it yet — Playwright keeps the locator lazy, the actual search is deferred until fill() is called.

fill() runs an actionability check first…

fill() first runs an actionability check: is the element attached, visible, enabled, and past any animation — if any check fails, Playwright WAITS instead of throwing immediately.

The existing input value is CLEARED entirely…

The existing input value is CLEARED entirely — Selenium's sendKeys() does not do this, it appends to the previous value; that's why in Selenium you always had to call .clear() first.

The new text is set on the input in one go…

The new text is set on the input in one go and a real "input" DOM event fires — frameworks like React/Vue update their state because of that event; just changing the value attribute would not be enough.

Before moving to the next line, Playwright…