The other browsers use any inline elements to set CSS property for applying
an inline style. However, Gecko limits it to a `<span>` which does not have
any attributes. The other browsers' design is better for saving number of
elements and runtime cost of inserting new element (moving all children to the
new element and inserting it to the original position). Therefore, it's nicer
to follow the other browses. Then, we can avoid new WPT failures at aligning
other behaviors to the other browsers.
With doing that, removing style code requires complicated changes because
`RemoveStyleInside` assumes that one element has one style, but after taking
the compatible behavior, one element can have multiple styles including the
style represented by the element itself.
Note that the new expected failures are caused by bug 1183844. Gecko returns
closest ancestor element's background color for
`queryCommandValue("backColor")`. Therefore, it returns "transparent" of the
inner `<span>` element.
Differential Revision: https://phabricator.services.mozilla.com/D164004
When keyboard events are fired by auto repeat feature of OS, each event is fired
in each event loop. However, `repeat` feature of the `synthesizeKey` and
typing multiple characters with `sendString` dispatch keyboard events in an
event loop. Therefore, asynchronous scrolling is handled differently from
users' scenario. So we should emulate the users' scenario better with
synthesizing each event with waiting a tick.
Depends on D162527
Differential Revision: https://phabricator.services.mozilla.com/D162528
It uses legacy `hitEventLoop` hack with `setTimeout`. Now, we have better
utility methods and can avoid using callbacks with using async/await.
However, waiting only for `waitToClearOutAnyPotentialScrolls` does not fix
the intermittent failure. Therefore, this patch checks whether the scroll
result in its wrapper to make sure that there is no pending scroll.
Differential Revision: https://phabricator.services.mozilla.com/D162527
The failure on Android is caused by async initialization of `<textarea>` runs
after initializing selection in it. Therefore, `ArrowUp` is synthesized when
all text is selected and collapses it to start.
Then, I see another failure on Linux and macOS in `contenteditable` case at
running TV and TV-nonfis. It seems that it's caused by remaining `Selection`
of the preceding test (`vertical-rl` case) does something wrong. Once
removing all ranges at `blur`ring, the failures in `vertical-lr` case has
gone.
Differential Revision: https://phabricator.services.mozilla.com/D159566
`nsIEditor.undo` and `nsIEditor.redo` are called with `1` except by the search
bar, and search bar wants to undo everything to reset the value. Therefore,
search bar needs an API to undo all, and the others do not need the number of
undoing/redoing transactions. Therefore, this patch adds `nsIEditor.undoAll`
for search bar, and remove the arguments from `nsIEditor.undo` and
`nsIEditor.redo`.
Differential Revision: https://phabricator.services.mozilla.com/D158338
They are methods to take 2 out params, and it's not convenient for light use.
I think that there should be 3 attributes, `undoRedoEnabled`, `canUndo` and
`canRedo`. Then, the findbar does not need to check number of transactions
with `nsITransactionManager`.
Differential Revision: https://phabricator.services.mozilla.com/D158337
`nsIEditor.transactionManager` is used only for some simple purposes, however,
`nsIEditor` exposes the rich API. That makes it harder to maintain internal
code around transactions. Instead, `nsIEditor` exposes only simple and
necessary APIs.
This patch creates a new API to clear undo/redo history and make the users in
mozilla-central use it instead of using `nsITransactionManager.clear()`.
Differential Revision: https://phabricator.services.mozilla.com/D158336
The test compares the node name of the split element and its previous sibling
element, so it should switch the scanning direction with the pref to switch
split node direction.
Note that the behavior is different from the other browsers in some cases.
Therefore, we cannot port this to WPT.
Differential Revision: https://phabricator.services.mozilla.com/D158105
This is a hack for compatibility with the other browsers. When we move first
line of `<pre>` to left paragraph whose `white-space` style does not make it
preformatted, they drop the last linefeed because of unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D157419
When the first line of right block element is moved before the block element,
unnecessary line break may be moved to immediately before the right block
element. In the case, it needs to clean it up instead of trying to find
unnecessary line break at end of the left block which is a container of the
right block element.
Differential Revision: https://phabricator.services.mozilla.com/D157417
Empty inline nodes except non-container nodes are not required in the
destination paragraph. Therefore, it should just remove the node from the
DOM tree.
Differential Revision: https://phabricator.services.mozilla.com/D157416
We don't ignore invisible data node at joining 2 paragraphs and this is
a different behavior from the other browsers. When looking for a content
from current block boundary, `AutoBlockElementsJoiner` should keep scanning
visible things with ignoring invisible data nodes. Then, it should delete
all invisible things after joining the paragraphs.
Differential Revision: https://phabricator.services.mozilla.com/D157414
Chrome and Safari preserve `white-space` with `style` attribute to keep
collapsible or preserved white-spaces as-is. If an HTML element is moved,
`style` attribute should be set to it. Otherwise, create `<span>` element
whose `style` attribute has the declaration for `white-space` and move
content into it.
Differential Revision: https://phabricator.services.mozilla.com/D157413
Gecko just joins 2 blocks when editable block parents are same element, e.g.,
both are `<div>`. However, Chrome and Safari moves only first line of the
right block into the left block, and Gecko does it when both blocks are
different elements.
Ideally, we should take same behavior as Chrome and Safari because it's
reasonable for both compatibility with the other browsers and consistency
when both blocks are different but has same style, then we don't need to
maintain different behavior paths.
However, doing it for all elements are too risky because right block will be
merged into left block if right block has no line break. On the other hand,
without doing it, preserving `white-space` is really hard because we need to
maintain the both paths.
Therefore, I'd like to change the behavior only when both blocks have different
`white-space` styles. Usually, web apps do not change `white-space` for each
block, so I think that this is safer than doing this in all elements,
additionally, we can revert the behavior easy since this patch is really small.
Differential Revision: https://phabricator.services.mozilla.com/D157412
This fixes bug 503838 partially. The new utility method scans unnecessary
`<br>` with strict check as far as possible. Then, we can delete the node or
the preformatted line break at end of the last text node.
Differential Revision: https://phabricator.services.mozilla.com/D157411
This patch ports most part of `editor/libeditor/tests/test_bug772796.html` to
WPT because this kind of behaviors are not tested by `editing/run/delete.html`
nor `editing/run/forwarddelete.html`. (Not ported tests are invalid HTML
structure cases and list item cases, the reason why not doing this for the
latter is, it needs a lot of cases and not important for most web apps.)
The most expectations are based on Chrome and Safari (they both behave almost
same), but they fail a lot in `join-pre-and-other-block.html` and
`white-space: pre-line` cases in the other tests.
Even though this ports a lot of cases, for making easier to compare the
behavior change in the following patches, we should keep the tests.
Differential Revision: https://phabricator.services.mozilla.com/D157410
They and their callees work with the result of `GetRoot()` which is the document
element or the body element. If the body is not editable, `Selection` should
not be updated in non-editable region nor `<br>` elements should not be
inserted in both non-focused editable elements and non-editable elements.
Therefore, they should run only when the document element or the `<body>`
element is editable.
To keep testing crashtests as reported, this patch makes tests which have
`contenteditable` except `<html>` and `<body>` initialize `Selection` as
what we've done. And clean up the tests for helping to port them to WPT
in the future (bug 1725850).
Differential Revision: https://phabricator.services.mozilla.com/D157408
It's hard to know how some tests failed in test_bug1318312.html. Therefore,
this patch makes the selection range comparison easier to read, and add
description to explain what was doing at the failure.
Differential Revision: https://phabricator.services.mozilla.com/D156526
Before the fix of bug 1758420, `TextComposition`'s text node and offset in it
are updated at creating `CompositionTransaction`. However, it's now put off
until getting the mutations. Therefore, it always unsets `pointToInsert` at
first time of the composition and fails to notify the listeners.
This patch makes it retrieve the result after calling `DoTransactionInternal`
and handle the post processing with the new point.
Differential Revision: https://phabricator.services.mozilla.com/D155052
The test oddly passes without the fix in `HandleInsertBRElement`. I guess that
post-processing in `HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal()`
handles `Selection`, and anyway the insertion point of the following
`insertText` is wrong. It seems that we don't need to uplift this.
Differential Revision: https://phabricator.services.mozilla.com/D153832
`increaseFontSize`, `decreaseFontSize`, `gethtml`, `heading` and `readonly`
commands were disabled for a year in all channels, but no regression reports
have been filed. Therefore, we can delete the commands and the telemetry
probes.
Note that `cmd_getContents` command which is the internal command of `gethtml`
is not used in comm-central too. Therefore, this patch deletes the command
handler, `nsClipboardGetContentsCommand`, and `Command::GetHTML` too.
Differential Revision: https://phabricator.services.mozilla.com/D153720
The following patches touch the logic to restore selection after handling
commands. However, it seems that they are not tested because I found some
regressions by manual testing, but didn't cause orange on tryserver.
`outdent-preserving-selection.tentative.html` causes a crash due to the
`MOZ_ASSERTION` in `HTMLEditor::HandleOutdentAtSelectionInternal`. It means
that I misunderstand the logic and had put the assertion. I should fix it
later with reading the complicated code again. For now, I just change it
to `NS_WARNING_ASSERTION` instead.
And also `test_cmd_absPos.html` is the first test to check toggling `position`
between `static` and `absolute`. Therefore, it detects wrong `MOZ_ASSERT`s
which test whether `EditActionData` or `TopLevelEditSubActionData` is created
or not **before** they create them by themselves. So, this patch removes the
wrong assertions.
Differential Revision: https://phabricator.services.mozilla.com/D152962
In Yahoo! Mail, the paragraph has `<br>` after `<span>` element which has
`background-color`. In this case, Gecko creates the following DOM tree after
splitting the paragraph:
```
<div><span>foo</span></div><div><span></span><br></div>
```
Then, the empty `<span>` in the right paragraph will be removed by the
post-processing. However, in this case, the inline element is required for
preserving the style continued from the previous paragraph.
In this case, we should move the `<br>` element into the `<span>` to make
it non-empty and avoid it to be removed. This is compatible with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D151345
This patch also makes it inserts table rows immediately after the previous
row element of the found reference row element to make it insert new table
rows immediately after there when inserting position is "after". Typically,
it's the parent `<tr>` element of `aCellElement`. Therefore, this approach
can preserve text nodes immediately after it which was intentionally inserted
by the web apps.
Differential Revision: https://phabricator.services.mozilla.com/D146365
It needs to work with the latest layout information to consider which cell
element is the insertion point due to rowspan and colspan. Therefore,
this patch makes it collects all cell data before touching the DOM except
the case that it needs to normalize the table to make it rectanble.
Note that the case requiring the normalizer should be fixed in a later patch.
This method is corresponding to an XPCOM method. Therefore, this is tested
by `test_nsITableEditor_insertTableColumn.html`.
And also it's used by the inline table editor, but we don't have automated tests
for this because of no API to get the buttons. Therefore, I tested it by my
hand.
Note that the old code fails to put caret to newly inserted cell at the reftest
situation. This fixes the bug too. Therefore, this changes the reftest's
reference.
Differential Revision: https://phabricator.services.mozilla.com/D146364
It refers the layout information for getting row/column index of selected cell
element or a cell element which contains selection. However, it can stop
referring it if all callers can specify insertion point of new cells, and it's
possible. Therefore, we can make it free from layout information.
Note that this blocks legacy mutation events during inserting table cell
elements, but perhaps this does not cause problems in the wild.
`DOMNodeInserted` will be fired after all cell elements are inserted, so
from point of view of the event listeners, editor content is different from
traditional behavior, but this works only when user uses inline table editor
which is disabled by default. I.e., in the wild, this path is rarely run.
Additionally, this patch makes it return `CreateElementResult` for the latter
changes which want to put caret to first inserted cell element.
Note that the changes are tested by `test_nsITableEditor_insertTableColumn.html`
and `test_nsITableEditor_insertTableCell.html`.
Differential Revision: https://phabricator.services.mozilla.com/D146361
Our table editor depends on layout information for getting raw/column position
of a cell, checking rawspan/colspan information and table size. Therefore,
they require the latest information, but they don't flush pending layout by
themselves. Therefore, this patch makes them do it by themselves and deleting
unnecessary hack from their tests.
Differential Revision: https://phabricator.services.mozilla.com/D146359
It refers the layout information for getting row/column index of selected cell
element or a cell element which contains selection. However, it can stop
referring it if all callers can specify insertion point of new cells, and it's
possible. Therefore, we can make it free from layout information.
Note that this blocks legacy mutation events during inserting table cell
elements, but perhaps this does not cause problems in the wild.
`DOMNodeInserted` will be fired after all cell elements are inserted, so
from point of view of the event listeners, editor content is different from
traditional behavior, but this works only when user uses inline table editor
which is disabled by default. I.e., in the wild, this path is rarely run.
Note that the changes are tested by `test_nsITableEditor_insertTableColumn.html`
and `test_nsITableEditor_insertTableCell.html`.
Depends on D146360
Differential Revision: https://phabricator.services.mozilla.com/D146361
Our table editor depends on layout information for getting raw/column position
of a cell, checking rawspan/colspan information and table size. Therefore,
they require the latest information, but they don't flush pending layout by
themselves. Therefore, this patch makes them do it by themselves and deleting
unnecessary hack from their tests.
Differential Revision: https://phabricator.services.mozilla.com/D146359
