Such events shouldn't be fired, but for now, we should make them handled in
the overrides. Then, we can avoid the skipping `TextEditor` case from
`HTMLEditor`.
Depends on D116351
Differential Revision: https://phabricator.services.mozilla.com/D116352
In any types of editor, `EditorBase` handles if it's in the read-only mode.
For making `HandleKeyPressEvent` relation between classes simpler, let's
handle it in an independent method.
Depends on D116350
Differential Revision: https://phabricator.services.mozilla.com/D116351
It's used both with `TextEditor` instance and `HTMLEditor` instance. So, it
should be implemented in `EditorBase`.
Depends on D116349
Differential Revision: https://phabricator.services.mozilla.com/D116350
It's a helper method of `TextEditor::ComputeValueInternal()` which is used by
`TextEditor` and `HTMLEditor::Rewrap()`. So, before we move
`ComputeValueInternal()`, we need to move this first.
Depends on D116347
Differential Revision: https://phabricator.services.mozilla.com/D116348
It's now used only by `HTMLEditor::Rewrap()` and it does simple thing with
`TextEditor::ComputeValueInternal()`. So, we can make `Rewrap()` directly
do it instead.
Differential Revision: https://phabricator.services.mozilla.com/D116347
The attribute is used only with `HTMLEditor`, and it does not make sense to
access document's character-set via `TextEditor`. Therefore, this patch
makes it implement in `HTMLEditor` (`EditorBase` will return
`NS_ERROR_NOT_AVAILABLE` both getter and setter).
Note that `EditorBase::GetDocumentCharsetInternal()` is required by
`TextEditor::ComputeValueInternal()`. Therefore, it needs to stay in
`EditorBase`.
Differential Revision: https://phabricator.services.mozilla.com/D115948
`TextEditor` declares some virtual methods newly. However, for moving some
methods from `TextEditor` to `EditorBase`, they should be accessible from
`EditorBase`. Therefore, this patch adds declarations of pure virtual
methods of them to `EditorBase`.
Differential Revision: https://phabricator.services.mozilla.com/D115796
It's common method of `TextEditor` and `HTMLEditor`, but implemented by
`TextEditor` even though it's an override of `nsIEditor`'s method.
Therefore, it should be implemented in `EditorBase` instead.
Differential Revision: https://phabricator.services.mozilla.com/D115794
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
