You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
authored
fix(CDPBrowser): support ARIA radiogroups in selectOption, fix waitInUrl message (#5711)
* fix(CDPBrowser): support ARIA radiogroups in selectOption, fix waitInUrl message
The Obscura CI job had 13 failing tests. 12 of them were not Obscura-specific:
they fail identically against Chrome (test/helper/CDPBrowser_chrome_test.js) and
only surfaced here because Obscura is the sole CDPBrowser variant with a CI job.
selectOption had no radiogroup branch (11 failures). Locator.field.labelContains
matches .//*[@aria-label = ...], so the [role="radiogroup"] element was found —
the client's select action then looked only for [role="option"] children and
returned false. It now clicks the [role="radio"] whose accessible name matches,
exact match first (the fixture's "Compact" / "Compact mode" siblings require it),
and lets the widget check it and uncheck the rest. Passing several options
returns a sentinel instead of throwing in-page, so selectOption raises the
"radio group holds one value" error from Node.
waitInUrl reported the resolved absolute URL instead of the part it was given
(1 failure), so the message read "expected url to include http://host/info2".
75f1221 restored the substring matching but left the message resolving.
The 13th is an Obscura/React interop gap with Base UI radios and is skipped with
the reason; Radix and plain radio groups pass on Obscura.
Obscura is bumped to v0.2.2 (version + tarball sha256, install URL, regenerated
docs).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017bdxGACghDuRVjn3hzmdy4
* fix(Obscura): pass --allow-file-access when launching obscura serve
0.2.2 gates DOM.setFileInputFiles behind --allow-file-access, so attachFile
failed with "DOM.setFileInputFiles is disabled" on a self-launched server. The
flag exists in 0.2.0 too, so passing it works against both.
Also drops "file uploads" from the documented limitations: they work, and the
two skipped #attachFile tests are skipped for an unrelated <select multiple>
bug, not for lack of upload support.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017bdxGACghDuRVjn3hzmdy4
---------
Co-authored-by: DavertMik <davert@testomat.io>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments