[Li-john1021]

Summary

Fixes #440.

bsk fill already treated every <input> as a cheap candidate, but the live preflight only allowed text|search|tel|url|email|password|number. Date-like controls were rejected with target_not_fillable.

Chrome's Input.insertText also leaves date / time / datetime-local / month / week empty, so typing alone cannot work even if the preflight were loosened.

This change:

• Allows those five types in FILL_EDITABLE_FUNCTION
• Assigns the browser-sanitized value via the HTMLInputElement value setter (and still dispatches input / change)
• Rejects invalid values the same way as number (fill_value_invalid)
• Keeps checkbox / radio / range / file out of fill
• Notes the supported date-like types in SKILL.md

Happy to adjust naming or coverage if maintainers prefer a narrower set.

Test plan

• vitest fill.test.ts + interaction.test.ts (210 passed)
• Chrome fill.browser.test.ts native-controls suite with BSK_FILL_CHROME (96 passed, including the five date-like targets and remaining rejects)
• Manual CDP check: Input.insertText stays empty on date-like; value setter + events succeed; invalid strings normalize to ""

[iuyo5678]

I tested this in Chrome and found two cases that need fixing:

1. A successful background fill can be overwritten when the tab becomes active.
   The new setter path skips the existing deferred-focus handling and follow-up checks. I reproduced a fill of 2026-10-14 returning success, then switching to the tab triggered the page’s pending focus handler, which reset the value to 2026-01-01. The date-like path should also flush deferred focus events and recheck the target before assigning the value.

2. Fields inside Shadow DOM update without notifying listeners on the host.
   Calling the value setter doesn’t generate a native input event, and the synthetic event dispatched afterward lacks composed: true. The field shows the new value, but the host listener never runs, leaving application state unchanged while fill reports success. I reproduced this with all five new input types. The input notification needs to cross the shadow boundary.

Could you fix these two cases and add browser regression tests? The existing tests pass; these scenarios just aren’t covered yet.

[Li-john1021]

Thanks for catching these — both should be fixed in 31cf7b4:

1. Background overwrite — the date-like value path now flushes deferred focus with the same Input.dispatchKeyEvent + follow-up focus/editability recheck used before typing, then assigns the sanitized value afterward so a later tab activation cannot replay a pending focus handler over the fill.
2. Shadow DOM — the fill input / change notifications now use composed: true so listeners on the host see the update.

Added unit coverage for both, plus Chrome regressions under date-like fill regressions (background tab activate + the five date-like types in Shadow DOM). Happy to adjust further if anything still looks off.

[NianJiuZst]

Review: Approve ✅

Thanks @Li-john1021 for the original implementation and for addressing the first round of feedback (deferred-focus flush and composed: true input events). On top of that, four follow-up commits fix the remaining issues found during review. Summary:

1. afdc5a6 — fix(fill): preserve background date input state

• Problem: Clearing a date-like input (--value "") in a background tab skipped the deferred-focus flush, and an empty expected value was never written back. A page focus handler that ran later (e.g. on tab activation) could restore the old value after fill had already reported success.
• Fix: The value-write path now flushes deferred background focus for every date-like fill, including clears, and always assigns the expected value, even when it is empty, so a focus handler cannot bring back a value that was just cleared.
• Tests: Unit tests plus Chrome regressions for all five types ("keeps a background <type> clear after deferred focus and tab activation").

2. 05127ff — fix(vom): expose date inputs as fillable references

• Problem: Chrome exposes these controls with accessibility roles (Date, DateTime, InputTime) that VOM did not treat as interactive. Date-like inputs therefore never got a @eN ref, and agents could only target them with CSS selectors.
• Fix: packages/vom/src/render.ts now renders date-like <input> elements and makes them referenceable. It skips nodes that have no role, are presentational, or are marked unaddressable.
• Tests: VOM render tests per type and role. A Chrome end-to-end suite observes and fills each type by ref in the main document, open shadow root, closed shadow root, and iframe.

3. fce6cad — fix(fill): flush background focus before empty text fills

• Problem: The same deferred-focus race also hit text inputs, textareas, and contenteditable elements. An empty fill sends no insertText, so nothing flushed pending focus events in a background tab, and a later focus handler could overwrite the cleared field.
• Fix: On the insert path, empty fills now check readiness and flush deferred background focus before clearing. If deferred focus moves away from the target, the fill fails with fill_focus_lost and leaves the field untouched.
• Tests: Unit tests and a Chrome regression ("does not clear a background text input when deferred focus moves away").

4. 7500107 — fix(fill): reject --no-clear and enforce min/max for date-like inputs

• Problem:
  • --no-clear on a date/time input joined the two values as strings (2026-10-14 + 2026-10-15). The result was always invalid and produced a misleading "invalid value" error.
  • Values outside the input's min/max were accepted and reported as successful, leaving the control in an :invalid state.
• Fix:
  • Date-like inputs now always replace their value. --no-clear is rejected with fill_value_invalid before the target is focused, and the code that was only reachable through it is removed.
  • Values are checked against min/max using the browser's own range validity, which also handles reversed time ranges such as min="22:00" max="02:00". Out-of-range values are rejected before focus, and the error names the bounds.
  • Skill docs are updated to match.
• Tests: Chrome regressions for --no-clear rejection with no side effects, out-of-range rejection for all five types (including the reversed time range), and in-range and inclusive-bound fills.

Verification

• CI is green on 7500107, including the real-Chrome fill.browser.test.ts suite (168 tests).
• Locally: 3546 extension unit tests pass; biome check, tsc --noEmit, and the eval corpus validation are clean.
• The branch is up to date with main and has no conflicts.

The fill flow for date-like inputs is now correct for the foreground, background, Shadow DOM, and iframe cases, and agents can target these inputs by ref. LGTM — approving. Recommend squash merge, since the branch has 8 commits including a merge commit.