This patch implements `JoinNodesResult` class which callers of
`JoinNodesWithTransaction()` can access removed node, existing (joined) node and
joined point with logical named accessors, and makes
`JoinNodesWithTransaction()` return it.
Then, the callers don't need to change at fixing bug 1735608.
Differential Revision: https://phabricator.services.mozilla.com/D132120
With this patch, callers of it can handle left and right node logically instead
of assuming that one is split and the other is new one.
Depends on D131748
Differential Revision: https://phabricator.services.mozilla.com/D131749
First, left/right node accessors are not used so that we can get rid of them.
However, we should have similar methods which can retrieve original node and
new node. Therefore, this adds `GetNewContent()` and `GetOriginalContent()`.
Next, `SplitPoint()` should return both `EditorDOMPoint` and `EditorRawDOMPoint`
for avoiding unnecessary conversion from `EditorRawDOMPoint` to
`EditorDOMPoint`. Therefore, this patch makes it a template method too.
Finally, this patch adds helper methods to get point of each related content.
E.g., `AtNewContent()` corresponding to `GetNewContent()`.
Differential Revision: https://phabricator.services.mozilla.com/D131748
It touches the DOM tree only with `SplitNodeTransaction()` and it now returns
`NS_ERROR_EDITOR_DESTROYED` so that the callers don't need to check whether
the editor is destroyed or alive by themselves.
Depends on D131043
Differential Revision: https://phabricator.services.mozilla.com/D131044
For making the code simpler, this patch makes it returns
`Result<nsCOMPtr<nsIContent>, nsresult>` instead of using `ErrorResult`.
This must make the construction faster and callers simpler.
Depends on D130950
Differential Revision: https://phabricator.services.mozilla.com/D131043
It should be treated as `uint32_t` since DOM API does so. However, there are
some exceptions:
* Result of `nsINode::ComputeIndexOf()`
* Result of `nsAString` methods
They return `-1` as not found, and anyway, they cannot treat large integer
than `INT32_MAX`. Therefore, this patch does not touch around them.
Differential Revision: https://phabricator.services.mozilla.com/D118933
Developers may be confused at `IsTextEditor()` and `IsPlaintextEditor()`. When
the latter is `true`, the former is always `true`, but it may be `true` when the
editor is `HTMLEditor` too. So, it's a mode of `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D118246
They may return a descendant, and now `HTMLEditUtils` has some methods whose
name ends with `Child` and they scan only direct children of given node.
So, we should rename these methods for avoiding misunderstanding.
Differential Revision: https://phabricator.services.mozilla.com/D115122
It's hard to understand each caller of `HTMLEditor::IsEmptyNode()` tries to
check with multiple `bool` arguments. Therefore, they should be replaced
with an `EnumSet`.
Note that only the first argument is reverted the meaning. Therefore, if
it's omitted or `false`, `EmptyCheckOption::TreatSingleBRElementAsVisible`
is specified explicitly. Otherwise, i.e., `true`, nothing should be
specified.
Differential Revision: https://phabricator.services.mozilla.com/D112513
It returns true only when it's a text node, but the text is empty.
However, `HTMLEditUtils::IsVisibleTextNode()` is used in
`HTMLEditor::IsEmptyNodeImpl()`. So, we replace it with directly using
`HTMLEditUtils::IsVisibleTextNode()`.
Depends on D112511
Differential Revision: https://phabricator.services.mozilla.com/D112512
When given point is **in** a void element, e.g., this can be when JS inserts
nodes into a void element like `<meta>`,
`HTMLEditor::SplitNodeDeepWithTransaction` may return "not handled" state.
So, it's possible case, we shouldn't assert the case.
This patch adds both WPT and crashtests because I couldn't reproduce it
with WPT's simpler API use.
Differential Revision: https://phabricator.services.mozilla.com/D111231
When the method detects the style coming from a parent block, the `MOZ_ASSERT`
checks whether the current mode is "style with CSS" or not because currently,
`HTMLEditor` does not use `<span>` with CSS when the mode is not "style with
CSS". However, fixing it requires bigger patch, and the change does not match
with the bug's summary. So, I just remove the `MOZ_ASSERT`, add WPT and filed
bug 1649639 for the root issue.
Differential Revision: https://phabricator.services.mozilla.com/D111067
The lifetime of it is guaranteed by `AutoEditActionDataSetter` which grabs
`Selection` until it's destroyed, and it's a stack only class and created
at first step of all public method calls. Therefore, we can mark it as
`MOZ_KNOWN_LIVE` and we can change it returning reference of `Selection`
instead of reference of `RefPtr<Selection>`.
Differential Revision: https://phabricator.services.mozilla.com/D110896
When typing at edge of a link, editor splits the link element at the edge (i.e.,
creating an empty link element). Then, unlink the new link element (i.e.,
clearing the "link style"). At this time, `class` attribute and `style`
attribute are cloned to new `<span>` element for keeping the original style.
However, in this case, other browsers discard the specified style of the link.
On the other hand, when unlinking a link with `execCommand("unlink")`, the
other browsers keep specified style coming from `style` attribute.
Therefore, this patch adds new state to `PropItem`, which indicates whether
the `class` and `style` attribute should be cloned or discarded. And then,
when preparing for inserting text, this patch makes it pass to the utility
method.
For better compatibility, we should stop cloning `class` attribute, but not
in this bug because this patch should be minimized for requesting uplift to
beta channel.
Differential Revision: https://phabricator.services.mozilla.com/D107801
Blink treats each non-editable node as an atomic object. E.g., deleting or
forward-deleting from next to a non-editable element, it deletes only one
non-editable element.
Unfortunately, our layout treat adjacent non-editable nodes as a node.
Therefore, the adding WPTs do not work, but they are not new regression of
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D107587
DONTBUILD because this is a comment-only change and hence doesn't affect
behavior at all.
I ran across this typo in nsPageFrame.cpp, and figured I might as well grep for
it and fix it more comprehensively. And while I'm at it, I also fixed some
neighboring instances of a duplicated word around a linebreak, in
nsXMLContentSerializer.h.
Differential Revision: https://phabricator.services.mozilla.com/D100852
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
Although it starts to return error if it causes destroying the editor, but
it should not occur because it modifies new and orphan node and it shouldn't
kick any mutation event listeners. Therefore, this patch makes the callers
handle error as-is rather than ignoring errors except
`NS_ERROR_EDITOR_DESTROYED`.
Differential Revision: https://phabricator.services.mozilla.com/D87989
The root cause of this bug is a bug of async `ScrollSelectionIntoView` that
is what it won't be canceled even if web app changes scroll position with
any API. Fixing it is really risky and this bug affects an existing website.
Therefore, this patch makes the constructors of `AutoPlaceholderBatch` take
whether do or do not `ScrollSelectionIntoView` when it's destructed. And
makes `HTMLEditor::SetInlinePropertyAsAction()` not request
`ScrollSelectionIntoView` for taking back the traditional behavior.
Note that this patch does not make it an optional argument because it's hard to
guess that it'll run `ScrollSelectionIntoView` automatically.
Differential Revision: https://phabricator.services.mozilla.com/D87819
I realized that there is no word "whitespace" in formal English. This patch
replaces it with "white-space" in comments, and change method names to use
"WhiteSpace".
Depends on D78654
Differential Revision: https://phabricator.services.mozilla.com/D78655
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
This is used by `TextEditor::UndoAsAction()` too, so, it might be better to be
in `EditorUtils`. However, it is completely designed for `HTMLEditor` and
ideally, `UndoAsAction` should be overridden by `HTMLEditor` too and
`TextEditor` should use faster path because of its content is in anonymous
subtree. But we don't have any merit to do that instead of avoiding virtual
call.
Differential Revision: https://phabricator.services.mozilla.com/D74362
It's a virtual method which always returns true if `TextEditor`. Therefore,
we can move it into `HTMLEditUtils` and we can make the only caller of
`EditorBase` check `IsTextEditor()` instead.
Depends on D70880
Differential Revision: https://phabricator.services.mozilla.com/D70882
Actually, they are used only by `HTMLEditor` because `TextEditor` finally
returns `true` for any cases in `TextEditor`, but the users are overridden by
`HTMLEditor` and never used by `HTMLEditor`. Therefore, we cam move them
into `HTMLEditUtils`.
Depends on D70878
Differential Revision: https://phabricator.services.mozilla.com/D70879
A lot of editor code refers `nsINode::IsText()` directly so that we don't
need to keep the too simple editor API anymore.
Depends on D70876
Differential Revision: https://phabricator.services.mozilla.com/D70877
It's only non-`HTMLEditor` user is `EditorBase::JoinNodesDeepWithTransaction()`,
but it's called only by `HTMLEditor`. Therefore, we can move it into
`HTMLEditUtils` and move `EditorBase::JoinNodesDeepWithTransaction()` to
`HTMLEditor`.
Depends on D70875
Differential Revision: https://phabricator.services.mozilla.com/D70876
Due to the include hell, `EditorBase.h` cannot include `EditorUtils.h`.
Therefore we need these 3 methods once. Additionally, `IsModifiableNode()`
is really odd method and looks like that it's used for the following 2 purposes:
1. Simply can be editable.
2. Can be removed from parent.
For the former case, we should sort out it with
`EditorUtils::IsEditableContent()`, but for now, this patch moves it to
`HTMLEditUtils::IsSimplyEditable()`. On the other hand, for the latter case,
we obviously has a bug. Therefore, this patch creates
`HTMLEditUtils::IsRemovableFromParentNode()` and make it check whether the
removing node is also editable.
Unfortunately, `EditorUtils::IsEditableContent()` needs to take editor type.
But it's most callers are in `HTMLEditor` and most of remains are in
common methods of `EditorBase`. I guess we could remove this ugly argument
in the future.
Depends on D70874
Differential Revision: https://phabricator.services.mozilla.com/D70875
Masayuki Nakano