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

Description Cetin Sert 2021-04-12 02:12:23 PDT

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?

Comment 1 Cetin Sert 2021-04-12 02:16:11 PDT

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

Comment 2 Ryosuke Niwa 2021-04-12 23:24:17 PDT

This is behaving correctly. In WebKit, focus follows selection so if you modify selection, then the focus will be moved there.

Comment 3 Cetin Sert 2021-04-13 01:30:08 PDT

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.

Comment 4 Cetin Sert 2021-04-13 01:31:01 PDT

See https://github.com/mozilla/pdf.js/pull/13232 for more details.

Comment 5 Ryosuke Niwa 2021-04-13 01:49:40 PDT

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