This change is a rewrite, and is not expected to change the behavior.
Also, add a testcase exercising wrapping a long line.
Differential Revision: https://phabricator.services.mozilla.com/D128558
`nsTextFragment` is a storage of data node and DOM offset is `uint32_t`, but
some methods of `nsTextFragment` takes `int32_t` for the offset/length in
its text. Therefore, callers need to cast from `uint32_t` to `int32_t` if
the offset value is offset in a DOM node. Therefore, all methods of it should
take `uint32_t` values as offset/length in its text.
Differential Revision: https://phabricator.services.mozilla.com/D127923
`nsFocusManager` does not send `focus` event in some cases, e.g., non-editable
root element gets focus. However, the element may become editable later without
a focus move. Therefore, even if `IMEStateManager::sContent` is `nullptr`,
`IMEStateManager::UpdateIMEState()` and `IMEStateManager::FocusInEditor()` are
called with focused content when the uncomposed document is in design mode.
With this change, editor does not need to call `IMEStateManager` methods with
`nullptr` when it's in `designMode`. Therefore, we can get rid of
`GetFocusedContentForIME()` which just returns `nullptr` if focused content is
in design mode.
Differential Revision: https://phabricator.services.mozilla.com/D127612
There are a lot of check of `Document`'s editable state **with** comments. This
means that it's unclear for developers that only `Document` node is editable in
design mode.
Additionally, there are some points which use composed document rather than
uncomposed document even though the raw API uses uncomposed document. Comparing
with the other browsers, checking uncomposed document is compatible behavior,
i.e., nodes in shadow trees are not editable unless `contenteditable`.
Therefore, `nsINode` should have a method to check whether it's in design mode
or not.
Note that it may be called with a node in UA widget. Therefore, this patch
adds new checks if it's in UA widget subtree or native anonymous subtree,
checking whether it's in design mode with its host.
Differential Revision: https://phabricator.services.mozilla.com/D126764
If the old DeprecatedNext() returned needs-more-text, we'd just force a break at the EOL position anyhow;
so the new behavior of Next(), always treating end-of-text as a break position, gives us this for free.
Differential Revision: https://phabricator.services.mozilla.com/D127806
If the old DeprecatedNext() returned needs-more-text, we'd just force a break at the EOL position anyhow;
so the new behavior of Next(), always treating end-of-text as a break position, gives us this for free.
Differential Revision: https://phabricator.services.mozilla.com/D127806
This patch is similar to Bug 1728708 Part 4, but for line breaker. This
should make the future integration of ICU4X line segmenter easier. A
UAX14 compatible line breaker always breaks at the end of text
(rule LB3 [1]), and ICU4X line segmenter has this behavior, too.
Current LineBreaker::Next() doesn't treat the end of text as a line
break opportunity, so this patch deprecates it by renaming it, and add a
new Next() method.
TestASCIILB() has adopted the new Next(). All the other callers of the
DeprecatedNext (nsPlainTextSerializer, nsXMLContentSerializer,
InternetCiter) should be audited later, possibly with the removal of
Prev() because the all the usages are very close to Prev().
[1] https://www.unicode.org/reports/tr14/#LB3
Differential Revision: https://phabricator.services.mozilla.com/D127379
Building with `ac_add_options --disable-unified-build` on macOS hits the following -Wunreachable-code-return warnings-as-errors:
editor/libeditor/HTMLEditor.cpp:4341:26 [-Wunreachable-code-return] 'return' will never be executed
editor/libeditor/HTMLTableEditor.cpp:1629:10: warning: 'return' will never be executed [-Wunreachable-code-return]
Differential Revision: https://phabricator.services.mozilla.com/D126441
The test requires to support allowing nested `execCommand` if we want to run
completely. From point of view of the purose of crashtests, we should allow
it for testing in more complicated situation. Therefore, this patch allows
it while the test is running by the pref.
Differential Revision: https://phabricator.services.mozilla.com/D125914
I have no idea how to make the test result stable because the intermittent
failure is caused by a race of `IMEContentObserver`'s content query performend
at vsync and `keypress` event after the `keydown` event. Therefore, I try to
fix the root cause of the failure.
There are two paths reaching a public method of editor with pending
notifications. One is `keypress` event listener of the editor. The other is
`execCommand` related methods of `Document`. Therefore, we should make them
flush pending notifications before accessing editor, but the cost may be too
expensive. So we should consider whether we should flush pending notifications
or not as far as later.
Note that we cannot fix the `beforeinput` cases because flushing pending
notifications after dispatching `beforeinput` event may cause oranges. It'll
be fixed while I'm working on bug 1710784.
Differential Revision: https://phabricator.services.mozilla.com/D125805
If we flush pending notifications before calling `execCommand` in
`insert-*-in-void-element.tentative.html`, `HTMLEditor` does not work because
`GetActiveEditingHost()` returns `nullptr`. This is wrong because `Selection`
cannot cross native anonymous subtree boundaries and the selection collapsed in
`<input>` element is valid. Therefore, it should not check whether the content
has independent selection or not.
Differential Revision: https://phabricator.services.mozilla.com/D125791
Although we don't have a testcase, `HTMLEditor` may need to delete a text node
if it's created for composition. If it's not allowed, users may see staying
composition string in disabled editor.
Differential Revision: https://phabricator.services.mozilla.com/D125502
And this renames the method to `ExtendOrShrinkRangeToDelete` for alining to
new behavior changed by the following patch.
Depends on D125028
Differential Revision: https://phabricator.services.mozilla.com/D125029
Similar to the previous patch, this patch makes `insertLineBreak` command
handler of `HTMLEditor` may insert a linefeed character instead of `<br>`
element for compatibility with Blink/WebKit.
Note that for making same name rules as `insertParagraphSeparator` command
handlers, this patch renames
`HTMLEditor::InsertBRElementAtSelectionWithTransaction()` to
`InsertLineBreakAsSubAction()` and moves
`EditorBase::InsertLineBreakAsSubAction()` to `TextEditor` since it's
used only by `TextEditor` instance.
Depends on D124731
Differential Revision: https://phabricator.services.mozilla.com/D124732
Blink and WebKit inserts linefeed character for `insertParagraphSeparator`
command if:
* the insertion point's block parent is an editing host
* the editing host's outside display is "inline"
* the editing host's white space style preformats linefeed characters
For web-compat, we should do this in these conditions.
Depends on D124562
Differential Revision: https://phabricator.services.mozilla.com/D124731
This uses `setTimeout` for emulating original test as far as possible, but
unfortunately, we need to change `data` URI of the `<iframe>` to `srcdoc`
due to cross-origin error.
Differential Revision: https://phabricator.services.mozilla.com/D124846
This does NOT add tests to `inserttext` command which includes linefeed
characters with other characters. It seems that Blink handles 2 or more
length string is handled as multiple calls for every character. So each
linefeed character is handled as `insertparagraph`, but Gecko treats the
linefeed characters as-is. We should add the tests later with changing
Gecko's behavior, but for now, we should keep current behavior because
this difference must not be trobule in the wild, but we need to improve
preformatted string handler of Gecko better against reported web-compat
issues.
Differential Revision: https://phabricator.services.mozilla.com/D124562
`HTMLEditor` tries to collect all children in a line. However, it does not
handle preformatted linefeed characters. Especially when there is a
preformatted linefeed immediately before a block boundary, it becomes invisible.
So, the range of line needs to extend the range correctly similar to the case
if there is an invisible `<br>` element.
Differential Revision: https://phabricator.services.mozilla.com/D124561
Ting-Yu Lin
Alexandru Michis
Evgenia Kotovich
Masayuki Nakano
Jonathan Kew
Geoff Brown
Csoregi Natalia
Chris Peterson