chore: exercise atoms against Angular-rendered DOM - #536
Conversation
…atic fixtures Mirrors appium#535's React fixture with a zoneless standalone Angular component (text/checkbox/select/radio/OTP-autofocus/disabled/conditional-style/submit, plus @if/@for control-flow blocks that add/remove real DOM nodes). Mounting uses provideZonelessChangeDetection since zone.js's global patching fights Node's test runner; tests flush change detection explicitly via tick(). Exercising clear() against it surfaced a real gap: it only fired a 'change' event, never 'input', so frameworks that bind to 'input' for live updates (Angular, Vue, vanilla — React is the outlier, also treating 'change' as an input-changed signal) never saw a cleared field. Fixed to fire input events too, matching how a real user's select-all + delete behaves. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every it() in react.spec.ts/angular.spec.ts repeated the same mount + patchLayout() + unmount-tracking boilerplate. Move it into beforeEach/ afterEach so each test only contains the interaction it's actually checking. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mykola-mokhnach
changed the title
| // then 'change' once the field loses focus. Frameworks bound to 'input' for live updates (most | ||
| // of them — React is unusual in also treating 'change' as an input-changed signal) never see | ||
| // the clear without it. | ||
| fire(element, EventType.TEXTINPUT); |
There was a problem hiding this comment.
Could we omit the textInput event here and keep only input?
Clearing via select-all + Delete is a deletion operation, while the UI Events algorithm only emits the obsolete textInput event for text insertion—not deletion. Dispatching it here could trigger legacy insertion handlers in addition to the correct input handler.
It would also be useful to add an event-sequence assertion covering this behavior.
Reference: https://w3c.github.io/uievents/event-algo.html#fire-key-input-events
--
I got comment the above by Codex. I'd like to double check if this is vald
There was a problem hiding this comment.
Good catch, and confirmed valid. This codebase already draws exactly that insertion-vs-deletion line elsewhere: updateOnBackspaceOrDelete() in atoms/src/core/keyboard.ts (the real backspace/delete handler) fires only INPUT, never TEXTINPUT, while updateOnKeyPress() (character insertion) fires both. Clearing is a deletion, so it should follow the same pattern as backspace/delete, not the insertion path. Will drop the TEXTINPUT line from clear() and add an event-sequence assertion.
clear() fired 'textInput' before 'input'/'change', but per the UI Events spec that event is scoped to text insertion, not deletion — clearing is a deletion. keyboard.ts's updateOnBackspaceOrDelete() already draws this same line for real backspace/delete keystrokes (input only, no textInput); clear() should follow it too, not the insertion path's event set. Found via PR review: appium#536 (comment) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
## [17.0.7](v17.0.6...v17.0.7) (2026-08-13) ### Miscellaneous Chores * exercise atoms against Angular-rendered DOM ([#536](#536)) ([9399ac1](9399ac1))
|
🎉 This PR is included in version 17.0.7 🎉 The release is available on: Your semantic-release bot 📦🚀 |
2 participants
Mirrors #535's React fixture with a zoneless standalone Angular component (text/checkbox/select/radio/OTP-autofocus/disabled/conditional-style/submit, plus @if/@for control-flow blocks that add/remove real DOM nodes). Mounting uses provideZonelessChangeDetection since zone.js's global patching fights Node's test runner; tests flush change detection explicitly via tick().
Exercising clear() against it surfaced a real gap: it only fired a 'change' event, never 'input', so frameworks that bind to 'input' for live updates (Angular, Vue, vanilla — React is the outlier, also treating 'change' as an input-changed signal) never saw a cleared field. Fixed to fire input events too, matching how a real user's select-all + delete behaves.