`TextControlState` is alive during reframing, but `TextEditor` is not so.
Therefore, `TextControlState` should take the `PasswordMaskData` before
`TextEditor` is destroyed. And if `TextEditor` is recreated, and the value
hasn't been modified, unmasked range should be restored in the new editor.
Depends on D118757
Differential Revision: https://phabricator.services.mozilla.com/D118758
During a `TextControlState` alive, `PasswordMaskData` should be alive too.
Otherwise, we cannot keep unmasked range at reframing.
Depends on D118756
Differential Revision: https://phabricator.services.mozilla.com/D118757
The intermittent failure is caused by unexpected global reflow during the test.
If `<input type="password">` is reframed, `TextEditor` instance is recreated.
Then, the unmasked range of the editor stored by `TextEditor` is also lost.
Therefore, unmasked range is randomly lost by unexpected reflow.
If the global reflow is occurred by font list update etc which are not expected
by users, unmasked password field is unexpectedly masked. So, this is a real
bug of `TextEditor`.
So, unmasked range needs to be stored outside `TextEditor` for making its
lifetime longer than `TextEditor`. For doing it, first, `TextEditor` should
access password mask data via a pointer to a struct. Then, fortunately,
we need to allocate it only when the `TextEditor` is a password editor.
Depends on D118755
Differential Revision: https://phabricator.services.mozilla.com/D118756
In my understanding at fixing bug 1717156, `nsIEditor.eEditorMailMask` won't be
set to `TextEditor` instance. However for making consistent **spellchecker**
behavior on email composer, subject editor is also set this flag. So, we need
to drop the check in `SetFlags` and IsMailEditor.
Differential Revision: https://phabricator.services.mozilla.com/D118561
It's used only by password field, i.e., only by `TextEditor`, and used
temporarily. Additionally, there is some space in `TextEditor`. So, we
can get rid of it, and make `TextEditor` store it directly.
Note that this allows to skip expensive `nsIEditor::SetFlags()` calls by
`AutoRestoreEditorState`. This may improve setting `<input>.value` performance.
Differential Revision: https://phabricator.services.mozilla.com/D118266
Now, `nsIEditor::eEditorNoCSSMask` is used only in the editor internally.
And it's available and meaningful only with `HTMLEditor` instance. So,
we can get rid of it from `EditorBase`. Fortunately, `HTMLEditor` always
creates `CSSEditUtils` and it stores the raw value indicating whether the
editor manager enabled or disabled CSS. Therefore, we don't need new
member variable in `HTMLEditor` for storing the flag. And this allows us
to remove `nsIEditor::SetFlags()` override of `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D118265
Now, `EditorBase::IsTabable()` returns true only when it's an `HTMLEditor`
instance and `nsIEditor::eEditorAllowInteraction` is not set. Additionally,
nobody controls the flag of `TextEditor`. So, we can make the flag available
only with `HTMLEditor` instance, and `Tab` key handling in `EditorBase`
can be moved to `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D118264
Nobody (including comm-central and BlueGriffon) uses
`nsIEditor::eEditorFilterInputMask`. Therefore, we can get rid of this and its
accessor, `EditorBase::IsInputFiltered()`.
Differential Revision: https://phabricator.services.mozilla.com/D118263
With the previous patch, we know `nsIEditor::eEditorWidgetMask` always
matches with `EditorBase::IsTextEditor()`. And it's not referred from JS
(including comm-central and BlueGriffon). So, we can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D118262
Some `nsIEditor::eEditor*Mask` flags are now only for `TextEditor` or
`HTMLEditor`. For making it clearer, add `MOZ_ASSERT` to the `SetFlags` and
each flag accessor.
Differential Revision: https://phabricator.services.mozilla.com/D118261
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
`TextEditor` is now a final class, so, it should be marked as so. And this
patch modernize `virtual`, `override` and `final` keywords in them.
Differential Revision: https://phabricator.services.mozilla.com/D117998
When middle mouse paste is enabled and middle click occurs in an editable
content or it's in a document whose `designMode` is `on`, we shouldn't start
the autoscrolling because the click must be intended for pasting clipboard
content or primary selection to the position.
Differential Revision: https://phabricator.services.mozilla.com/D117987
`nsIDocumentEncoder.OutputRaw` was misspelled as `nsIDocumentEncoder.OutRaw`.
Then, I investigate the expected result more. Then, I see that when only this
flag is set, any markups should be ignored except `<br>`. Therefore, I modified
the 2 test results which check `<p>`, `<div>` and `<br>` elements.
Differential Revision: https://phabricator.services.mozilla.com/D117966
This is slightly complicated by the fact that the editor code wants to be able
to set this from the content process, so we really need separate
BrowsingContext and WindowContext flags, the latter of which can be set by the
owning process.
Differential Revision: https://phabricator.services.mozilla.com/D114899
It's a static method and called only with `EditorDOMPointBase` instances.
So, we can add new API to `EditorDOMPointBase` instead.
Note that it's changed to return container when the container is a data node
rather than a text node. This should be better because no data node can
have children.
Depends on D117382
Differential Revision: https://phabricator.services.mozilla.com/D117490
For making it clearer that `TextEditor` has only its specific members. For
guaranteeing that, we should split `TextEditor` and `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D117382
For consistency with the similar internal DOM API, `As*()` should just cast
the type without checking editor type. Instead, `GetAs*()` should do it.
Differential Revision: https://phabricator.services.mozilla.com/D117381
While initializing `HTMLEditor` for `designMode`, `blur` event for the
previously focused element will be fired after `HTMLEditor` initialization
because of the script blocker in `Document::EditingStateChanged()`:
https://searchfox.org/mozilla-central/rev/c0f286b1f541c675bbe052b21bdefa80d150ec35/dom/base/Document.cpp#5878,5891,5923
This causes `EditorEventListener::Blur()` calling
`EditorBase::FinalizeSelection()` to make the editor stop handling selection.
Therefore, if the design mode is turned on from an event listener run by a
user operation cannot make the caret visible.
This patch makes the `Blur()` ignore `blur` events whose target is element
in the design mode since the target of `blur` events should be handled in the
design mode is always the DOM window or the document node.
Differential Revision: https://phabricator.services.mozilla.com/D117268
`TextEditor` will be not a parent class of `HTMLEditor`. Therefore, editor
command classes should use `EditorBase` class instead.
Depends on D117116
Differential Revision: https://phabricator.services.mozilla.com/D117117
`DataTransfer` manages its items with `uint32_t` now, but editor methods still
access with `int32_t`. Therefore, editor module should use `uint32_t`.
Depends on D117115
Differential Revision: https://phabricator.services.mozilla.com/D117116
This patch makes the previously created handler method to virtual (derived from
`EditorBase`), and makes `TextEditor` override it.
Depends on D116801
Differential Revision: https://phabricator.services.mozilla.com/D116802
`TextEditor::OnDrop()` handles both cases, in `TextEditor` and in `HTMLEditor`
because the common part is too complicated to duplicate. However, most
different part is inserting the dropped items part. So, let's make them
into a virtual method.
In this patch, creating a method only in `HTMLEditor` and moves the part
into it.
Depends on D116569
Differential Revision: https://phabricator.services.mozilla.com/D116801
It should be a virtual method derived from `EditorBase`, and `TextEditor`
and `HTMLEditor` should override it. Then, `nsIEditor::Paste()` requires
referring vtable again if we keep implementing it only in `EditorBase`.
Therefore, this patch avoid it with implementing it in both `TextEditor`
and `HTMLEditor`.
Depends on D116567
Differential Revision: https://phabricator.services.mozilla.com/D116568
It just creates an `nsITransferable` instance and add 2 flavors for storing
plain text. Therefore, it can be in `EditorUtils` instead.
Depends on D116566
Differential Revision: https://phabricator.services.mozilla.com/D116567
It stopped using `ComputeValueFromTextNodeAndBRElement` for `HTMLEditor` case.
However, `ComputeValueFromTextNodeAndBRElement` handles the case that there is
only padding `<br>` element for empty editor even if the instance is
`HTMLEditor`.
So, this patch makes it handle this special case by itself before checking
whether the instance is `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D116541
`Delete` and `Backspace` keys are handled by same code. So, the code should
be in `EditorBase` instead of `TextEditor`.
If `HTMLEditor` is in the plaintext editing mode of mail composer, `Tab` key
is also handled by the same code as `TextEditor`. So, the code in `TextEditor`
should be moved to `EditorBase` too and `HTMLEditor` should call `EditorBase`'s
method only when it's in the plaintext mode.
Depends on D116352
Differential Revision: https://phabricator.services.mozilla.com/D116353
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
Masayuki Nakano
Kagami Sascha Rosylight
Ryan VanderMeulen
Andrew Halberstadt
Kris Maglione
Csoregi Natalia
Emilio Cobos Álvarez
Makoto Kato
Butkovits Atila