-
Notifications
You must be signed in to change notification settings - Fork 6.8k
fix(slide-toggle): clicks not landing correctly in some cases on Chrome #18285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Any time the slide toggle host receives focus we forward it immediately to the underlying `input` element. This bouncing around of focus seems to interrupt click events in some cases on Chrome. These changes make it so that we only forward focus for events originating from the keyboard or programmatically. Fixes angular#18269.
e52a847
to
c454df5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Sounds reasonable to me. The focus redirection might also explain why the focus origin was wrong for the native input in the past IIRC:
// 1. It can prevent clicks from landing in Chrome (see #18269). | ||
// 2. They're already handled by the wrapping `label` element. | ||
if (focusOrigin === 'keyboard' || focusOrigin === 'program') { | ||
this._inputElement.nativeElement.focus(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to that, did we consider forwarding the focus origin here? (through focusVia
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind changing it if you feel strongly about it. I didn't do it, because there's nothing reacting to different focus origins on the input anyway so it seemed redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it was mostly for sanity. I don't feel strongly about it. Let's just leave it as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…me (angular#18285) Any time the slide toggle host receives focus we forward it immediately to the underlying `input` element. This bouncing around of focus seems to interrupt click events in some cases on Chrome. These changes make it so that we only forward focus for events originating from the keyboard or programmatically. Fixes angular#18269.
This is along the same lines as angular#18285 since the radio button and slide toggle have a very similar setup. Whenever the radio button host receives focus we forward it immediately to the underlying input, but this bouncing around of focus could cause clicks to be interrupted in some cases. These changes make it so that we only move focus if the host was focused by the keyboard or mouse.
This is along the same lines as #18285 since the radio button and slide toggle have a very similar setup. Whenever the radio button host receives focus we forward it immediately to the underlying input, but this bouncing around of focus could cause clicks to be interrupted in some cases. These changes make it so that we only move focus if the host was focused by the keyboard or mouse.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Any time the slide toggle host receives focus we forward it immediately to the underlying
input
element. This bouncing around of focus seems to interrupt click events in some cases on Chrome. These changes make it so that we only forward focus for events originating from the keyboard or programmatically.Fixes #18269.