playwright clicks istrusted

Playwright isTrusted: are automated clicks real?

There is a lot of advice about mouse curves, dwell times and typing rhythm, and most of it matters less than one boolean the page can read for free. Before a detector measures how a pointer moved, it can ask whether the event that fired was generated by the user or by a script. That question has a single-bit answer, isTrusted, and it does not care how graceful your Bezier curve was.

This page is about that bit: what it means, why an event a page builds itself can never set it, and why an automated click driven through Firefox with the Juggler protocol comes back with isTrusted=true, exactly like a hand on the mouse.

What isTrusted actually is

Every DOM event carries a read-only isTrusted property. The specification is blunt about it: the flag is true only for events the user agent itself generated in response to real user action or an internal state change, and false for any event created and dispatched by script. It is set by the engine at construction time and there is no setter, no override, no way to reach it from page code.

You can watch it separate the two cases in a few lines:

document.addEventListener('click', (e) => {
  console.log('click isTrusted =', e.isTrusted);
});

// A real click on the element logs: click isTrusted = true
// This logs: click isTrusted = false
document.querySelector('#submit').dispatchEvent(new MouseEvent('click', { bubbles: true }));

The second call does everything a real click does at the DOM level. It bubbles, it hits the same listeners, it looks identical in the handler except for that one property. A detector that reads e.isTrusted in its click or pointer handler is doing the cheapest useful check there is, and any automation that fabricates events in JavaScript fails it on the first interaction.

Why a page-injected event is always isTrusted=false

This is the part that trips up a whole category of stealth approaches. If your automation reaches interactivity by running JavaScript in the page, whether that is a dispatchEvent, a synthetic CustomEvent, or a helper that constructs a MouseEvent and fires it, the engine sees an event constructed by page script and stamps isTrusted=false by definition. There is no configuration that changes this, because the flag is precisely what distinguishes the two origins, and a page cannot be allowed to claim it was the user.

So the moment automation touches the page through injected script, it has already answered the trust question the wrong way, no matter how human the coordinates were. This is why "move the mouse on a curve" advice can be simultaneously correct and beside the point: a beautiful trajectory made of untrusted events is a beautiful trajectory that a one-line handler discards. The two properties are independent, and the boolean is the one checked first.

The correct place to generate input is therefore not the page. It is the browser's own input machinery, the same code path a physical mouse feeds into, reached from outside the page rather than from inside it.

How Firefox and Juggler keep the click trusted

Playwright does not drive Firefox by injecting click scripts. It speaks a control protocol to a patched build, and input requests cross that protocol to be realised by the engine's native event-synthesis path, the same internal machinery that turns a hardware mouse report into a DOM event. Because the event is manufactured by the engine and not by page script, it is a user-agent-generated event, and it carries isTrusted=true.

Two details of that native dispatch are worth naming, because they are what a careful detector looks at next after isTrusted:

• Input source. The synthesized event is tagged as coming from a real mouse device rather than from an unknown or synthetic source. A page reading the pointer type sees a mouse, not a null device.
• Pressure. The event carries a pressure value that moves with button state, the way a real pointer's does, rather than a flat constant that reads as fabricated.

At the event level, which is all a detector can read, the two origins compare like this:

Signal a detector reads	Page-injected JS event	Native driven click (Firefox + Juggler)
isTrusted	false	true
Input source (pointer device)	unknown or null device	real mouse
Pressure	flat constant	moves with button state
Passes the origin check	no	yes

The important consequence for this library is that the humanised motion path and a plain page.mouse.move are not two different mechanisms. The waypoints produced for a human-shaped stroke are handed to the engine with byte-identical arguments to the ones a direct mouse move uses: same native call, same real-mouse input source, same pressure semantics. Nothing about trust is traded away to get the nicer trajectory. A move driven from Python is indistinguishable, at the event level, from one the engine emits on its own, so you get the human shape and the trusted origin at the same time, and the full mechanics of that motion are a separate concern from the trust bit this page is about.

Measuring it yourself

You do not have to take this on faith. The check fits in one script and takes both arms, trusted and untrusted, at once:

from invisible_playwright import InvisiblePlaywright

with InvisiblePlaywright(seed=42) as browser:
    page = browser.new_page()
    page.set_content("""
        <button id="target" style="position:absolute;top:200px;left:200px">click me</button>
        <pre id="out"></pre>
        <script>
          const out = document.getElementById('out');
          document.getElementById('target').addEventListener('click', (e) => {
            out.textContent += 'trusted=' + e.isTrusted + '\\n';
          });
        </script>
    """)

    # Arm 1: a real driven click, through the engine's native input path
    page.click("#target")

    # Arm 2: a page-injected event, for contrast
    page.evaluate("""
      document.getElementById('target')
              .dispatchEvent(new MouseEvent('click', { bubbles: true }));
    """)

    print(page.inner_text("#out"))

The driven click reports trusted=true; the injected event reports trusted=false, from the same handler on the same element in the same session. Because the browser object returned is a real Playwright Browser, every method here is stock Playwright, and the seed makes the run reproducible so you can re-run the exact identity later.

If you want to fold this into a broader check, isTrusted is one line inside the same pointer handler that a full detection-testing method already runs, and it belongs with the other automation-origin tells such as navigator.webdriver rather than with the machine-level fingerprint surfaces.

Where trust stops mattering and other signals start

Trusted events are necessary, not sufficient, and it is worth being honest about the boundary. A click that carries isTrusted=true clears the origin check and nothing else. The engine still has to deliver a plausible sequence, hence why direct hover behaviour once misfired on Windows when waypoints were dispatched inside the hit-target check rather than before it, and why the shape and timing of motion remain their own problem. Above that sits behavioural biometrics proper, and above that the network and the machine.

So the honest ordering is: fabricate events in JavaScript and you lose at the boundary, on a one-bit check, before any of the harder work is even evaluated. Drive them through the engine's native path and you get to have the rest of the conversation at all. A detector watching for the pauses that look like automation, including the timing gaps a debugger introduces, is a real concern, but it is a concern you only reach once the trust bit is already true.

Conclusion

isTrusted is the input question that gets asked first and answered cheapest. A page cannot be allowed to forge it, so any automation that reaches the page through injected JavaScript hands over a false on every event it fires, no matter how human the motion looks. Firefox driven through the Juggler protocol synthesizes input in the engine's native path instead, tagged as a real mouse with real pressure, so the events come back trusted like a hand on the hardware, and the humanised trajectory rides the same call without giving any of that up. Get this bit wrong and the curve does not matter; get it right and the curve is finally worth tuning.

Short answers to the questions that lead here

Do Playwright clicks have isTrusted=true? With Firefox driven through the Juggler protocol, yes: input is synthesized by the engine's native path, so events are user-agent-generated and trusted. Clicks fabricated by injecting JavaScript into the page are always isTrusted=false.

Why is my dispatched event isTrusted=false? Because the flag is set by the engine and means "generated by the user agent, not by page script". Any event you build and dispatch from page code is script-generated by definition, and there is no setter to change it.

Can I set isTrusted from JavaScript? No. It is read-only and has no override. The only way to get a trusted event is to have the browser itself generate it in response to input, which is what a native driven click does.

Does a human mouse curve fix the trust problem? No, they are independent. A perfect trajectory made of injected events is still untrusted. You need both: trusted origin and plausible motion.

How do I check my automation's clicks? Put a listener on the target that logs e.isTrusted, drive a real click, and drive an injected one for contrast. They will read true and false respectively from the same handler.

Is isTrusted enough to look human? It is necessary, not sufficient. It clears the origin check; motion shape, timing, behaviour, network and machine signals are all still separate questions.

Sources

• The WHATWG DOM specification for Event.isTrusted: set at construction, read-only, true only for user-agent-generated events. See also MDN's Event.isTrusted reference.
• The W3C Pointer Events specification: defines pointerType and pressure as attributes of a pointer event, the input-origin details a detector reads right after isTrusted.
• This project's own measurements of the native input path: driven input synthesized as a real mouse with a pressure value, and the humanised motion path passing arguments identical to a plain mouse move through the same engine call.

See also: human mouse movement for the motion the trusted events carry, the hover dispatch bug for what happens when waypoints run inside the wrong check, and navigator.webdriver for the other automation-origin tell in the same family.

---

Written while maintaining invisible_playwright, a Firefox patched at the C++ level driven by stock Playwright. The trust bit is the one input signal that is cheap to check and impossible to fake from the page.