The function tests whether `input` event whose `inputType` is `insertFromPaste`
or not and it waits the event until timeout. This sometimes fails in my
environment, and `input` event should be fired synchronously in this case.
Therefore, it should just fail if the event isn't fired.
Depends on D120424
Differential Revision: https://phabricator.services.mozilla.com/D120425
Oddly, clipboard related test randomly (and frequently) fails in my environment.
And `test_pasting_table_rows.html` does not handle exception which is thrown
by `SimpleTest.promiseClipboardChange`. Therefore, I'm always waiting 5 mins
when I run all tests under `editor/libeditor/tests`.
Therefore, I'd like to make it abort remaning tests if it fails due to
an unexpected exception.
Additionally, this fixes a bug in `_copyToClipboard#validatorFn`. This method
modifies the variable of the parent function, `aExpectedPastedHTML`, with
itself. Therefore, when the function is called multiple times, the expected
string will be re-wrapped with `kTextHtmlPrefixClipboardDataWindows` and
`kTextHtmlSuffixClipboardDataWindows` again and again...
Differential Revision: https://phabricator.services.mozilla.com/D120424
For consistency, between `TextServicesDocument` and `HTMLEditor`,
`TextServicesDocument::IsBlockNode()` should be replaced with
`HTMLEditUtils::IsBlockElement()` for making same consideration for each
element type.
Differential Revision: https://phabricator.services.mozilla.com/D119870
It checks default `font-family` with editing commands, but it depends on the
system locale. ("serif" vs. "sans-serif"). So, its `<body>` should be styled
as `font-family: serif` for consistent behavior in any environment.
Differential Revision: https://phabricator.services.mozilla.com/D119871
`EventStateManager` gives up to track gesture to start a drag if mouse down
content which is stored in `mGestureDownFrameOwner` gets lost its primary frame.
When user tries to start to drag selected text in `<input>` or `<textarea>`
element, mouse down content is an anonymous node in `TextControlElement`. So,
if a reflow occurs after `mousedown` event, the anonymous `<div>` element
is replaced with new one and `EventStateManager` gives up to track it.
Therefore, this patch makes `EventStateManager` do similar things as
`nsBaseDragService`. When `nsTextControlFrame` notifies of remove/add
the anonymous nodes, `EventStateManager` tries to keep tracking gesture with
a new anonymous node.
Differential Revision: https://phabricator.services.mozilla.com/D119488
When `nsTextControlFrame` is reframed, `TextEditor`, anonymous `<div>`, its
`Text` and the independent `Selection`s are deleted temporarily and recreated
them.
If users are dragging text in `<input>` or `<textarea>`, the drag session's
source node is set to the anonymous text node in the element and the selection
is set to the independent selection. So, if the element is reframed during a
drag, the source node is disconnected from the document and `EndDragSession`
failed to dispatch `eDragEnd` event.
Therefore, this patch makes `nsTextControlFrame` replaces the source node and
selection when it's recreated and only when the drag session's original source
node was in the text control element. For checking which text control had the
anonymous text node, this patch makes `nsTextControlFrame` replaces source
node with the `<input>` or `<textarea>` element when the frame is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D119487
With IIEF, we can guarantee each test block isolated. So, without declaring
semi-global variables a lot for all tests, developers can comment out every
tests to debug only one thing.
Differential Revision: https://phabricator.services.mozilla.com/D119486
When the test is timed out, there is a JS error which is thrown by
`synthesizePlainDragAndDrop`. So, first, make the test handle exception
with `try-catch` and assert the error.
Differential Revision: https://phabricator.services.mozilla.com/D119485
There are some methods in `TextServicesDocument` which work only with
`TextServicesDocument::mOffsetTable`. Once we move such methods to custom
class of `nsTArray<UniquePtr<OffsetEntry>>`, we can make `TextServicesDocument`
simpler.
Depends on D119157
Differential Revision: https://phabricator.services.mozilla.com/D119158
`beforeinput` event was shipped and it won't be disabled for avoiding confusion
of web developers. So, we can drop the pref setting of
"dom.input_events.beforeinput.enabled" in our tests.
Depends on D119716
Differential Revision: https://phabricator.services.mozilla.com/D119729
Now, it stores `dom::Text` with `OwningNonNull`. So, once it's leaked, it
wastes a lot of memory spaces. Therefore, we should make `mOffsetTable`
store `UniquePtr<OffsetEntry>` instead of `OffsetEntry*`.
Depends on D119156
Differential Revision: https://phabricator.services.mozilla.com/D119157
Now, the meaning of `OffsetEntry` is clear. Therefore, this patch adds comment
explaining the class and its members.
Then, the meaning of `TextServicesDocument::mSelStartOffset` and
`TextServicesDocument::mSelEndOffset` becomes clearer since they are used to
create `OffsetEntry` instances. Therefore, this patch renames them.
Depends on D119155
Differential Revision: https://phabricator.services.mozilla.com/D119156
Now, `mNode` is always a text node, and it may store across "can run script"
boundaries. So, it should be `OwningNonNull<Text>`.
Depends on D119148
Differential Revision: https://phabricator.services.mozilla.com/D119149
It seems that it treats mainly a text node in various places, but it's not
guaranteed by any variable declarations. So, first of all, I'd like to make
it clearer.
`TextServicesDocument::IsTextNode()` isn't necessary because `nsINode::IsText()`
is enough useful. And `AsText()` should be zero cost at runtime. So, in blocks
which guarantee specific content node is a text node, this patch appends
`AsText()` for making the code clearer.
Differential Revision: https://phabricator.services.mozilla.com/D119148
The crash is caused by the infinite loop to delete unnecessary ranges.
The `i` is always equals or larger than `0` due to unsigned. So, if
`Selection::RangeCount()` is `0`, `i` can be `UINT32_MAX`.
Instead, we can use `nsTArray<RefPtr<RangeItem>>::TruncateLength()`.
Differential Revision: https://phabricator.services.mozilla.com/D119564
Until fixing bug 1686012, clipboard in the headless mode does not support
"text/html" flavor. Therefore, the `waitForClipboard` in the test does not
get expected value as `aData` in the first callback.
So, it should request `text/unicode` in the headless mode.
Depends on D119483
Differential Revision: https://phabricator.services.mozilla.com/D119484
With the change of bug 1716863, it retrieves editing host, but it's `nullptr`
if there is no `<body>` element in XHTML document. The root cause should be
fixed in bug 1697989, but for now, we should allow it only in XHTML document
for safer regression fix.
Differential Revision: https://phabricator.services.mozilla.com/D119483
In most cases, it's called with selection range which is collapsed in a text
node, but otherwise, the selection may be in an element which cannot have
text nodes. Therefore, before handling the insertion, it should look for
ancestor element which can have text nodes.
Note that this patch makes inserting text immediately before an inclusive
ancestor element whose parent can have a text node. However, both Blink and
WebKit ignores if there are invisible/empty inline nodes. So, even with
this patch, Gecko keeps failing in some tests of the WPT. It should be handled
in a follow up bug because doing it requires complicated code.
Differential Revision: https://phabricator.services.mozilla.com/D119065
I guess that this class is replaced with `AutoPlaceholderBatch`, and both of
them are followed by its instances. However, I don't want to change the
behavior in this bug. Therefore, this patch just moves it into `HTMLEditor`.
Depends on D119002
Differential Revision: https://phabricator.services.mozilla.com/D119003
Unfortunately, marking its constructor and destructor as `MOZ_CAN_RUN_SCRIPT`,
`Maybe<AutoSelectionRestorer>::reset()` and
`Maybe<AutoSelectionRestorer>::emplace()` cause bustage. Therefore, this patch
just mark them as `MOZ_CAN_RUN_SCRIPT_BOUNDARY`.
Note that `EditorBase::SavedSelectionRef()` cannot be moved to `HTMLEditor`
because `mEditActionData` is a private member of `EditorBase`.
Depends on D119001
Differential Revision: https://phabricator.services.mozilla.com/D119002
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
`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
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
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
I think that it's no matter to make `WSRunScanner` work without editing host.
Therefore, this patch make it take pointer of `Element` rather than reference.
Depends on D112502
Differential Revision: https://phabricator.services.mozilla.com/D112503
Currently, its `mEditorWasDestroyed` is set to true even while `input` event
is being dispatched, i.e., even when it finished everything for the edit action.
However, the flag should be only for blocking unexpected cause which is caused
by mutation event listeners or something other unexpected event listeners
which shouldn't be run while editor is handling an edit action.
Therefore, this patch makes it store "handled" state which is marked before
notifying editor observers and dispatching `input` event and the flag won't
be set to true after it's marked as "handled".
Depends on D111579
Differential Revision: https://phabricator.services.mozilla.com/D111580
The editing session is temporarily disabled when opening a document. Then,
when the document is closed, the editing session is restored with same
`HTMLEditor` instance. Therefore, initializing editor may occur during
an edit action is being handled.
Probably, this must not be used in normal webapps since mutation events are
used rarely. So, I think that for avoiding further complicated things, we
should make editor won't accept new edit action handling after original
editing session ended.
This patch renames `AutoEditActionDataSetter::CanHandle()` to
`IsDataAvailable()` since it just checks whether the important resource is
available or not. And makes new `CanHandle()` return `false` for
non-initializing edit actions if editing session has ended.
Differential Revision: https://phabricator.services.mozilla.com/D111241
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
Currently, it dispatches `input` event with holding `mPlaceholderTransaction`
and `mPlaceholerBatch` as 1. If `input` event listener sets value in XUL
document, the setting value transaction will break the existing placeholder
transaction. Then, only the last one will be undone, and it causes inserting
new padding `br` element with transaction and clears redo history.
This patch makes it forget them before dispatching `input` event.
Note that I tried to create automated test for this, but I cannot reproduce
this with simple testcase. I guess something other things also required to
reproduce this bug.
Differential Revision: https://phabricator.services.mozilla.com/D110715
This is a bug of the assertion.
When there is 2 text nodes are adjacent, one ends with a visible character and
the other starts with a white-space, and the deleting range ends at end of the
first one, `GetReplaceRangeDataAtEndOfDeletionRange()` returns a range starting
with the start of the second one since it does not need to touch the first one.
Therefore, the white-space range start may be after the deleting range end.
This patch adds new condition to the `MOZ_ASSERT_IF`, and test this specific
case with new `MOZ_ASSERT_IF`.
Differential Revision: https://phabricator.services.mozilla.com/D110068
Those command handlers just check whether the given editor is an `HTMLEditor`
or not. Therefore, we should make them check whether the given editor is
a single line editor or not instead.
Differential Revision: https://phabricator.services.mozilla.com/D108572
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
Those command handlers just check whether the given editor is an `HTMLEditor`
or not. Therefore, we should make them check whether the given editor is
a single line editor or not instead.
Differential Revision: https://phabricator.services.mozilla.com/D108572
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
This test case doesn't generate body element and isn't general case. Actually
since we don't manage current IME focus on IMEStateManager, we shouldn't notify
IMEContext of widget.
Differential Revision: https://phabricator.services.mozilla.com/D108366
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
E.g., comment node is an invisible data node, and it's not handled by
`HTMLEditor` nor `ContentEventHandler`. Therefore, `IMEContentObserver`
should ignore invisible data nodes, which are not derived from `dom::Text`.
Differential Revision: https://phabricator.services.mozilla.com/D107590
For making delete handlers simpler, and set better target ranges to the
corresponding `beforeinput` event, we should ignore non-editable ranges
before handling deletion.
This patch makes editor stop handling deleteion when a range crosses editing
host boundaries. In this case, Gecko has done nothing, but fired
`beforeinput` event. Note that Blink deletes editable contents in the range
**until** it meets first non-editable content, but I don't think this is
a good behavior because it makes things complicated. Therefore, I filed
a spec issue: https://github.com/w3c/editing/issues/283
On the other hand, this behavior change causes different behavior in
https://searchfox.org/mozilla-central/source/editor/libeditor/crashtests/1345015.html
It tries to insert paragraph into `<html>` element, but our editor currently
does not support it. Therefore, it hits `MOZ_ASSERT`. Therefore, this patch
added a new check into `HTMLEditor::InsertParagraphSeparatorAsSubAction()`.
Differential Revision: https://phabricator.services.mozilla.com/D107588
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
It does not make sense `WSRunScanner` handles invisible white-spaces in
non-editable elements. Therefore, this patch makes it stop handling in the
cases.
Note that this change causes new fail of some WPTs. That will be fixed by
the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D107586
No behavior change. We were already returning false for HTML editor +
non-editable so we can simplify it a bit.
Depends on D107511
Differential Revision: https://phabricator.services.mozilla.com/D107512
Masayuki Nakano
Kagami Sascha Rosylight
Ryan VanderMeulen
Andrew Halberstadt
Kris Maglione
Csoregi Natalia
Emilio Cobos Álvarez
Makoto Kato
Butkovits Atila
Matt Woodrow
Alexandru Michis
Mirko Brodesser
Jonathan Kew
Brindusan Cristian