Created attachment 428433 [details] Minimal repro Steps to reproduce: 1. Go to https://bl.ocks.org/nolanlawson/raw/c7d8ed3d43dbb4a018fb392467fae365/ 2. Click the text input with a mouse 3. Try to type letters on the keyboard Expected: The input receives the keypresses and show them. Actual: The input remains focused, but it isn't able to receive keypresses, and the cursor no longer blinks. Details: This issue is reproducible in Safari and Chrome, but not Firefox. It's also reproducible in Safari Technology Preview 124 (Safari 14.2, WebKit 15612.1.11.10).
For the record, I filed the same bug on Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1208631
This is sort of expected since in WebKit, all typing goes to where the selection is, and Range in this case isn't representing any position inside the input element. We should probably be clearing the focus in this case, however.
Thanks for the feedback. Since this didn't repro in Firefox (or IE11 incidentally), I assumed it was a WebKit/Blink bug. My assumption as a web developer is that clearing a Selection of its Ranges and then adding those same Ranges back would be a non-destructive action. If that's not the case, then is there a way to formulate this as a bug to file on Firefox? Something like "When `selection.removeAllRanges()` is called, focus should be cleared"? It's not clear to me from the spec how to phrase this: https://w3c.github.io/selection-api/#dom-selection-removeallranges
<rdar://problem/78231107>
I am able to reproduce this bug in Safari 15.6 / TP 150 on macOS 12.5 and I am unable to type in input field. It is same with Chrome Canary 106 while Firefox Nightly 105 allows to type in the field. Just wanted to update status. Thanks!
I am able to reproduce this bug in WebKit ToT (260854@main) with Live Range Selection API enabled as well. Just wanted to confirm that it still exist.