There are 2 bugs. One is that `SplitNodeDeepWithTransaction` tries to split
comment node, but it fails. The other is, the failure result is not checked
by `HandleInsertParagraphInHeadingElement`. Therefore, the original head
element's previous node may not be a heading element.
Depends on D106591
Differential Revision: https://phabricator.services.mozilla.com/D106620
browserscope is no longer maintained, so contenteditable=false case is
incorrect now. So I would like to update this tests for non editable case.
Differential Revision: https://phabricator.services.mozilla.com/D96299
Since `WSScanResult` can return non-editable/non-removable text node,
`HandleDeleteAtomicContent` is called with non editable text node, then it cannot
remove atomic content.
This fix doesn't follow other block case such as added newer test.
Differential Revision: https://phabricator.services.mozilla.com/D96298
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
Applying default edit action for some shortcut keys on Linux and macOS
causes some oranges. The new failure reasons are:
* The keyboard events are consumed in the bubbling phase of the system
group if editor has focus (`EditorEventListener` or `TextInputListener`
does it).
* No key combinations are mapped to per-word move or select on macOS.
* Home/End keys on macOS do not change selection.
Therefore, this adjusts each failure case for the new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D102878
The issue is that the test was depending on the native resizers (or on a
previous test having loaded the non-native ones).
The first snapshot will not have resizers (because we just started the
load of the SVG) and thus following snapshots would fail.
Wait for the load event and pre-show the ltr textarea, so that the
resizer is known loaded.
This doesn't happen without the non-native theme because that uses
native resizers which don't depend on the image load.
Differential Revision: https://phabricator.services.mozilla.com/D103591
According to the debug log and result on tryserver, the frequency of this
test failure becomes higher is caused by bug 1676966. When global reflow
is kicked during dragging the grabber, the implicit capture is released
forcibly. Fortunately, editor behavior shouldn't depend on font list
loading system, so, disabling the feature until fixing bug 1688430 is fine.
Differential Revision: https://phabricator.services.mozilla.com/D102889
This is same behavior as the other browsers. When selection is collapsed to
a edge of a link after deletion, we should stop applying link style to new
inserted content.
Differential Revision: https://phabricator.services.mozilla.com/D101006
When selection is not collapsed and is across link element boundary, we can
assume that user does not try to modify the link text because the other
browsers behave so. Therefore, we should take the same behavior in this case.
Note that all the new failures of `editing/run/inserttext.html` are passed
only on Gecko. So, it should be updated in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D101005
This is the most important situation. If selection is collapsed to a edge of a
link, the other browsers does not insert new content into the link. So, from
the point of view of web developers, this cause should work exactly same as
the other browsers.
Note that the new failures in `editing/run/inserttext.html` are passed only
on Gecko. So, the test should be updated after fixing this bug.
Differential Revision: https://phabricator.services.mozilla.com/D101004
When caret is not moved but selection change command is fired, it means that
the caret is already set to start or end of editing host. In this case, we
should stop keeping link style for new inserting content because otherwise,
user cannot exit from the first or last link with arrow keys.
Differential Revision: https://phabricator.services.mozilla.com/D101003
Although different from the other browsers' behavior, our traditional behavior
might be better than them because the behavior on the other browser does not
allow users to insert new content at start nor end of a link.
However, we can relax more about keeping traditional behavior for web-compat.
Perhaps, only when caret is moved from the other side of first or last character
in the link and moves caret to the edge of the link with arrow key, we should
allow users to modify the link text.
Otherwise, e.g., `Home` and `End` key press should make it stop keeping the
link style. This helps advanced users who are familiar with keyboard navigatin
in editor.
Note that this patch also changes the condition which checks
`aReason & nsISelectionListener::KEYPRESS_REASON` to check also
`nsISelectionListener::COLLAPSETO_START_REASON` and
`nsISelectionListener::COLLAPSETO_END_REASON` because all of them are
set by `nsFrameSelection::MoveCaret` exclusively.
https://searchfox.org/mozilla-central/rev/a0ccd492719b1ad2106f6456549be62a76f45acb/layout/generic/nsFrameSelection.cpp#738,741,745
Therefore, they should be treated as same as a key press.
Note that they are also set by `Selection::CollapseToStart` and
`Selection::CollapseToEnd` too. But a following patch will add a new
reason to notify selection listeners of caused by JS. So, the problem
will be fixed by the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D101002
When mouse button is clicked outside a link element but caret is positioned
start or end of the link, our traditional behavior keeps inserting new content
into the link. But this is different from the other browsers, and it does
not make sense to treat such selection change is intended to keep typing in
the link element.
Therefore, this patch makes `TypeInState::OnSelectionChange()` handle
selection change reason is `mousedown` and `mouseup` cases. However,
it cannot know whether the event was fired in the parent link element or
not. Therefore, this patch makes `HTMLEditorEventListener` notifies
`TypeInState` of mouse events via `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D101001
They were designed for object resizer and grabber to move absolutely positioned
element. Therefore, they should have better name to explain what they do.
Then, we can create event listener methods for generic cases.
Differential Revision: https://phabricator.services.mozilla.com/D100999
Currently, the test checks the result only in `contenteditable`, but I'd be
better to do same tests in `designMode` editor too.
Additionally, for detecting regressions of the following patches, it should
check the result of 2nd typing too because inserting text into end of a link
element may cause unlink it.
Differential Revision: https://phabricator.services.mozilla.com/D100997
DONTBUILD because this is a comment-only change and hence doesn't affect
behavior at all.
I ran across this typo in nsPageFrame.cpp, and figured I might as well grep for
it and fix it more comprehensively. And while I'm at it, I also fixed some
neighboring instances of a duplicated word around a linebreak, in
nsXMLContentSerializer.h.
Differential Revision: https://phabricator.services.mozilla.com/D100852
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
When we don't match exactly dictionary name with `lang` attribute, we look for
language name. When looking for language name (ex. en/fr etc), we don't
consider the priority by application/system locale. So if lang=en, it may be
selected by character order. Most case is that en-GB is always selected if it
is installed.
We should respect application/system locale if language name is matched to
current content language before random selection.
Depends on D99336
Differential Revision: https://phabricator.services.mozilla.com/D99337
Actually, our locale service doesn't use UTF-16 for locale name and it will
be ASCII. Although dictionary name of spell checker is locale/language name,
it still uses UTF-16. To use locale API, I should replace it with `ACString`.
Differential Revision: https://phabricator.services.mozilla.com/D99336
Turns out this causes a bit of overhead when appending to an AutoString,
because Truncate() calls SetToEmptyBuffer(), which makes it go from
inline-string to buffer string, and next time we append we need to turn
the string from a buffer-based string to an inline string again, which
is some minor, but measurable, work, while profiling some
micro-benchmarks.
Probably we should make Truncate() a no-op for a zero-length string, but
I'll send that separately.
Differential Revision: https://phabricator.services.mozilla.com/D99493
Kagami Sascha Rosylight
Masayuki Nakano
Makoto Kato
Tom Schuster
Emilio Cobos Álvarez
Jonathan Kew
Cameron McCormack
Noemi Erli
Mihai Alexandru Michis
Henri Sivonen
Kartik Gautam
Daniel Holbert
Andi-Bogdan Postelnicu
Cosmin Sabou
Dorel Luca
Simon Giesecke