Currently, our editor and document viewer manage `Selection` state and
ranges within their `focus`/`blur` event listeners. However, UI Events
defines that the events should be fired after the focus move finished
[1][2]. Therefore, we need to move the handlers to
`EventTarget::PreHandleEvent` or the event listener of the event target
parent of the window (in the capturing phase of the default event group).
Otherwise, a web content's event listener runs before we maintain the
`Selection`. This patch moves the handlers to
`nsGlobalWindowInner::PreHandleEvent`.
Currently, there are 3 event listeners which maintain the `Selection`.
`nsDocViewerFocusListener`:
This maintains the active `nsFrameSelection` and the display of the
last focused selection only when the document node gets focus. This
patch removes this class and move the code into new static methods of
`nsFrameSelection`.
`HTMLEditor::OnFocus`:
This activates the document `nsFrameSelection` and collapses `Selection`
to the focused element if `Selection` ranges are not in the focused
editing host. This does it even if a text control gets focus even though
the focused `TextEditor` will handle the further user inputs.
`TextEditor::OnFocus`:
This activate the independent `nsFrameSelection`.
These handlers run in the following order:
1. `nsDocViewerFocusListener`
2. `HTMLEditor`
3. `TextEditor`
Therefore, `nsGlobalWindowInner::PreHandleEvent` handles all of them
within this order.
Note that `TextEditor::OnFocus` is now called after `HTMLInputElement`
or `HTMLTextAreaElement` prepares the further `change` event
dispatching. After applying this patch, their `PreHandleEvent` will do
that. Then, `nsGlobalWindowInner::PreHandleEvent` will run because
`PreHandleEvent`s are called in the bubbling phase order. Therefore, the
handling order shouldn't be changed.
1. https://w3c.github.io/uievents/#event-type-focus
2. https://w3c.github.io/uievents/#event-type-blur
Differential Revision: https://phabricator.services.mozilla.com/D292335
Masayuki Nakano
52def4ebef