224425 2021-04-12 02:12:23 -0700 setSelectionRange() on blur re-focuses input element 2021-04-13 01:49:40 -0700 1 1 1 Unclassified WebKit HTML Editing Safari 14 All All RESOLVED WONTFIX P2 Normal --- 1 apple webkit-unassigned akeerthi megan_gardner rniwa wenson_hsieh oldest_to_newest 1749161 0 apple 2021-04-12 02:12:23 -0700 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? 1749162 1 apple 2021-04-12 02:16:11 -0700 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'. 1749553 2 rniwa 2021-04-12 23:24:17 -0700 This is behaving correctly. In WebKit, focus follows selection so if you modify selection, then the focus will be moved there. 1749586 3 apple 2021-04-13 01:30:08 -0700 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. 1749587 4 apple 2021-04-13 01:31:01 -0700 See https://github.com/mozilla/pdf.js/pull/13232 for more details. 1749594 5 rniwa 2021-04-13 01:49:40 -0700 (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.