The serializer needs to make each mailcite starts from head of a line.
However, mailcite may be a blocked `<span>`. So, its preceding `<br>`
is not required from the HTML point of view, but we need to preserve
it for the serializer.
If we need this hack in some other places, we should make
`HTMLEditUtils::GetFollowingUnnecessaryLineBreak()` aware of this
special handling in a follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D270784
When we find a block boundary, it may be current block's boundary or
other block's boundary. The lambda assume only the former, but the
STR of this bug hits the latter case.
So, when user modifies the text before a mail-quote which is a block of
`<span>` element should put `<br>` before it rather than end of it.
Differential Revision: https://phabricator.services.mozilla.com/D270782
It's used as the result in some cases. However, it's not tracked in
some cases when touching the DOM.
This modifies the API of `AutoTrackDOMPoint` to flush the tracking point
but can keep tracking. We should use the new API in every place later.
(This manually merges `WhiteSpaceVisibilityKeeper.cpp` because ESR140
still has the pref to take the legacy mode back and that blocks applying
the patch cleanly.)
Differential Revision: https://phabricator.services.mozilla.com/D270643
When committing composition string,
`WhiteSpaceVisibilityKeeper::InsertOrUpdateCompositionString()` may
replace commit string with normalized white-spaces. Therefore, if
the last character is a white-space, it may be replaced with the other
white-space (ASCII white-space vs. NBSP). Then, `Selection` collapsed
after the last character will be moved to start of the replaced
white-spaces. So, when committing composition,
`HTMLEditor::HandleInsertText()` may need to change `Selection` by
itself.
Original Revision: https://phabricator.services.mozilla.com/D252278
Differential Revision: https://phabricator.services.mozilla.com/D253280
In modern C++, static constexpr member variables are automatically
inline (aka weak) so the template trick is not needed. This also avoid
duplication and reduces the amount of parsed code. No impact on
generated binary (actually: smaller debuginfo, close to identical
binary).
Differential Revision: https://phabricator.services.mozilla.com/D247825
This reverts commit 0681b181d6.
Revert "Bug 1932150 - Fix lint failure" for causing Build bustage.
This reverts commit 60cc0878d3.
Revert "Bug 1932150 - Add new test cases for selection in flat tree r=smaug"
This reverts commit 3dbe5fc183.
Revert "Bug 1932150 - Make selection code to correctly iterate flattened tree r=smaug"
This reverts commit 6f7a1e4886.
Revert "Bug 1932150 - ContentSubtreeIterator #3: Fix a bug in ContentSubtreeIterator where the end container is in the light DOM of a shadow host r=jjaschke"
This reverts commit 19ce2c5806.
Revert "Bug 1932150 - ContentSubtreeIterator #2: Allow ContentSubtreeIterator to iterate nodes in flattened tree r=jjaschke"
This reverts commit d9d192bc3a.
Revert "Bug 1932150 - ContentSubtreeIterator #1: Make the end container related logic in ContentSubtreeIterator more robust r=jjaschke,smaug,dom-core"
This reverts commit 2fbde5b84d.
Revert "Bug 1932150 - Update ranges to correctly set and update nodes for flattened selection r=jjaschke,smaug,dom-core"
This reverts commit 116d26c37f.
Revert "Bug 1932150 - Allow using flat tree order for point comparing in selection r=jjaschke,smaug,dom-core"
This reverts commit 2ba73e1639.
Revert "Bug 1932150 - Fix some inconsistency about indicating whether the selection is allowed to cross the shadow boundary r=jjaschke,dom-core"
This reverts commit 793c2453f1.
When inserting text or deleting text is for updating composition string,
`InsertTextWithTransaction()` does not suggest caret position because in the
most cases, `CompositionTransaction` updating `Selection` properly. However,
if it's deleting existing composition (i.e., replacing the composition with
empty string), `HTMLEditor::HandleInsertText()` doesn't use
`CompositionTransaction` to update composition. Instead, it uses the suggested
caret position from `InsertTextWithTransaction()` even though it's always unset.
Therefore, if the composition string follows some collapsible white-spaces and
they are replaced, `Selection` is automatically moved to the start position of
the replaced range and `HTMLEditor::HandleInsertText()` does not maintain the
caret position.
Therefore, this patch make it collapse `Selection` to end of the inserted text
where the composition string was.
Differential Revision: https://phabricator.services.mozilla.com/D246087
I'm not sure how to make this appear as an unexpected result. I just found
these mistakes when I was debugging bug 1959323
Depends on D244876
Differential Revision: https://phabricator.services.mozilla.com/D244879
When `HTMLEditor::InsertElementAtSelectionAsAction` inserts given element,
it tries to normalize the white-spaces around the insertion point [1].
Then, `WhiteSpaceVisibilityKeeper::NormalizeWhiteSpacesToSplitAt` tries to
delete invisible white-spaces around the insertion point first [2].
If the insertion point is not in leading white-spaces nor trailing white-spaces
around a block boundary, it tries to scan preceding and following white-spaces
to delete the surrounding invisible white-spaces [3].
At this time, it uses `TextFragmentData::GetInclusiveNextCharPoint()` and
`TextFragmentData::GetPreviousCharPoint()` which was initialized at the
insertion point.
However, they may return a point behind a block boundary with both digging into
a sibling block or skipping a sibling block. Therefore, the result may
be too far from the insertion point and the following code in
`WhiteSpaceVisibilityKeeper::EnsureNoInvisibleWhiteSpaces()` may extend the
range to contain children because `GetFirstASCIIWhiteSpacePointCollapsedTo()`
and `GetEndOfCollapsibleASCIIWhiteSpaces()` uses `GetInclusiveNextCharPoint`
and `GetPreviousCharPoint()` too.
Therefore, when Thunderbird inserts a `<p>` with a call of
`HTMLEditor::InsertElementAtSelectionAsAction()` after `<blockquote>`,
it may delete the preceding text in the `<blockquote>` accidentally.
So, the scan methods of `WSRunScanner` shouldn't cross the block boundaries
because they handle only text fragment in the same line.
1. https://searchfox.org/mozilla-central/rev/27bb03eebacd679df419dac52a3b99c142cdb5db/editor/libeditor/HTMLEditor.cpp#2264-2269
2. https://searchfox.org/mozilla-central/rev/27bb03eebacd679df419dac52a3b99c142cdb5db/editor/libeditor/WhiteSpaceVisibilityKeeper.cpp#1501-1503
3. https://searchfox.org/mozilla-central/rev/27bb03eebacd679df419dac52a3b99c142cdb5db/editor/libeditor/WhiteSpaceVisibilityKeeper.cpp#2447-2469
Differential Revision: https://phabricator.services.mozilla.com/D244876
If aDataTransfer is non-null we should always use it in
EditorBase::PasteAsAction(), even if we aren't dispatching the event.
This correctly handles a corner case when the focus is changed by the
paste handler (around line 1929) and PasteAsAction() calls itself again.
Differential Revision: https://phabricator.services.mozilla.com/D244235
The inner block of a scroller for example (::-moz-scrolled-content)
shouldn't be considered a line break.
Same for scrollbar nodes, we don't want to break on scrollbars (or
native anonymous content in general), since we can't position the caret
and such there anyways.
Differential Revision: https://phabricator.services.mozilla.com/D244519
The inner block of a scroller for example (::-moz-scrolled-content)
shouldn't be considered a line break.
Same for scrollbar nodes, we don't want to break on scrollbars (or
native anonymous content in general), since we can't position the caret
and such there anyways.
Differential Revision: https://phabricator.services.mozilla.com/D244519
Although, the empty text should've been removed, but it may happen without the
normalization. Therefore, the lambda should keep scanning the first visible
char with ignoring empty `Text` nodes.
Additionally, there are similar methods which have the same lambda. Therefore,
this fixes them too.
I think we should make the scanner method take an option parameter to ignore
empty `Text` in a follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D242264
In bug 1925635, I moved the post processing after deleting ranges in
`EditorBase::DeleteRangesWithTransaction` into the `HTMLEditor`'s override.
At this time, I makes it uses `HTMLEditUtils::IsEmptyNode` to check whether
the `Text` and its containers become empty. Therefore, if `Ctrl`+`Backspace`
deletes the only word in the `Text` which starts with a collapsible white-space
causes deleting the `Text` after deleting all visible characters in the `Text`.
Therefore, this makes check it with `Text::TextDataLength` too before searching
the most distant ancestor inline element which becomes empty.
However, it may cause leading invisible white-spaces of the only word visible
because `nsFrameSelection` computes the word range strictly in the `Text`.
Therefore, this patch also makes `HTMLEditor::DeleteRangesWithTransaction` and
`AutoDeleteRangesHandler::ComputeRangesToDeleteRangesWithTransaction` extend
each range to delete to include surrounding invisible white-spaces too.
Therefore, this patch adds the new method to `AutoClonedRangeArray`.
Then, I hit 4 existing bugs with new test failures.
One is `HTMLEditUtils::LineRequiresPaddingLineBreakToBeVisible`. It checks
whether the candidate point to insert a `<br>` is followed by a block boundary
first. Then, it checks whether the candidate point follows a collapsible
white-space or a block boundary. However, it uses
`WSRunScanner::ScanPreviousVisibleNodeOrBlockBoundary()` which ignores invisible
white-spaces. Therefore, it will ignore the new invisible white-space and
reaches preceding `Text`. Thus, it fails to put a `<br>` and makes the new
invisible white-space "fixed" as invisible.
Therefore, this patch rewrites the check with using
`HTMLEditUtils::GetPreviousLeafContentOrPreviousBlockElement()`.
Next one is, `HTMLEditor::DeleteEmptyInclusiveAncestorInlineElements()`
returns end of deleted node if it's followed by a non-editable node, i.e.,
an element has `contenteditable="false"`. Therefore, its caller inserts a
`<br>` to the end of the container when deleting preceding editable node of a
non-editable node.
Therefore, this patch removes the editable state check.
Next, `AutoBlockElementsJoiner::HandleDeleteNonCollapsedRange` may put a padding
`<br>` after the moved line, but it does not assume that the moved line does not
ends with a block boundary. This causes failing #46 and #48 tests in
`text_bug772796.html`. E.g., when pressing `Delete` in
`<div>foo[]<div><span style="white-space:pre"><div>bar</div>baz</span>`, we move
the second `<div>` as a child of the parent `<span>` to end of the first `<div>`
like `<div>foo<span style="white-space:pre"><div>bar</div></span></div>...`.
Without the change, it starts to put unnecessary `<br>` after ` the `<span>`
because of the bug fix in `HTMLEditUtils::LineRequiresPaddingLineBreakToBeVisible`
above. This result is completely odd from the users point of view (looks like
just move caret), but we should avoid to put the unnecessary `<br>`.
Finally, we'll fail an assertion when putting caret at the last of
`AutoBlockElementsJoiner::DeleteContentInRange` because it forgets to flush
the tracking range before using it. This appeared by the changes above.
Therefore, this patch fixes this bug too.
Differential Revision: https://phabricator.services.mozilla.com/D240703
Even in these days, we notify selection listeners of selection changes
**synchronously**. Thus, we need to mark all selection change methods as
`MOZ_CAN_RUN_SCRIPT` even though they are safe in the most cases.
Depends on D241776
Differential Revision: https://phabricator.services.mozilla.com/D241778
It's an alias of `nsINode::GetClosestNativeAnonymousSubtreeRootParentOrHost()`
and oddly it returns `const nsIContent*` rather than `nsIContent*`. Therefore,
some callers need to use `const_cast`.
Differential Revision: https://phabricator.services.mozilla.com/D241776
It's currently always set to the native anonymous `<div>` for editable content
of text control element. So, it means that it's an independent selection root.
Depends on D241587
Differential Revision: https://phabricator.services.mozilla.com/D241775
This patch fixes multiple points which may cross independent selection
boundaries which is element boundary of the native anonymous `<div>` for
editable content in text controls. The reason why I don't split this patch is,
fixing one of them leads another assertion failure. So, I couldn't pass all
tests with separated patches.
1. `nsFrameTraversal` should take `Element` instead of `nsIFrame` for the
limiter because e.g., inline editing host like `<span contenteditable>` may
have multiple frames if it's wrapped. Therefore, we should make it take
an element as the ancestor limiter, and check it when getting parent frame
or after getting previous or next frame.
2. `nsIFrame::PeekBackwardAndForward` may cross the boundary because it does not
take the anonymous `<div>` element as ancestor limiter of the selection. It's
currently used only for extending selection. Therefore, I rename it to make
it clearer.
3. `SelectionMovementUtils::GetPrevNextBidiLevel` to take the ancestor limiter
for calling `nsIFrame::GetFrameFromDirection()`.
4. `nsINode` should have a method to return the `nsFrameSelection` instance
which manages the selection in the node. This makes the check simpler, and
this is not expensive. Then, for making it clearer, I rename
`TextControlElement::GetConstFrameSelection()` to
`GetIndependentFrameSelection()`.
5. `nsINode::GetSelectionRootContent()` should have an option to return
independent selection root when the node is its host for
`nsFrameSelection::ConstrainFrameAndPointToAnchorSubtree()`
6. `nsFrameSelection::ConstrainFrameAndPointToAnchorSubtree()` should not
retrieve independent selection root when the given frame is a text control
frame.
7. `RangeUtils` should get parent with checking the independent selection
boundaries.
8. `Selection::Extend` should assert if the destination is managed by its
frame selection to detect a bug.
Differential Revision: https://phabricator.services.mozilla.com/D241587
`GetTextNode()` requires that the instance has already been initialized since
it requires the native anonymous `<div>`. And `IsEmpty()` is a public method.
Therefore, it should return `true` if there is no editor root, i.e., when it's
not been initialized yet after creation or destroyed.
Additionally, `TextControlState::GetValue()` should call
`TextEditor::ComputeTextValue()` if the editor has not been initialized because
it requires the native anonymous subtree to compute the value. I'm not sure
whether this is a bug when `<textarea>` is being initialized.
(I guess that it should get the default value of the text control element or
`mValue` in the case, but we should do that in another bug separately.)
I couldn't find the crash testcase, so, this does not contain a new test.
Differential Revision: https://phabricator.services.mozilla.com/D241543
We added a lot of crash tests for tricky cases for the editor module. Some of
them use the legacy DOM mutation events, and some of them caused serious issues.
Thus, we should enable the DOM mutation events at least running the tests to
detect regressions as soon as possible.
Differential Revision: https://phabricator.services.mozilla.com/D240709
So, `Text` editor can access the `Text` node quickly and it's not needed to
be grabbed by a lot of transactions. Additionally, when we support keeping
`TextEditor` instance even if the text control is reflowed (bug 1922141,
bug 1339052 and bug 1620050), transactions need to work with new anonymous
nodes. Therefore, retrieving `Text` node of `TextEditor` each time does make
sense rather than storing the node.
Depends on D240419
Differential Revision: https://phabricator.services.mozilla.com/D240420
The anonymous `<div>` of `TextEditor` has only one `Text` as its first child.
Therefore, we can make `TextEditor` simpler to access the `Text` node.
Differential Revision: https://phabricator.services.mozilla.com/D240419
Before the failure, all nodes which entirely selected have already deleted.
Therefore, if the selection range completely removes a list item and it starts
from end of preceding list, the range selects only block boundaries of the
list, e.g.,
```html
<div contenteditable>
{<dl>}
<dt>next item</dt>
```
Then, there is no content to move the first line of the right block. However,
if the `<dl>` is not the first child, the method returns `true` [1].
Therefore, it will mismatch with the actual result of `Run()`. Therefore, this
patch makes it return `false` if the range selects only block boundaries.
Additionally,
`AutoInclusiveAncestorBlockElementsJoiner::CanMergeLeftAndRightBlockElements`
has a bug and not updated when
`WhiteSpaceVisibilityKeeper::MergeFirstLineOfRightBlockElementIntoLeftBlockElement`
is changed. Therefore, this patch updates it to fix new assertion failures.
1. https://searchfox.org/mozilla-central/source/editor/libeditor/HTMLEditorDeleteHandler.cpp#6678-6680
Differential Revision: https://phabricator.services.mozilla.com/D239986
The style editing commands should be disabled in
`contenteditable="plaintext-only"`. Currently, we return `false` from
`execCommand`, but we still claim that the commands are enabled for
`queryCommandEnabled`.
Differential Revision: https://phabricator.services.mozilla.com/D239985
Enabling the new normalizer causes this assertion failure:
```
###!!! ASSERTION: Want to fire DOMNodeRemoved event, but it's not safe: 'Error', file /builds/worker/checkouts/gecko/dom/base/nsContentUtils.cpp:5586
#01: NS_DebugBreak [xpcom/base/nsDebugImpl.cpp:508]
#02: nsContentUtils::MaybeFireNodeRemoved(nsINode*, nsINode*) [dom/base/nsContentUtils.cpp:5587]
#03: nsINode::RemoveChild(nsINode&, mozilla::ErrorResult&) [dom/base/nsINode.cpp:0]
#04: mozilla::DeleteNodeTransaction::DoTransaction() [editor/libeditor/DeleteNodeTransaction.cpp:112]
#05: mozilla::EditorBase::DoTransactionInternal(nsITransaction*) [editor/libeditor/EditorBase.cpp:929]
#06: mozilla::EditorBase::DeleteNodeWithTransaction(nsIContent&) [editor/libeditor/EditorBase.cpp:2685]
#07: mozilla::WhiteSpaceVisibilityKeeper::NormalizeWhiteSpacesToSplitTextNodeAt(mozilla::HTMLEditor&, mozilla::EditorDOMPointBase<RefPtr<mozilla::dom::Text>, nsIContent*> const&, mozilla::EnumSet<mozilla::WhiteSpaceVisibilityKeeper::NormalizeOption, unsigned int>) [editor/libeditor/WhiteSpaceVisibilityKeeper.cpp:1384]
#08: mozilla::WhiteSpaceVisibilityKeeper::NormalizeWhiteSpacesToSplitAt(mozilla::HTMLEditor&, mozilla::EditorDOMPointBase<nsCOMPtr<nsINode>, nsCOMPtr<nsIContent> > const&, mozilla::EnumSet<mozilla::WhiteSpaceVisibilityKeeper::NormalizeOption, unsigned int>) [editor/libeditor/WhiteSpaceVisibilityKeeper.cpp:1599]
#09: mozilla::HTMLEditor::PrepareToInsertLineBreak(mozilla::HTMLEditor::LineBreakType, mozilla::EditorDOMPointBase<nsCOMPtr<nsINode>, nsCOMPtr<nsIContent> > const&) [editor/libeditor/HTMLEditor.cpp:4418]
#10: mozilla::EditorBase::InsertPaddingBRElementForEmptyLastLineWithTransaction(mozilla::EditorDOMPointBase<nsCOMPtr<nsINode>, nsCOMPtr<nsIContent> > const&) [editor/libeditor/EditorBase.cpp:2511]
#11: mozilla::HTMLEditor::InsertBRElementToEmptyListItemsAndTableCellsInRange(mozilla::RangeBoundaryBase<nsINode*, nsIContent*> const&, mozilla::RangeBoundaryBase<nsINode*, nsIContent*> const&) [editor/libeditor/HTMLEditSubActionHandler.cpp:0]
#12: mozilla::HTMLEditor::InitEditorContentAndSelection() [editor/libeditor/HTMLEditSubActionHandler.cpp:187]
#13: mozilla::HTMLEditor::Init(mozilla::dom::Document&, mozilla::ComposerCommandsUpdater&, unsigned int) [editor/libeditor/HTMLEditor.cpp:412]
#14: nsEditingSession::SetupEditorOnWindow(nsPIDOMWindowOuter&) [editor/composer/nsEditingSession.cpp:405]
```
The initialization is required only for empty table cells and empty list items
and they are typically not used at initial document. So, I think that it's fine
to stop normalizing white-spaces before succeeded to initialize `HTMLEditor`.
If this change causes a web-compat issue in the wild, let's make it run
asynchronously.
Differential Revision: https://phabricator.services.mozilla.com/D239473
For avoiding invisible white-space issues around composition string and for
avoiding making `CompositionTransaction` confused, we normalize white-spaces
around composition string boundaries with using NBSPs more than usual.
Therefore, we need to recover them as usual when ending the composition.
Differential Revision: https://phabricator.services.mozilla.com/D239469
Unfortunately, this patch becomes big because this includes multiple utility
methods to normalize white-spaces and touching a lot of places.
In some edge cases, this starts failing when the new white-space normalizer is
enabled.
```
FAIL execCommand("forwarddelete", false, ""): "a [] | b" - assert_equals: Modified text is wrong expected "a " but got "a "
FAIL execCommand("forwarddelete", false, ""): "a [] | b" - assert_equals: Modified text is wrong expected "a " but got "a "
FAIL execCommand("forwarddelete", false, ""): "a []b| c" - assert_equals: Modified text is wrong expected "a " but got "a "
FAIL execCommand("forwarddelete", false, ""): "a [] <span style=white-space:pre;> </span>" - assert_equals: expected "a <span style=\"white-space:pre;\"> </span>" but got "a <span style=\"white-space:pre;\"> </span>"
```
In these failures, we normalize the trailing white-spaces of the preceding
`Text` too, but Chrome does not do that. However, in some cases, they do
in similar cases. Therefore, it's hard to align all cases due to the handling
order difference. Additionally, these failure results are not odd. So, these
new failures are acceptable.
```
FAIL execCommand("forwarddelete", false, ""): "<span>abc[] <span> def</span></span>" - assert_equals: expected "<span>abc<span> def</span></span>" but got "<span>abc<span> def</span></span>"
FAIL execCommand("forwarddelete", false, ""): "<span><span>abc[] </span> def</span>" - assert_equals: expected "<span><span>abc</span> def</span>" but got "<span><span>abc</span> def</span>"
FAIL execCommand("forwarddelete", false, ""): "<span>abc[] </span><span> def</span>" - assert_equals: expected "<span>abc</span><span> def</span>" but got "<span>abc</span><span> def</span>"
FAIL execCommand("forwarddelete", false, ""): "<span>abc[] </span><span> def</span>" - assert_equals: expected "<span>abc </span><span> def</span>" but got "<span>abc </span><span> def</span>"
```
In these failures, we don't normalize the leading white-spaces of the following
`Text`. However, Chrome does so in some other cases. So, it's hard to align
the behavior in these cases too. The new normalizer ensures that the preceding
`Text` ends with a visible char. Therefore, the following `Text` won't starts
with new invisible white-spaces. Therefore, these failures are also acceptable.
```
FAIL execCommand("forwarddelete", false, ""): "<span style=white-space:pre;> [] </span> a" - assert_equals: expected "<span style=\"white-space:pre;\"> </span> a" but got "<span style=\"white-space:pre;\"> </span> a"
```
In this failure, we don't normalize the following `Text` but Chrome does it.
However, I don't think we should do it because this updates the `Text` which
is preformatted. Therefore, this is also acceptable.
So, I think that we can accept all new failures.
Differential Revision: https://phabricator.services.mozilla.com/D239468
Surprisingly, it has not normalize white-spaces around it. So, in some edge
cases, it might cause changing visibility of surrounding white-spaces.
Differential Revision: https://phabricator.services.mozilla.com/D239467
Unfortunately, this change does not make
`white-spaces-after-insert-image.tentative.html?paste-image` pass because we
paste the `<div>` at pasting the `<img>`, but Chrome pastes only the `<img>`.
Differential Revision: https://phabricator.services.mozilla.com/D239466
Unfortunately, this change does not make
`white-spaces-after-execCommand-insertparagraph.tentative.html` pass because
the insert paragraph handler inserts a temporary `<br>` element and that causes
normalizing the following white-spaces at the split point. However, Chrome
does not normalize the following white-spaces if it begins with an NBSP.
Differential Revision: https://phabricator.services.mozilla.com/D239465
When inserting a `<br>` element or a preformatted line break at middle of a
`Text`, we need to split it first. At this time, we should normalize the
surrounding white-spaces before split. Then, we can use only one
`ReplaceTextTransaction` instance for the normalization in the most cases.
Differential Revision: https://phabricator.services.mozilla.com/D239464
First, it makes it deletes invisible white-spaces at the insertion point.
This makes the further processing simpler.
Second, it extends the range to update in `Text` which will contain the
insertion string when it's not used for inserting nor updating composition
string, as containing all surrounding white-spaces at the insertion point.
Next, it normalizes the inserting string with the surrounding white-spaces with
the same rules as the other browsers especially as Chrome.
1. a collapsible white-space at start or end of a `Text` is always an NBSP.
2. a collapsible white-space immediately before or after a preformatted line
break is always an NBSP.
3. a collapsible white-space surrounded by non-collapsible chars is always an
ASCII white-space.
4. collapsible white-spaces are pairs of an NBSP and an ASCII white-space.
Then, we can make `HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal()`
stop normalizing white-spaces when inserting text.
Differential Revision: https://phabricator.services.mozilla.com/D239463
