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
When users input text in the dynamic filter, non-English input methods often require a conversion process (for example, using an IME for Japanese). Currently, if a user presses Enter during the conversion process, the "apply" action is immediately triggered, causing the search to execute before the intended conversion is completed.
It would be highly appreciated if the dynamic filter could differentiate between an Enter key press meant for converting text and one meant for applying the filter. In other words, when text conversion is in progress, pressing Enter should complete the conversion rather than triggering the apply action.
Current workarounds
At present, there is no effective workaround. Users must avoid pressing Enter during text conversion, which is inconvenient and disrupts the expected behavior for non-English input methods.
Screenshots or screen recordings
This video demonstrates that when I type "matsumoto" and press Enter once to convert it into Japanese, the search is executed immediately. Since I only pressed Enter once, I expected that the word "matsumoto" would be converted into the Japanese characters "松本" without triggering a search.
sample_feature_video.mov
Additional context
I understand that having Enter trigger the apply action is very convenient for English input. However, considering global usage and the needs of users who rely on text conversion for non-English input, this behavior can be quite disruptive.
The text was updated successfully, but these errors were encountered:
I've implemented a change that addresses this issue.
With the new global keydown listener, when users are using an IME in dynamic filters, the Enter key event will no longer trigger the "apply" action during composition. This prevents the filter from being applied prematurely when the user is finalizing their input. Below is the relevant code:
/app/javascript/application.js
// Global listener to intercept Enter key events during IME composition.
// This prevents unwanted "apply" actions when confirming input via an IME
document.addEventListener(
"keydown",
(event) => {
// If the key is not "Enter" or IME is not composing, exit early.
if (event.key !== "Enter" || !event.isComposing) return;
event.stopImmediatePropagation();
},
true // Use capture phase to intercept the event as early as possible.
);
Feature
When users input text in the dynamic filter, non-English input methods often require a conversion process (for example, using an IME for Japanese). Currently, if a user presses Enter during the conversion process, the "apply" action is immediately triggered, causing the search to execute before the intended conversion is completed.
It would be highly appreciated if the dynamic filter could differentiate between an Enter key press meant for converting text and one meant for applying the filter. In other words, when text conversion is in progress, pressing Enter should complete the conversion rather than triggering the apply action.
Current workarounds
At present, there is no effective workaround. Users must avoid pressing Enter during text conversion, which is inconvenient and disrupts the expected behavior for non-English input methods.
Screenshots or screen recordings
This video demonstrates that when I type "matsumoto" and press Enter once to convert it into Japanese, the search is executed immediately. Since I only pressed Enter once, I expected that the word "matsumoto" would be converted into the Japanese characters "松本" without triggering a search.
sample_feature_video.mov
Additional context
I understand that having Enter trigger the apply action is very convenient for English input. However, considering global usage and the needs of users who rely on text conversion for non-English input, this behavior can be quite disruptive.
The text was updated successfully, but these errors were encountered: