Currently, `EditorBase::EndUpdateViewBatch()` does this, but it's before `input`
event. Therefore, if an `input` event listener changes the target elements'
position and/or size, user will see broken UI. Therefore, it should be updated
at editor finishes everything.
Differential Revision: https://phabricator.services.mozilla.com/D128871
There is also a mozilla::intl::Locale in intl/locale/MozLocale.h. This naming
collision was causing crashes in debug builds where the wrong destructor ended
up being called. This patch renames the intl/locale/MozLocale.h class to
MozLocale.
I've filed Bug 1736017 to move callers of the MozLocale version to the
unified intl/components/Locale version.
Differential Revision: https://phabricator.services.mozilla.com/D128593
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
* bug 1266185 was specifically about the how the editor behaves when the application handler dialog pops up, so I've restored this behavior by setting alwaysAskBeforeHandling true for the octet-stream mime-type
Differential Revision: https://phabricator.services.mozilla.com/D127889
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
Currently, `mozInlineSpellChecker` handles events in the default group. This
means that the listener may not run if web app stops the propagation. For
keeping the event listener order as far as possible, this patch changes to
listen to the event at capturing phase in the system group (editor handles
the events at bubbling phase in the system group).
Additionally, it listens to `keypress` events for handling caret/selection
changes. However, they should be handled at `keydown` because those keys
are not printable. Therefore, this patch changes to listen to `keydown`
events, but this could change the race between running the scheduled spellcheck
and following `keypress` event which is dispatched only for chrome code and
C++ event listeners. However, this may not change it actually because the
race is changed only when the following `keypress` event delays too much.
https://searchfox.org/mozilla-central/rev/2eebd6e256fa0355e08421265e57ee1307836d92/extensions/spellcheck/src/mozInlineSpellChecker.cpp#503-504
Differential Revision: https://phabricator.services.mozilla.com/D126635
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
* Rename arguments so that their names are consistent with Next().
* Make the function not assert on an empty string, i.e. aLen == 0, like
Next().
* Fix an undefined behavior when the user passes aTextLen == aOffset.
The methods used to access `aText[aOffset]` that is clearly out of range
because the string may not be null-terminated. After this patch, it
returns a sentinel WordRange when aLen == aPos.
* Add document and gtest TestFindWordWithEmptyString().
* Change the sentinel return value to {aLen,aLen} for FindWord(), and
adapt one caller.
Differential Revision: https://phabricator.services.mozilla.com/D125434
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
Greg Tatum
Masayuki Nakano
Butkovits Atila
Dan Minor
Evgenia Kotovich
Noemi Erli
Ting-Yu Lin
Alexandru Michis
Sam Foster
Jonathan Kew
Geoff Brown
Csoregi Natalia
Emilio Cobos Álvarez
Chris Peterson