Skip to content
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

Rich Text: Avoid activeElement focus call #20594

Merged
merged 3 commits into from
Mar 2, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 20 additions & 1 deletion packages/rich-text/src/to-dom.js
Original file line number Diff line number Diff line change
Expand Up @@ -302,5 +302,24 @@ export function applySelection( { startPath, endPath }, current ) {
}

selection.addRange( range );
activeElement.focus();

// This function is not intended to cause a shift in focus. Since the above
// selection manipulations may shift focus, ensure that focus is restored to
// its previous state. `activeElement` can be `null` or the body element if
// there is no focus, which is accounted for here in the explicit `blur` to
// restore to a state of non-focus.
if ( activeElement !== document.activeElement ) {
// The `instanceof` checks protect against edge cases where the focused
// element is not of the interface HTMLElement (does not have a `focus`
// or `blur` property).
//
// See: https://github.com/Microsoft/TypeScript/issues/5901#issuecomment-431649653
if ( activeElement ) {
if ( activeElement instanceof window.HTMLElement ) {
activeElement.focus();
}
} else if ( document.activeElement instanceof window.HTMLElement ) {
document.activeElement.blur();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aduth Why was this added? This seems to be causing the IE bug #20598.

Copy link
Member Author

@aduth aduth Mar 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ellatrix If I recall correctly, the idea was that if this logic should not cause a change in focus, and there was no focused element before the selection applied, we should guarantee that there is no focused element after it's applied by calling blur on whichever element is focused at that point.

I'm not able to remember if there was a specific case in mind this was addressing, or if it was only here to deal with the hypothetical technical possibility.

Based on the debugging information from the original pull request comment, I suspect the main fix for Trac#49519 is largely in adding the condition of if ( activeElement ) { (accounting for the fact that activeElement can be null). If that's enough to accommodate all of the current scenarios and fix both Trac#49519 and #20598, then maybe it would be fine to remove this blur call.

}
}
}