The different points are, whether it checks in a given element or not, and
whether it ignores non-editable content. Therefore, this patch adds new
`LeafNodeType` and new ancestor limiter argument.
The new flag is not handled in the other methods which take `LeafNodeType`
because there is no test.
Differential Revision: https://phabricator.services.mozilla.com/D115123
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
I realized that it's used only by the dead path because the only caller,
`EditorBase::BeginningOfDocument()` is overridden by `HTMLEditor` and
is never called.
Differential Revision: https://phabricator.services.mozilla.com/D115117
This must make the callers of `HTMLEditUtils::IsVisibleBRElement()` and
`HTMLEditUtils::IsInvisibleBRElement()` easier to read.
Depends on D114933
Differential Revision: https://phabricator.services.mozilla.com/D114934
When I review patches, sometimes I saw wrong usage of `!IsVisibleBRElement()`.
It means that it's an invisible <br> element **or** non-<br> element node,
but developers may think it checks whether it's an invisible `<br>` element
or not without checking the specifying content is a <br> element.
For avoiding this, there should be `IsInvisibleBRElement()` too.
Depends on D114932
Differential Revision: https://phabricator.services.mozilla.com/D114933
editor.pastedTransferable cannot insert image/png when using nsITransaferable.
Although pastedTransferable stores DataTransfer in stack, when mime type is
image/png, DataTransfer fetches all data in
DataTransferItem::FillInExternalData then stores it as `KIND_FILE`.
It means that nsIInputStream in nsITransferable is already EOF.
So we should use InsertFromDataTransfer when internal data moves to
DataTransfer.
Differential Revision: https://phabricator.services.mozilla.com/D114702
The testcase hits the assertion because `CreateNodeTransaction::DoTransaction()`
returns error, but it's not handled by `HandledInsertParagraphInParagraph()`
so that we should make `InsertBRElementWithTransaction()` and its callees
should return error if they meet unexpected cases.
Depends on D113471
Differential Revision: https://phabricator.services.mozilla.com/D113472
This changes the logic of `HTMLEditor::GetFirstEditableLeaf()` and
`HTMLEditor::GetLastEditableLeaf()`, but it shouldn't change actual behavior
because the case is that the first/last child of `aNode` is not in editing
host but editable.
Differential Revision: https://phabricator.services.mozilla.com/D113282
If the editor instance is a `TextEditor`, the root element has to be
anonymous `<div>` element and it has only one text node when it has non-empty
value. Therefore, if it's in `TextEditor`, the method does not need to use
the complicated APIs for finding a text node from the anonymous `<div>` element
or padding `<br>` element since it can adjust the given point into the text
node without such API.
Differential Revision: https://phabricator.services.mozilla.com/D113240
Only the user is `EditorBase::BeginningOfDocument()` which is used by both
`TextEditor` and `HTMLEditor`. However, if it's a `TextEditor`, expected
result is only the first text node only when there is one. Therefore, we can
move it into `HTMLEditUtils` and make `EditorBase::BeginningOfDocument()`
find the text node by it self. Then, we can get rid of using
`EditorBase::GetEditorType()` in this case.
Differential Revision: https://phabricator.services.mozilla.com/D113239
They are instance members of `EditorBase` only for referring editor type and
editing host. Therefore, we can make them static with making them take
editor type and ancestor limiter as arguments.
Depends on D113236
Differential Revision: https://phabricator.services.mozilla.com/D113237
The following patches will get rid of inline wrapper methods of them.
Therefore, they shouldn't be called as "internal". And they return
`nsIContent*` instead of `nsINode*` so, `Get*Content()` is better name for
them.
Depends on D113229
Differential Revision: https://phabricator.services.mozilla.com/D113230
So, the meaning is reverted of this action. But with this change, the scanner
methods scans any nodes by default. This is simpler to understand from the
callers.
Depends on D113228
Differential Revision: https://phabricator.services.mozilla.com/D113229
Before moving them from `EditorBase`, they should take only one option argument
whose type is an `EnumSet` class.
Note that I wanted to name each option for optional behavior, but
`FindAnyDataNode` requires to revert the its meaning (I.e., only with this
patch, `true` should be set an option). Therefore, the following patch renames
it.
Differential Revision: https://phabricator.services.mozilla.com/D113228
Like the other browsers, we shouldn't allow to user modify content in
`<select>` element. Note that this case won't occur with moving caret
with input devices. This occurs only with Selection API.
FYI: Chrome deletes `<select>` element if children of it are selected,
but it's odd behavior since user don't see where is selected visually
and may cause unexpected data loss (i.e., deleting `<select>` element).
Perhaps, we should investigate the behavior in other replaced elements
like `<textarea>` etc in follow up bugs.
Depends on D112513
Differential Revision: https://phabricator.services.mozilla.com/D112517
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
Masayuki Nakano
Makoto Kato
Matt Woodrow
Alexandru Michis