**I** think that updating `Selection` of the page should not cause changing focus when a text control has focus because it's done by script, the user may not intended. So, the reported expectation may make users confused. On the other hand, web **can** do it with calling `<input>.blur()` even on Gecko. So, doing `<input>.blur()` from `Selection::NotifySelectionListeners()` may be reasonable. On the other hand, if we actually move focus from focused `<input>`, the behavior is also different from Chrome (looks like that Chrome keeps focusing on `<input>`, just the `<input>` stop handling text input). E.g., `Tab` after `Enter` in the testcase make the following checkbox focused rather than the `<input>` immediately after selected text. So, fixing this could cause another web-compat issue. (I think that we should file a bug of Chromium at least for that `<input>` stop handling text input even though it keeps having focus.)
Bug 1917322 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
**I** think that updating `Selection` of the page should not cause changing focus when a text control has focus because it's done by script, the user may not intended. So, the reported expectation may make users confused. On the other hand, web apps **can** do it with calling `<input>.blur()` even on Gecko. So, doing `<input>.blur()` from `Selection::NotifySelectionListeners()` may be reasonable. On the other hand, if we actually move focus from focused `<input>`, the behavior is also different from Chrome (looks like that Chrome keeps focusing on `<input>`, just the `<input>` stop handling text input). E.g., `Tab` after `Enter` in the testcase make the following checkbox focused rather than the `<input>` immediately after selected text. So, fixing this could cause another web-compat issue. (I think that we should file a bug of Chromium at least for that `<input>` stop handling text input even though it keeps having focus.)