Skip to content

Fix: autosubmit dropped when modifier keyup follows a character keyup#1284

Open
jaroslavlibal wants to merge 1 commit into
contributte:masterfrom
jaroslavlibal:autosubmit
Open

Fix: autosubmit dropped when modifier keyup follows a character keyup#1284
jaroslavlibal wants to merge 1 commit into
contributte:masterfrom
jaroslavlibal:autosubmit

Conversation

@jaroslavlibal
Copy link
Copy Markdown
Contributor

Problem

After typing into a data-autosubmit filter input, running Ctrl+ACtrl+X (releasing Ctrl between) leaves the grid filtered to the old value — submitForm never fires on the now-empty input. Ctrl+V afterwards puts pasted text in the input but the filter still doesn't re-run. Holding Ctrl down throughout avoids it.

Cause

Each shortcut ends with a Control keyup right after the character keyup. The skip-keys predicate sits inside the debounce() wrapper, so the debounce keeps resetting and ends up firing for the Control event. isInKeyRange returns true for multi-char named keys after ae9e9be / c9835f1, the handler early-returns and submitForm never runs. Same shape also affects Tab and Arrow keys arriving after a character keyup.

Fix

Move the skip predicate out of debounce(), into the listener. Modifier and nav keyups no longer reset the debounce timer, so the pending character keyup's submit fires as intended. isInKeyRange itself is untouched.

Also bind Enter to immediate submit, no debounce wait.

Verification

Live-tested in our project with browser-side keyup instrumentation. With the fix the debounce stays anchored to the character keyup and submitForm runs.


¹ The skeleton demo at https://examples.contributte.org/datagrid-skeleton/filters/ doesn't reproduce the bug only because its deployed composer.lock pins ublaboo/datagrid to dev-master @ bf8b0e0 (pre-regression), even though composer.json is ^7.2. Fresh composer install of the skeleton today resolves to v7.2.0 and reproduces.

² Side note: package.json's version field is 7.1.0 on the v7.2.0 tag (and 6.9.2 on v7.0.0). Looks like releases don't bump it.

@codecov
Copy link
Copy Markdown

codecov Bot commented May 13, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.79%. Comparing base (e5faff0) to head (d398d38).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1284   +/-   ##
=======================================
  Coverage   46.79%   46.79%           
=======================================
  Files          53       53           
  Lines        2729     2729           
=======================================
  Hits         1277     1277           
  Misses       1452     1452           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Move the skip-keys predicate out of the debounce wrapper so a late
modifier or nav keyup can't overwrite the pending submit's target event
and silence submitForm. Also let Unidentified through the predicate —
virtual keyboards dispatch it. Bind Enter to immediate submit.
@jaroslavlibal
Copy link
Copy Markdown
Contributor Author

Force-pushed an expanded version of the fix: testing on mobile revealed a second autosubmit regression with the same root cause — virtual keyboards (e.g. Android Chrome / Gboard) dispatch keyup with e.key === "Unidentified" and keyCode === 229, which after ae9e9be lands in isInKeyRange's "named keys are always in range" branch and gets the predicate to skip every submit on mobile.

Added Unidentified to the Backspace/Delete escape list in assets/utils.ts — same semantic ("real input value change, must trigger autosubmit"). Predicate-outside-debounce + Enter-immediate changes are
unchanged.

@radimvaculik
Copy link
Copy Markdown
Member

@jaroslavlibal Could you fix CI?

@jaroslavlibal
Copy link
Copy Markdown
Contributor Author

Hi @radimvaculik , those errors come from master and I'd rather not touch them - I don't have enough context to judge whether the instanceof guards or the IPresenter::class lookup are load-bearing in scenarios I'm unaware of, and I don't want to silently regress something.

I can probably drop those instanceof checks and switch the lookupPath to \Nette\Application\UI\Presenter::class, but without the context I can't tell whether that would break something.

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.

2 participants