Issue #2388 - Part 4: Align focus behavior more with Blink/Gecko

This commit is contained in:
Moonchild 2024-01-16 21:45:11 +01:00 • committed by roytam1
commit 4a438e6607

View file

@ -6415,19 +6415,16 @@ Selection::NotifySelectionListeners()
MOZ_ASSERT(!newEditingHost->IsInNativeAnonymousSubtree()); MOZ_ASSERT(!newEditingHost->IsInNativeAnonymousSubtree());
nsCOMPtr<nsIDOMElement> domElementToFocus = nsCOMPtr<nsIDOMElement> domElementToFocus =
do_QueryInterface(newEditingHost->AsDOMNode()); do_QueryInterface(newEditingHost->AsDOMNode());
// Note that don't steal focus from focused window if the window doesn't // Note that don't steal focus from focused window if the window
// have focus. // doesn't have focus. Additionally, when an element gets focus,
fm->SetFocus(domElementToFocus, nsIFocusManager::FLAG_NOSWITCHFRAME); // we usually scroll to the element, but in this case we shouldn't
} // do that because Blink&Gecko don't do this.
// Otherwise, if current focused element is an editing host, it should fm->SetFocus(domElementToFocus, nsIFocusManager::FLAG_NOSWITCHFRAME |
// be blurred if there is no common editing host of the selected ranges. nsIFocusManager::FLAG_NOSCROLL);
else if (!newEditingHost && focusedElement &&
focusedElement == focusedElement->GetEditingHost()) {
IgnoredErrorResult err;
focusedElement->Blur(err);
NS_WARNING_ASSERTION(!err.Failed(),
"Failed to blur focused element");
} }
// Otherwise, we shouldn't move focus since Blink&Gecko don't move
// focus; only the selection range is updated. This is a bit weird but
// it is what it is and we should act the same for parity.
} }
} }