Summary
A date field added through the Shopify Forms app ( Shopify Forms - Capture customer information to grow your marketing list | Shopify App Store ) stops accepting any input on the storefront when the value is typed using the Japanese kana keyboard’s numeric mode (the 12-key / “☆123” layout) on iOS. The field enters a broken state and no further characters can be entered — the only recovery is to reload the page.
The same field works correctly when the digits are typed with the English QWERTY keyboard’s numeric layout, which strongly suggests the problem is in how the field handles IME composition events rather than the digits themselves.
Steps to reproduce
- In the Shopify Forms app, create an inline (or popup) form and add a date field.
- Publish the form to the storefront.
- Open the form on an iOS device with the Japanese kana keyboard enabled.
- Tap the date field, switch the keyboard to numeric mode by tapping “☆123” (12-key layout).
- Type the digits of a date (e.g. 19900101).
Expected behaviour
The digits are accepted and formatted by the field the same way as when typed with the English keyboard.
Actual behaviour
After the first few keystrokes the field enters an inconsistent state and stops accepting input entirely. Nothing further can be typed, and the value cannot be corrected without reloading the page.
Control test
| Input method | Result |
|---|---|
| English keyboard, numeric layout (123) | Works correctly |
| Japanese kana keyboard, numeric layout (☆123) | Reproduces the bug |
| Calendar picker selection | Works correctly |
Probable cause
On iOS, the numeric mode of the Japanese kana keyboard is still handled by the Japanese IME, so it fires compositionstart / compositionupdate / compositionend, and the field receives an unconfirmed (pre-composition) string — which may also contain full-width digits — before the value is committed.
If the date field masks or re-formats value on every input event and writes the result back to the DOM without checking event.isComposing (or without guarding between compositionstart and compositionend), the write-back interrupts the active composition session. The DOM value and the IME’s internal state then diverge, and the field can no longer receive input.
This is a well-known pitfall for CJK input in JS-controlled/masked inputs. The usual fix is to skip the masking/filtering logic while isComposing === true, and apply it once on compositionend.
Environment
- Device / OS: iPhone16e/26.5.2
- Browser: Safari / Chrome for iOS
- Keyboard: iOS Japanese kana keyboard, numeric mode (“☆123”, 12-key layout)
- Store: Shopify Plus, Online Store 2.0 theme
- Form type: inline, date field mapped to customer metafield
- First observed: 2026-08-18
Impact
This affects Japanese-market stores in particular. The 12-key kana layout is the default and by far the most common input method on Japanese iOS devices, so a large share of mobile visitors will hit this the moment they try to type a date. In our case the field is used for a date of birth, so the failure blocks form submission entirely for those users.
Question
Has anyone else reproduced this, and is there a known workaround short of removing the date field? We would also appreciate confirmation from Shopify on whether composition-event handling in the Forms date field is being looked at.
I provide a screen recording of that trouble.