Skip to content

fix: desktop loop refuse to type into a real macOS password field (#5) - #72

Open
bluzername wants to merge 1 commit into
awlevin:mainfrom
bluzername:fix-password-field-guard-desktop
Open

bluzername wants to merge 1 commit into
awlevin:mainfrom
bluzername:fix-password-field-guard-desktop

Conversation

@bluzername

Copy link
Copy Markdown

This fix the second part of #5. The owner comment say it clear:
Field.is_text check role only, and a real macOS password field give
role AXTextField with subrole AXSecureTextField. That subrole was
never read, so the desktop loop had no code-level guard, only the
browser backend did (the secret flag in browser/perceive.py).

What I change:

  • Field (models.py) get a new subrole field (default "", so
    every other adapter and caller still work with no change) and a new
    is_secure property. It is true when subrole == "AXSecureTextField"
    (the real macOS shape) or when role == "AXSecureTextField" directly
    (how OSWorld's simulated tree already report a password field in
    osworld/a11y.py, which is why that path was already safe).
  • macos.py's focused_field() now read AXSubrole from the
    accessibility API and put it on the Field, same way it already
    read role/label/placeholder/value.
  • actions.py's _type_email and _type_text now refuse before
    typing when screen.field.is_secure, same spot as the existing
    "no text field is focused" refusal.

I did not touch windows.py: the issue only talk about macOS and I
could not find how UI Automation report a password field's protected
state in this codebase, so I leave that for a separate issue instead
of guessing.

Tests added in tests/test_actions.py:

  • test_is_secure_catches_a_macos_password_field_by_its_subrole
  • test_is_secure_catches_an_osworld_password_field_by_its_role
  • test_is_secure_is_false_for_an_ordinary_text_field
  • test_type_email_refuses_a_focused_password_field
  • test_type_text_refuses_a_focused_password_field

I check RED first: all 5 fail with AttributeError/TypeError on
the code before my change (no subrole, no is_secure). After the
fix they pass.

Full suite: uv run pytest -q -> 735 passed, 2 skipped, 1 xfailed
(same skip/xfail as before my change). uv run ruff check . and
uv run ruff format --check . both clean.

Fixes #5 (the password-field part; the README part was already
fixed in #9).

…levin#5)

On real macOS a password field give role AXTextField with subrole
AXSecureTextField, so Field.is_text see it as a normal text field and
nothing stop typing into it. The browser backend already had this
guard, desktop loop did not.

This add a subrole to Field, a new is_secure property (true for the
macOS subrole and also for the AXSecureTextField role OSWorld's
simulation use), and make type_email/type_text refuse when the
focused field is secure. macos.py now read AXSubrole so the real
adapter fill it in.

Tests: two new unit tests for is_secure (macOS subrole shape and
OSWorld role shape, plus a negative case) and two for the type_email
/ type_text refusal, all in tests/test_actions.py. Confirmed RED
first (AttributeError / TypeError before the fix), then GREEN.
Full suite: 735 passed, 2 skipped, 1 xfailed. ruff check and ruff
format both clean.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

README says no screenshot is sent, but the final answer includes one; no code-level password-field guard

1 participant