8000 click/type/fill/get-text fail with "Invalid parameters" on v0.37.0, even with a fresh valid ref (regression from #121 fix) · Issue #123 · amirlehmam/wmux · GitHub
[go: up one dir, main page]

Skip to content

click/type/fill/get-text fail with "Invalid parameters" on v0.37.0, even with a fresh valid ref (regression from #121 fix) #123

Closed

Description

@yatran911

Version: wmux.exe 0.37.0 (ProductVersion confirmed via file properties)

Context: #121 fixed the ref_not_found bug caused by the @ prefix mismatch between buildAccessibilityTree and resolveRef. That fix works � the old error is gone. But a new regression appeared in the same command group.

Bug: browser click, browser type, browser fill, and browser get-text all fail with a generic Invalid parameters error, even when called with a ref that was just returned by browser snapshot and definitely exists.

Reproduction:

wmux browser open https://example.com
wmux browser snapshot
# � returns tree with @e1..@e14, e.g. "@e2: heading \"Example Domain\""
wmux browser click e2
# � Error: Invalid parameters

Tested and ruled out as causes:

  • @ prefix / no prefix вÐ�â�� same error with e2 and "@e2"
  • Timing / race condition вÐ�â�� same error even with a 5s delay between snapshot and click; when the ref genuinely doesn't match the latest snapshot, wmux correctly returns a different, honest error (ref_not_found: eN вÐ�â�� the last snapshot has @e1..@eM), so this isn't a "clicked before the tree settled" issue
  • Missing WMUX_SURFACE_ID вÐ�â�� present and correct in the test environment, no effect

Command matrix (same session, same fresh snapshot):

Command Result
browser open OK
browser snapshot OK
browser eval OK
browser wait <ref> OK
browser click <ref> Invalid parameters
browser type <ref> <text> Invalid parameters
browser fill <ref> <value> Invalid parameters
browser get-text <ref> Invalid parameters

Notably wait uses the same ref param as the failing commands and succeeds � so this doesn't look like a client-side param-building issue (the CLI builds {ref: args[2]} identically for all of them per dist/cli/wmux.js). Looks like a server-side validation regression scoped to the interaction/read command group, likely introduced alongside the ref-normalization fix in #121.

Workaround: browser eval with direct JS still works fine, e.g. browser eval "document.querySelector('a').click()".

Activity

  1. amirlehmam commented on Jul 28, 2026

    @amirlehmam
    Owner

    Fixed in v0.38.0. Your triage was right on every point, including that wait succeeding ruled out the client side — thank you, that narrowed it a lot.

    Root cause. Accessibility.getFullAXTree returns AXNodes whose nodeId is an accessibility-tree id — a string — while the DOM handle lives in a separately named integer field, backendDOMNodeId. buildAccessibilityTree read node.backendNodeId (a field AXNode does not have) and fell back to node.nodeId, so every ref carried an AX string into DOM.getBoxModel / DOM.resolveNode, which require an integer.

    Confirmed against a live page rather than by reading code:

    keys: ["backendDOMNodeId","childIds","chromeRole","frameId","ignored","name","nodeId","properties","role"]
    nodeId: "5"   typeof -> string
    backendDOMNodeId: 5   typeof -> number
    
    DOM.getBoxModel { backendNodeId: 5 }    -> {"model":{"border":[0,0,337.33,...
    DOM.getBoxModel { backendNodeId: "5" }  -> {"code":-32000,"message":"Invalid parameters"}
    

    That last line is your error, verbatim.

    Why it looked like a #121 regression. It isn't one — it predates #121 and was simply unreachable. Every ref lookup failed with ref_not_found before any DOM call was made, so the bad id never reached CDP. Fixing the lookup exposed the next bug in the same path, which is exactly why the failure moved but stayed in that command group. wait kept working because it only checks whether a ref resolves; it never touches the DOM. eval and snapshot never take a ref at all.

    What changed

    • Refs now carry backendDOMNodeId as an integer. A hand-built node list using backendNodeId still works, and a plain numeric nodeId is still accepted, so nothing that worked before stops working.
    • click falls back to scrollIntoView + getBoundingClientRect() when DOM.getBoxModel throws — elements with no layout box used to fail here too.
    • fill also dispatches change, not just input; some frameworks ignored the value otherwise.
    • A ref that maps to an accessibility-only node with no DOM element now returns no_dom_node: @e1 (RootWebArea) is an accessibility-only node with no DOM element — pick a ref that maps to one instead of being handed to CDP to fail as Invalid parameters. Generic protocol errors were the thing that cost you the most time here, and that class is now named at the source.

    Regression tests cover the wire format with string ids, assert an AX id can never leak out as a DOM handle, and drive a click end to end asserting DOM.getBoxModel receives an integer. Verified live afterwards: e1/e2/e3 from a real snapshot each resolve, box-model, and read back text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0