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.

Sign up for GitHub

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

Jump to bottom

Rich Text: Avoid activeElement focus call #20594

Merged
merged 3 commits into from
Mar 2, 2020
Merged

Rich Text: Avoid activeElement focus call #20594

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
def8a8a
Rich Text: Avoid activeElement focus call
aduth Mar 2, 2020
e56b9b4
Rich Text: Restore focus, accounting for null activeElement
aduth Mar 2, 2020
1c5d3eb
Rich Text: Verify activeElement instanceof HTMLElement
aduth Mar 2, 2020
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
14 changes: 13 additions & 1 deletion packages/rich-text/src/to-dom.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -302,5 +302,17 @@ 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 ) {
if ( activeElement ) {
activeElement.focus();
} else {
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 •
edited
Loading

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.

}
}
}