Summary: | Restoring selection ranges causes text input to ignore keypresses | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Nolan Lawson <nlawson> | ||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Normal | CC: | ahmad.saleem792, ap, bfulgham, rniwa, webkit-bug-importer, wenson_hsieh | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | Safari 14 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Nolan Lawson
2021-05-12 16:38:09 PDT
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 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. |