-
Notifications
You must be signed in to change notification settings - Fork 392
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
fix(engine): prevent focus events when engine manages focus #1116
Conversation
This comment has been minimized.
This comment has been minimized.
bded9ce
to
d0f659b
Compare
This comment has been minimized.
This comment has been minimized.
@@ -302,20 +321,14 @@ function keyboardFocusInHandler(event: FocusEvent) { | |||
const post = relatedTargetPosition(host as HTMLElement, relatedTarget); | |||
switch (post) { | |||
case 1: // focus is probably coming from above | |||
if ( | |||
isFirstFocusableChildReceivingFocus && | |||
relatedTarget === getPreviousTabbableElement(segments) |
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.
Looks like this change is the cause of the IE11 test failure.
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.
getPreviousTabbableElement
is unreliable here since focusout
is dispatched on the previous tabbable element before this focusin
handler executes and the state of the DOM may change (e.g., the previously tabbable element is no longer tabbable). It seems that this check here is mainly to handle the case where the application focus enters the document? I'm not sure we can support both scenarios and I'm also not sure which scenario should take priority.
Benchmark resultsBase commit: lwc-engine-benchmark
|
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, this is a clever idea.
Details
Fixes issue #1031. Bubbling focus events (i.e.
focusin
andfocusout
) resulting from our syntheticdelegatesFocus
focus management were causing component event handlers to execute and getting us into an unexpected state. Since engine focus management should be transparent to components we should just mute them.Does this PR introduce a breaking change?