The telemetry result is written in bug 1706266 comment 1:
https://bugzilla.mozilla.org/show_bug.cgi?id=1706266#c1
`increasefontsize`, `decreasefontsize`, `gethtml`, `heading` and `readonly` are
obviously not used by web apps in the wild. Therefore, they can be disabled
in all channels.
`contentReadOnly` and `insertBrOnReturn` are odd. The usage is really low (less
than 1% of beta users). However, the number of documents which used the command
is about 1k samples. The result of the commands are not tiny (making the editor
not editable or changing the behavior at typing `Enter` key in `<div>`, `<p>`,
etc). Therefore, it's hard to use them in web apps which supports not only
Gecko. So I guess that they are collected the number of used by automated
tests of somebody because of the constant number in other beta versions.
Perhaps, we should disable it only in Nightly channel for now, and after a
couple of releases, we should try to disable those commands too later.
Depends on D130328
Differential Revision: https://phabricator.services.mozilla.com/D130329
I'd like to split utilities for all editors and only for `HTMLEditor`.
This moves some trivial classes into new `HTMLEditHelpers.h`. Perhaps, it's
better if we can move them into `HTMLEditUtils.h`, but it has too many inline
method definitions so that adding new classes into it makes it much bigger.
Depends on D130349
Differential Revision: https://phabricator.services.mozilla.com/D130425
Now, it does not notify nobody before joining the nodes. Therefore, it can
return error immediately if it fails to create a transaction to join the given
nodes.
Additionally, this patch makes it return `NS_ERROR_EDITOR_DESTROYED` if the
editor is destroyed while it handles to join nodes. Therefore, we can get rid
of the check by the callers.
Differential Revision: https://phabricator.services.mozilla.com/D130349
`TopLevelEditSubActionData::WillJoinNodes()` and
`TopLevelEditSubActionData::DidJoinNodes()` are called only by
`HTMLEditor::JoinNodesWithTransaction()`. `WillJoinNodes()` assumes that
all children or text data in `aLeftContent` is moved to head of `aRightContent`.
Therefore, it just stores length of `aLeftContent` and `DidJoinNodes()` lets
`AddPointToChangedRange()` know the joined point.
Same value is stored by `HTMLEditor::JoinNodesWithTransaction()`. Therefore,
it can create same DOM point at calling `DidJoinNodes()` so that we can get
rid of `WillJoinNodes()`.
Differential Revision: https://phabricator.services.mozilla.com/D130348
Now, it does not notify nobody before joining the nodes. Therefore, it can
return error immediately if it fails to create a transaction to join the given
nodes.
Additionally, this patch makes it return `NS_ERROR_EDITOR_DESTROYED` if the
editor is destroyed while it handles to join nodes. Therefore, we can get rid
of the check by the callers.
Differential Revision: https://phabricator.services.mozilla.com/D130349
`TopLevelEditSubActionData::WillJoinNodes()` and
`TopLevelEditSubActionData::DidJoinNodes()` are called only by
`HTMLEditor::JoinNodesWithTransaction()`. `WillJoinNodes()` assumes that
all children or text data in `aLeftContent` is moved to head of `aRightContent`.
Therefore, it just stores length of `aLeftContent` and `DidJoinNodes()` lets
`AddPointToChangedRange()` know the joined point.
Same value is stored by `HTMLEditor::JoinNodesWithTransaction()`. Therefore,
it can create same DOM point at calling `DidJoinNodes()` so that we can get
rid of `WillJoinNodes()`.
Differential Revision: https://phabricator.services.mozilla.com/D130348
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
LineBreaker has no member variables and acts like "namespaces" with
utility functions. Therefore, its methods can be static and called
directly without needing a LineBreaker instance.
Rename GetJISx4051Breaks() to ComputeBreakPositions() per review
feedbacks.
Differential Revision: https://phabricator.services.mozilla.com/D129107
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
Masayuki Nakano
Cristian Tuns
Dan Minor
Noemi Erli
Ting-Yu Lin
Greg Tatum
Butkovits Atila
Evgenia Kotovich
Alexandru Michis
Sam Foster
Jonathan Kew
Geoff Brown
Csoregi Natalia