NEW307150
<input type="text"> change event does not fire on blur when tapping outside the input in WKWebView (iOS) 
https://bugs.webkit.org/show_bug.cgi?id=307150
Summary <input type="text"> change event does not fire on blur when tapping outside t...
617549039
Reported 2026-02-06 01:25:34 PST
This behavior makes the standard 'change' event unreliable for form fields in WKWebView, forcing developers to implement workarounds (e.g., manual value comparison on blur). Steps to Reproduce: 1. Create a simple HTML page with the following content: <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> </head> <body style="height: 200vh; padding: 40px; background: #f0f0f0;"> <h3>Test: change event on external tap</h3> <input type="text" id="testInput" placeholder="Type something then tap outside"> <div id="log" style="margin-top: 40px; padding: 12px; background: white; border: 1px solid red; min-height: 200px; font-family: monospace;"></div> <script> const input = document.getElementById('testInput'); const log = document.getElementById('log'); function appendLog(msg) { const time = new Date().toLocaleTimeString(); log.innerHTML += `[${time}] ${msg}<br>`; log.scrollTop = log.scrollHeight; console.log(msg); } input.addEventListener('focus', () => appendLog('focus triggered')); input.addEventListener('input', e => appendLog(`input triggered → value="${e.target.value}"`)); input.addEventListener('blur', () => appendLog('blur triggered')); input.addEventListener('change', () => appendLog('CHANGE triggered (expected after modified + blur)')); // Log clicks outside document.addEventListener('click', e => { if (e.target !== input) { appendLog(`Click detected on ${e.target.tagName || 'body/body content'}`); } }); // Periodic focus check setInterval(() => { const focused = document.activeElement === input; appendLog(`Current focus state: ${focused ? 'Still focused' : 'Lost focus'}`); }, 2000); </script> </body> </html> 2. Load this page in a WKWebView (e.g., a simple iOS app using WKWebView, or any hybrid framework that uses WKWebView). 3. Tap the input field → virtual keyboard appears. 4. Type some text (e.g., "hello"). 5. Tap on the empty space outside the input (e.g., below or above the field) to dismiss the keyboard. 6. Observe the log (both on-screen and in console via Safari Web Inspector). Expected Results: - 'input' events fire during typing. - 'blur' event fires when tapping outside. - 'change' event fires because the value was modified by the user and then blur occurred. Actual Results: - 'input' events fire normally. - 'blur' event may or may not fire (often does not in many test cases). - 'change' event does NOT fire, even when 'blur' is observed or when document.activeElement no longer points to the input. - Keyboard dismisses, cursor disappears, but change event is lost. Regression: This issue has been observed consistently on: - iOS 18.5 (tested on real device / simulator) - iOS 26 (beta or later, same behavior) It is also reproducible in plain WKWebView apps, not limited to hybrid frameworks. Notes / Additional Info: - The problem is not about the standard change event definition (which requires modification + blur); the issue is that the blur → change chain is broken when focus is lost via tap outside the input. - Tapping on another focusable element (e.g. another input) often triggers change correctly. - Pressing the "Done" / "Return" key on the keyboard sometimes triggers it, but tapping blank space does not reliably. - No JavaScript preventDefault(), no event.stopPropagation(), no unusual CSS (position: fixed, etc.) is needed to reproduce. - Workarounds: Listen to 'blur' and manually compare previous value, or use 'input' event for real-time needs. But this should not be necessary for standard HTML behavior. Please let me know if you need a minimal native iOS repro project, video recording, or more configuration details (e.g. WKWebView properties set). Thanks!
Attachments
Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2026-02-13 01:26:10 PST
<rdar://problem/170302301>
Note You need to log in before you can comment on or make changes to this bug.