Bug 224425
Summary: | setSelectionRange() on blur re-focuses input element | ||
---|---|---|---|
Product: | WebKit | Reporter: | Cetin Sert <apple> |
Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | akeerthi, megan_gardner, rniwa, wenson_hsieh |
Priority: | P2 | ||
Version: | Safari 14 | ||
Hardware: | All | ||
OS: | All |
Cetin Sert
See https://stackoverflow.com/questions/67055218/set-input-caret-position-on-blur-in-safari-without-refocusing-input
This is unique to Safari.
Is it possible to match the behavior of other browsers?
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Cetin Sert
In https://stackoverflow.com/questions/67055218/set-input-caret-position-on-blur-in-safari-without-refocusing-input (link to minimal playground test)
Safari is the only browser where 'setSelectionRange' interferes with blur (focus loss/change)
'setSelectionRange' traps the user into '#a' in Safari with no way out!
'selectionStart > 0' that I have added helps one escape on second attempt.
Is it possible to make 'setSelectionRange' behave like other browsers i.e. not interrupt / mess with 'blur' / 'focus loss/change'.
Ryosuke Niwa
This is behaving correctly. In WebKit, focus follows selection so if you modify selection, then the focus will be moved there.
Cetin Sert
Mr. Niwa!
Thank you for your reply.
I have sent a pull request to Mozilla/PDF.js to switch from 'setSelectionRange(0, 0)' to 'scrollLeft = 0' and have long patched it in my own project. We can consider this issue resolved if WebKit project does not deem it necessary to match 'setSelectionRange(0, 0)' behavior with other browsers.
Cetin Sert
See https://github.com/mozilla/pdf.js/pull/13232 for more details.
Ryosuke Niwa
(In reply to Cetin Sert from comment #3)
> I have sent a pull request to Mozilla/PDF.js to switch from
> 'setSelectionRange(0, 0)' to 'scrollLeft = 0' and have long patched it in my
> own project. We can consider this issue resolved if WebKit project does not
> deem it necessary to match 'setSelectionRange(0, 0)' behavior with other
> browsers.
Yeah, I saw that :) Thanks for reporting the bug anyway.