Of course, they are used for `HTMLEditor` instances too. Therefore, they
should be in `EditorBase` rather than `TextEditor`.
Depends on D115789
Differential Revision: https://phabricator.services.mozilla.com/D115790
It calls only its helper method, and the helper method,
`IsCopyToClipboardAllowedInternal()`, needs to check complicated things only
when it's a password editor.
This patch makes `IsCopyToCLipboardAllowedInternal()` a virtual method. But
this shouldn't cause performance regression because this should be called
only when updating menu items or handling "copy" commands. So, this shouldn't
be in any hot paths.
Depends on D115788
Differential Revision: https://phabricator.services.mozilla.com/D115789
They just work with a transaction manager and transactions, and they are used
by both `TextEditor` and `HTMLEditor`. Therefore, they should be in
`EditorBase` for making `HTMLEditor` stop inheriting `TextEditor` in the
future.
Depends on D115787
Differential Revision: https://phabricator.services.mozilla.com/D115788
Currently, `EditorBase::GetDocumentIsEmpty()` is implemented by `TextEditor`,
and it refers only `IsEmpty()` which is implemented both by `TextEditor` and
`HTMLEditor`. So, `IsEmpty()` should be a virtual method of `EditorBase`,
then, `EditorBase` can implement `GetDocumentIsEmpty()`.
Depends on D115786
Differential Revision: https://phabricator.services.mozilla.com/D115787
They are used by setting text value of `TextEditor` or replacing a misspelled
word with a new word in both `TextEditor` and `HTMLEditor`. Therefore,
they should be in the `EditorBase` rather than `TextEditor`.
Note that the path of the former case may be in a hot path. Therefore, we need
to keep redirecting to `TextEditor` for keeping the performance only in the
case.
Depends on D115785
Differential Revision: https://phabricator.services.mozilla.com/D115786
This method is semi-public method, meaning that this is commonly used by
public methods which handle various user input and that causes inputting
text, both in `TextEditor` and `HTMLEditor`.
Therefore, for making `HTMLEditor` stop inheriting `TextEditor` class in the
future, we should move it into `EditorBase`.
Depends on D115784
Differential Revision: https://phabricator.services.mozilla.com/D115785
IME is available in both `TextEditor` and `HTMLEditor`, and the handling
code is almost same (they partially do different things with checking
`IsHTMLEditor()`). Therefore, we should move them to `EditorBase` for
making `HTMLEditor` possible to inherit only `EditorBase` in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115784
This fix allows that we can remove previous div block that isn't editable.
```
<div contenteditable>foo<div contenteditable=false>bar</div><[]baz</div>
```
Our text scanner can reach previous text node in other block when deleting
text even if text node is read-only. In this situation, we try joining each
block. But since target element/node isn't editable, this operation is
failure.
So we should use atomic deletion instead for this case.
Differential Revision: https://phabricator.services.mozilla.com/D115341
This fix allows that we can remove previous div block that isn't editable.
```
<div contenteditable>foo<div contenteditable=false>bar</div><[]baz</div>
```
Our text scanner can reach previous text node in other block when deleting
text even if text node is read-only. In this situation, we try joining each
block. But since target element/node isn't editable, this operation is
failure.
So we should use atomic deletion instead for this case.
Differential Revision: https://phabricator.services.mozilla.com/D115341
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
And also `HTMLEditor::CountEditableChildren()` is moved since it's used only by
it.
Despite the long method name, it's really unclear what it does. I try to
explain it with new name, but the things which the method does are not make
sense. So, if you have better name idea, I'll take it...
Differential Revision: https://phabricator.services.mozilla.com/D115177
Now, it does easy things and called only by
`HTMLEditor::CreateRangeIncludingAdjuscentWhiteSpaces()`. Therefore, we can
move the code into the caller.
Differential Revision: https://phabricator.services.mozilla.com/D115173
Similarly, it's called only by `HTMLEditor::GetWhiteSpaceEndPoint()` and
it returns after point of last white-space if and only if the given point
container is a text node and the offset is not end of the text node.
Therefore, we can reimplement it in the caller simply.
Differential Revision: https://phabricator.services.mozilla.com/D115172
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
It's used only by `HTMLEditor::GetWhiteSpaceEndPoint()` and it just skips
white-spaces and returns first white-space position if and only if the
given point container is a text node and its previous character is a
white-space. Therefore, it can be rewritten with `EditorDOMPoint` simply in
the caller.
Differential Revision: https://phabricator.services.mozilla.com/D115171
Despite its name, it checks whether both given nodes are in same/no table
structure element or not. For avoiding this confusion, let's add
`GetInclusiveAncestorAnyTableElement()` to `HTMLEditUtils` and compare
the result of its calls with 2 content nodes.
Differential Revision: https://phabricator.services.mozilla.com/D115170
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
