Bug 224425 – setSelectionRange() on blur re-focuses input element

• Status: RESOLVED
• Resolution: WONTFIX
• Component: HTML Editing

[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?

[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.