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
Masayuki Nakano