A `focus` event listener may change focus from the `focus` event target
and it's not good thing to run content script before dispatching
`eFocus` event via `OnFocus` of the editor classes. Therefore, let's
make `EditorEventListener` restart listening to `eFocus` event and
handle the things which are not referred by web content script after
the `focus` event propagation in the web content.
Unfortunately, this cannot drop `MOZ_CAN_RUN_SCRIPT` from
`TextEditor::OnFocus` nor `HTMLEditor::OnFocus` because selection
listeners may run. However, they should not run web content script.
So, the preprocessing of `eFocus` or `eBlur` event becomes much safer
by this change.
Differential Revision: https://phabricator.services.mozilla.com/D294361
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
This reverts commit 2cd5592148.
Revert "Bug 2035304 - Part 1: Connecting and disconnecting EditContexts. r=dom-core,layout-reviewers,emilio,smaug"
This reverts commit ccb1f6bfb8.
This reverts commit ae69f6c9c6.
Revert "Bug 2035304 - Part 1: Connecting and disconnecting EditContexts. r=dom-core,layout-reviewers,emilio,smaug"
This reverts commit 7c0bd3f1e0.
Although for making the further processing simpler and faster, we always
delete the following invisible things when modifying the preceding
content. However, `www.icloud.com/notes` users the invisible
preformatted linefeed as anchor for the post-processing of inserting
text. Therefore, this patch makes the inserting content handlers stop
deleting preformatted linefeed. However, for minimizing the risk, this
does not make them stop deleting unnecessary `<br>` elements.
Note that different from padding `<br>` element, the invisible
preformatted linefeed appears as a line break in the flattened text
content for IME. Therefore, preserving the linefeed makes IME not
receive unexpected deletion of a line break. It might be better for IME.
Interestingly, the other browsers delete padding linefeed if it's a
padding for current empty block. It seems that they do it before
inserting content. However, this patch does not do that. Perhaps, we
should write a method to prepare to insert content and share it wider
in a follow up bug (bug 2021218).
Differential Revision: https://phabricator.services.mozilla.com/D286202
In the most cases, the scanner users should ignore empty inline
containers so that the behavior should be the default behavior.
Then, the options becomes clearer what the callers can expect.
Differential Revision: https://phabricator.services.mozilla.com/D284963
Perhaps, we should stop using "visible" from the API names because
some API users use the methods while modifying the DOM. Therefore, the
new APIs explain the position of a line break or whether it's
significant or unnecessary from the layout point of view.
This patch adds API to check a line break position which may return
following/preceding block boundary's element and to scan following
block boundary with ignoring unnecessary line break which is done in
some places with calling
`WSRunScanner::ScanInclusiveNextVisibleNodeOrBlockBoundary()` twice.
Additionally, making the extant internal API mainly `HTMLEditUtils`
use the new API to do the correct handling.
Note that this makes `HTMLEditUtils::GetLeafNodeType` return `Ignore`
if the caller does not want invisible things and the node is in
`display:none` element. This change is required to keep passing some
tests whose editing host is `display:inline` and it's followed by
invisible text like `<script>`.
Differential Revision: https://phabricator.services.mozilla.com/D284962
The `AutoTrackDOMPoint` constructor which takes `nsCOMPtr<nsINode>&` and
`uint32_t` is not used anymore. Thus, we can get rid of the mode.
And `FlushAndStopTracking()` should be replaced with
`Flush(StopTracking::Yes)` and align the relatives to use the same
API style.
Differential Revision: https://phabricator.services.mozilla.com/D283634
Similarly, we can implement it with `LeafNodeOptions` to ignore
unnecessary nodes. Then, we can get rid of `WalkTreeOption` and
`WalkTreeOptions` completely.
Differential Revision: https://phabricator.services.mozilla.com/D277524
`WalkTreeOptions` is similar to `LeafNodeOptions` and it's hard to
maintain both of them. Additionally, `LeafNodeOptions` can specify
which type of leaf nodes should be ignored at scanning. Therefore,
`LeafNodeOptions` can be used for them.
Differential Revision: https://phabricator.services.mozilla.com/D277523
`HTMLEditUtils::GetNextContent()` and
`HTMLEditUtils::GetPreviousContent()` are wrappers of
`HTMLEditUtils::GetAdjacentContent()` and
`HTMLEditUtils::GetAdjacentLeafContent()`. The behavior is similar to
`HTMLEditUtils::GetNextLeafContentOrNextBlockElement()` or
`HTMLEditUtils::GetPreviousLeafContentOrPreviousBlockElement()` but
they won't stop at block inclusive ancestor or a block sibling of an
inclusive ancestor. Therefore, we can get rid of them and use the new
and better implementation.
Differential Revision: https://phabricator.services.mozilla.com/D277522
This adds some options which ignore some types of inline elements.
For example, `IgnoreAnyEmptyInlineContainers` is useful to scan previous
or next editable point because Chrome ignores empty inline elements when
deleting from next to an inline element.
`IgnoreInvisibleInlineVoidElements` is useful to scan invisible line
break from end of a block or checking a line break is invisible because
visible inline element makes a line after the last line break. E.g.,
```html
<div>ABC<br><span></span></div>
```
This shows only one line. However,
```html
<div>ABC<br><span style="border:1px solid"></span></div>
```
This shows 2 lines in the `<div>`.
Additionally, renaming the existing `LeafNodeType` values for making
them easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D277520
This reverts commit 5ccf392dce.
Revert "Bug 1998077 - part 6: Reimplement `HTMLEditUtils::Get(First|Last)Child()` and `HTMLEditUtils::Get(Next|Previous)Sibling()` with `LeafNodeOptions` r=m_kato"
This reverts commit 12eb928cb5.
Revert "Bug 1998077 - part 5: Replace the remaining `HTMLEditUtils::Get(Next|Previous)Content()` with new ones based on `Get(Next|Previous)LeafNodeOr(Next|Previous)BlockElement()` r=m_kato"
This reverts commit 58b4243d10.
Revert "Bug 1998077 - part 4: Replace some callers of `HTMLEditUtils::Get(Next|Previous)Content()` with `HTMLEditUtils::Get(Next|Previous)LeafContentOr(Next|Previous)BlockElement()` r=m_kato"
This reverts commit dd46967eb4.
Revert "Bug 1998077 - part 3: Add new options to ignore empty/invisible leaf nodes r=m_kato"
This reverts commit ca50a4a628.
Revert "Bug 1998077 - part 2: Add `WSType::EmptyInlineContainerElement` r=m_kato"
This reverts commit 4a5d93d631.
Revert "Bug 1998077 - part 1: Make `HTMLEditUtils::IsVisibleElementEvenIfLeafNode` work better if primary frame is available r=m_kato"
This reverts commit b42dc9d35f.
Similarly, we can implement it with `LeafNodeOptions` to ignore
unnecessary nodes. Then, we can get rid of `WalkTreeOption` and
`WalkTreeOptions` completely.
Differential Revision: https://phabricator.services.mozilla.com/D277524
`WalkTreeOptions` is similar to `LeafNodeOptions` and it's hard to
maintain both of them. Additionally, `LeafNodeOptions` can specify
which type of leaf nodes should be ignored at scanning. Therefore,
`LeafNodeOptions` can be used for them.
Differential Revision: https://phabricator.services.mozilla.com/D277523
`HTMLEditUtils::GetNextContent()` and
`HTMLEditUtils::GetPreviousContent()` are wrappers of
`HTMLEditUtils::GetAdjacentContent()` and
`HTMLEditUtils::GetAdjacentLeafContent()`. The behavior is similar to
`HTMLEditUtils::GetNextLeafContentOrNextBlockElement()` or
`HTMLEditUtils::GetPreviousLeafContentOrPreviousBlockElement()` but
they won't stop at block inclusive ancestor or a block sibling of an
inclusive ancestor. Therefore, we can get rid of them and use the new
and better implementation.
Differential Revision: https://phabricator.services.mozilla.com/D277522
This adds some options which ignore some types of inline elements.
For example, `IgnoreAnyEmptyInlineContainers` is useful to scan previous
or next editable point because Chrome ignores empty inline elements when
deleting from next to an inline element.
`IgnoreInvisibleInlineVoidElements` is useful to scan invisible line
break from end of a block or checking a line break is invisible because
visible inline element makes a line after the last line break. E.g.,
```html
<div>ABC<br><span></span></div>
```
This shows only one line. However,
```html
<div>ABC<br><span style="border:1px solid"></span></div>
```
This shows 2 lines in the `<div>`.
Additionally, renaming the existing `LeafNodeType` values for making
them easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D277520
Technically, the document can have no element, e.g.,
```js
document.documentElement.remove();
```
And it should work even if it's destroyed because "Select All" should be
able to work even without `HTMLEditor`. Therefore, this makes the
method stop using `GetRoot()` which requires `mRootElement`.
Finally, I checked the behavior when there is no element on Chrome.
Then, `document.execCommand("selectAll")` succeeded and returned `true`.
However, they don't touch `Selection` actually. It's simple since
there is nothing to do. Let's follow their behavior.
Differential Revision: https://phabricator.services.mozilla.com/D276800
For making the implementation is for which editor, the method should be
a pure virtual function and `TextEditor` and `HTMLEditor` implement it
as they needed.
Additionally, it should return `Result` to avoid the caller to use
fallback IME state even temporarily.
Differential Revision: https://phabricator.services.mozilla.com/D274386
Once the editor is destroyed while dispatching `beforeinput` event,
e.g., by a reframe of the text control frame, `AutoEditActionDataSetter`
marks "the editor has destroyed during my lifetime". Then, nested
`EditAction`s always fail because the parent `AutoEditActionDataSetter`
thinks the editor is not available.
However, the editor can be reinitialized immediately. Then, the nested
`EditAction`s should work (note that it does not mean that another user
input is handled, `AutoEditActionDataSetter` is used by some query
methods too). Therefore, this patch adds a new `bool` member to store
whether the editor is initialized again.
I think we could reset `mEditorWasDestroyedDuringHandlingEditAction`,
but I'm afraid to do that because it forgets the destroyed thing
completely and some features may need to abort handling something even
if the editor is restored since the editable nodes are recreated.
Therefore, this patch adds a new `bool` member for making this change
safer and anybody can access the details of the state.
Differential Revision: https://phabricator.services.mozilla.com/D271559
It's not required explicitly to specify
`BlockInlineCheck::UseComputedDisplayStyle` and
`BlockInlineCheck::UseComputedDisplayOutsideStyle` to `WSRunScanner`
too. And it should take an `EnumSet` for making it easier to maintain
the class in the future.
Differential Revision: https://phabricator.services.mozilla.com/D270117
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
The serializer needs to make each mailcite starts from head of a line.
However, mailcite may be a blocked `<span>`. So, its preceding `<br>`
is not required from the HTML point of view, but we need to preserve
it for the serializer.
If we need this hack in some other places, we should make
`HTMLEditUtils::GetFollowingUnnecessaryLineBreak()` aware of this
special handling in a follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D266751
In the historical reason, some of them still take `nsINode*`. In these
days, converting from `nsINode` to `nsIContent` or `Element` is faster
than before and most callers already use `nsIContent`. Therefore, we
should make them take `const nsIContent&`.
Only some methods, allowing callers use pointer makes them simpler.
Therefore, only some methods have overloads which take
`const nsIContent*` instead.
Differential Revision: https://phabricator.services.mozilla.com/D265525
In the historical reason, some of them still take `nsINode*`. In these
days, converting from `nsINode` to `nsIContent` or `Element` is faster
than before and most callers already use `nsIContent`. Therefore, we
should make them take `const nsIContent&`.
Only some methods, allowing callers use pointer makes them simpler.
Therefore, only some methods have overloads which take
`const nsIContent*` instead.
Differential Revision: https://phabricator.services.mozilla.com/D265525
Leo Tenenbaum