`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--HG--
extra : moz-landing-system : lando
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow because:
- it may create some `nsRange` instances.
- it users `nsContentUtils::ComparePoints()` multiple times.
Therefore, we can improve the performance if we can stop using it in some
places. First, this patch creates `Selection::SetStartAndEnd()` and
`Selection::SetStartAndEndInLimiter()` for internal use. They remove
current ranges, reuse `nsRange` instance as far as possible and add new
range which is set by their arguments. Then, this patch makes
`Selection::SelectAllChildren()` stop using `Selection::Extend()`. At this
time, this fixes a web-compat issue. `Selection::Expand()` cannot cross the
selection limiter boundary when there is a limiter (e.g., when an editing host
has focus). But we can now fix this with using the new internal API.
Note that methods in editor shouldn't move selection to outside of active
editing host. Therefore, this patch adds `Selection::SetStartAndEndInLimiter()`
and `Selection::SetBaseAndExtentInLimiter()` for them.
Differential Revision: https://phabricator.services.mozilla.com/D23459
--HG--
extra : moz-landing-system : lando
Actually, we only support `text/unicode` mime type on Android clipboard backend. But Android API 16+ supports `text/html`, so we should support this type since Chrome/Blink already supports it.
Differential Revision: https://phabricator.services.mozilla.com/D22659
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--HG--
extra : moz-landing-system : lando
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow because:
- it may create some `nsRange` instances.
- it users `nsContentUtils::ComparePoints()` multiple times.
Therefore, we can improve the performance if we can stop using it in some
places. First, this patch creates `Selection::SetStartAndEnd()` and
`Selection::SetStartAndEndInLimiter()` for internal use. They remove
current ranges, reuse `nsRange` instance as far as possible and add new
range which is set by their arguments. Then, this patch makes
`Selection::SelectAllChildren()` stop using `Selection::Extend()`. At this
time, this fixes a web-compat issue. `Selection::Expand()` cannot cross the
selection limiter boundary when there is a limiter (e.g., when an editing host
has focus). But we can now fix this with using the new internal API.
Note that methods in editor shouldn't move selection to outside of active
editing host. Therefore, this patch adds `Selection::SetStartAndEndInLimiter()`
and `Selection::SetBaseAndExtentInLimiter()` for them.
Differential Revision: https://phabricator.services.mozilla.com/D23459
--HG--
extra : moz-landing-system : lando
`PresShell.h` is exposed as `mozilla/PresShell.h` and `PresShell` is the only
concrete class of `nsIPresShell`. Therefore, we have no reason to access
`PresShell` via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D23277
--HG--
extra : moz-landing-system : lando
Summary: Actually, we only support `text/unicode` mime type on Android clipboard backend. But Android API 16+ supports `text/html`, so we should support this type since Chrome/Blink already supports it.
Reviewers: #geckoview-reviewers, snorp
Reviewed By: #geckoview-reviewers, snorp
Bug #: 676268
Differential Revision: https://phabricator.services.mozilla.com/D22659
--HG--
extra : rebase_source : 17ef0aa06b83b812bb9bccfab93a72e0b37f9652
Firefox, comm-central and bluegriffon don't use `*JSAndPlugin*` methods of
`nsIEditingSession` from script. Let's remove or move to `nsEditingSession`.
Differential Revision: https://phabricator.services.mozilla.com/D22465
--HG--
extra : rebase_source : 256fb4025fe8c6f5a61d5b015af942ff65759c23
Only Firefox has an operation to paste clipboard data as quoted text
(Control + middle button paste). Input Events Level 1 and Level 2 declared
new inputType value for this operation. Therefore, we should support it.
Differential Revision: https://phabricator.services.mozilla.com/D22067
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
Accidentally, I removed the check in the previous landing (bug 1529190). This
patch restores it.
Differential Revision: https://phabricator.services.mozilla.com/D20970
--HG--
extra : moz-landing-system : lando
As far as I've tested, Chrome does not throw exception even when editor is
destroyed or editor content is modified unexpectedly. So, we should return
`NS_OK` from most public methods of editor when internal methods return
`NS_ERROR_EDITOR_DESTROYED` or `NS_ERROR_EDITOR_UNEXPECTED_DOM_TREE`.
Differential Revision: https://phabricator.services.mozilla.com/D20811
--HG--
extra : moz-landing-system : lando
We should stop handling splitting nodes if mutation event listeners move or
remove the split nodes unexpectedly because the post processors may not be
able to keep handling the nodes. For example, if a node is moved to outside
of editing host, we shouldn't touch it anymore due to non-editable.
This patch makes `EditorBase::DoSplitNode()` return new error for making
any parent callers stop their job, but note that the following patch makes
any public methods expose the new error as exception for compatibility with
Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D20810
--HG--
extra : moz-landing-system : lando
Oddly, `SplitNodeTransaction::DoTransaction()` checks the result of
`EditorBase::DoSplitNode()` only when it's not allowed to change `Selection`.
We should make it always check the result.
Differential Revision: https://phabricator.services.mozilla.com/D20809
--HG--
extra : moz-landing-system : lando
`InsertTagCommand::DoCommandParams()` inserts given URL to `href` of `<a>` or
`src` of `<img>`. However, it treats the given URL includes only ASCII
characters. Therefore, we cannot insert URL including non-ASCII characters
with `execCommand("createLink")` nor `execCommand("insertImage")`.
This patch makes `nsHTMLDocument::ExecCommand()` set the param as `nsString`
and makes `InsertTagCommand::DoCommandParams()` retrieve it with `GetString()`.
Differential Revision: https://phabricator.services.mozilla.com/D20615
--HG--
extra : moz-landing-system : lando
`InsertTagCommand::DoCommandParams()` uses `Element::SetAttribute()` which takes
`nsAString` as attribute name. For avoiding unnecessary copy of attribute name,
we should make it use `Element::SetAttr()` which takes `nsAtom` instead.
Differential Revision: https://phabricator.services.mozilla.com/D20614
--HG--
extra : moz-landing-system : lando
"cmd_copyAndCollapseToEnd" is referred only by CopyPasteAssistent (even
including comm-central and BlueGriffon), but CopyPasteAssistent won't receive
"copy" command to send it.
So, it seems that we can get rid of a lot around CopyPasteAssistent but this
patch just changes the mapping in it ("copy" is mapped to "cmd_copy") and
removes command handlers of "cmd_copyAndCollapseToEnd" completely.
Differential Revision: https://phabricator.services.mozilla.com/D20612
--HG--
extra : moz-landing-system : lando
"cmd_setDocumentOptions" is never used now (even including comm-central and
BlueGriffon). So, we can stop supporting this command and we can get rid of
the command handler, SetDocumentOptionsCommand.
Differential Revision: https://phabricator.services.mozilla.com/D20611
--HG--
extra : moz-landing-system : lando
"cmd_clearUndo" is never used now (even including comm-central and BlueGriffon).
So, we can stop supporting this command and we can get rid of the command
handler, ClearUndoCommand.
Differential Revision: https://phabricator.services.mozilla.com/D20610
--HG--
extra : moz-landing-system : lando
Those probes are now expired and we got enough data:
- Almost no user uses the grip to move absolute positioned element
- There were over one thousand users using the inline table editor and the object resizers.
- Such users keep using even after we disabled the UIs by default.
Perhaps, such small number of users keep using the UIs, i.e., I guess the
number won't become smaller in short term. Therefore, this patch removes the
telemetry probes and members of HTMLEditor which are necessary to call
Telemetry API.
Differential Revision: https://phabricator.services.mozilla.com/D20609
--HG--
extra : moz-landing-system : lando
This code was already handling the world going away, but did not handle the case
of just getting unbound, which can happen if some selection listener (e.g.,
AccessibleCaret) flushes layout.
Differential Revision: https://phabricator.services.mozilla.com/D20469
--HG--
extra : moz-landing-system : lando
Only nsBlockFrame and its subclasses recognize the nsIFrame::eBlockFrame
flag, so we can replace the usage of the flag with either
nsIFrame::IsBlockFrameOrSubclass() or a do_QueryFrame().
Differential Revision: https://phabricator.services.mozilla.com/D20542
--HG--
extra : moz-landing-system : lando
Even less so on reframe, where it's just unsound to do so. I had to give a value
to eSetValue_Internal, since otherwise I cannot check for its presence. I can
further special-case the reframe case if you prefer.
Differential Revision: https://phabricator.services.mozilla.com/D20133
--HG--
extra : moz-landing-system : lando
DataTransfer should have more 2 constructors. One takes |const nsAString&| and
sets its data to the string. The other takes |nsITransferable*| and stores only
its data with DataTransferItem.
If given data is external resource like the case of `HTMLEditor::PasteTransferable()`,
we should copy its data to each DataTransferItem because nsITransferable is not
cycle-collectable, but DataTransfer may be grabbed by JS. Unfortunately, adding
new path to initialize DataTransfer with nsITransferable instance is too risky
because DataTransfer and DataTransferItem work together to initialize each of
them if DataTransfer is in external mode. Therefore, this patch makes the
new constructor temporarily sets it to in external mode, then, cache usable types
first, then, call `FillAllExternalData()` to make each DataTransferItem initializes
its data by itself, finally, make the constructor set it to internal mode and release
nsITransferable instance. This is ugly implementation but the most reasonable
way for now because:
- We don't need to change DataTransfer nor DataTransferItem a lot in this bug.
- We don't need to duplicate any code like a loop in `CacheExternalData()`.
In another bug, we should redesign DataTransfer and DataTransferItem to
make DataTransferable easier to be added new constructors.
Differential Revision: https://phabricator.services.mozilla.com/D19298
--HG--
extra : moz-landing-system : lando
InputEvent.dataTransfer should be set to non-null when InputEvent.inputType
is "insertFromPaste", "insertFromDrop" or "insertReplacementText" and
editor is an HTMLEditor instance:
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
("insertTranspose" and "insertFromYank" are not currently supported on Gecko.)
This patch makes nsContentUtils::DispatchInputEvent() take dataTransfer value
and EditorBase set it via AutoEditActionDataSetter like data value.
However, we need to create other constructors of DataTransfer to create its
read-only instances initialized with nsITransferable or nsAString. This will
be implemented by the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D19297
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data when the event
is caused by `document.execCommand()` with `backColor`, `foreColor` nor
`hiliteColor`, Safari supports styling color with touchbar and in that case,
Safari sets it (*1).
Additionally, currently Safari uses `rgb()` to represents a color value and
using same rule to serializing color value for CSS OM matches Safari's behavior
and can represent any valid color values.
This patch makes given color value parsed and then serialized with same code
in style system. If the value is `currentcolor`, `inherit`, `initial` or `reset`, sets
the value as-is for now. Additionally, when given value is invalid, sets the value
as-is for forward compatibility.
Note that automated tests will be added into input-events-exec-command.html
by the last patch.
1. https://github.com/w3c/input-events/issues/94#issuecomment-461061517
Differential Revision: https://phabricator.services.mozilla.com/D19295
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data value when
InputEvent.inputType is "fontName", but it's easy to implement. Therefore, this
patch implements it as declaration of Input Events.
This patch uses given value as-is. Perhaps, this shouldn't cause any problems
because such value can be set to Element.style.fontFamily without any changes.
Note that automated test will be added into WPT later.
Differential Revision: https://phabricator.services.mozilla.com/D19294
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data value when
InputEvent.inputType is "insertLink", but it's easy to implement. Therefore,
this patch implements it as declaration of Input Events.
This patch sets the value to raw href attribute value because we create
<a> element without absolute URI when web apps call execCommand("createLink")
with relative URI.
Differential Revision: https://phabricator.services.mozilla.com/D19291
--HG--
extra : moz-landing-system : lando
When InputEvent.inputType is "formatSetBlockTextDirection" or
"formatSetInlineTextDirection", InputEvent.data value should be one of
"ltr", "rtl", "auto" or "null".
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
We only supports "ltr" and "rtl" when user switches the direction with
Accel + Shift + X. Therefore this patch makes EditorBase set the data
to "ltr" or "rtl".
Oddly, with synthesizing the shortcut keys, the command is not executed
properly in the automated test. Therefore, this patch dispatches the
command directly.
Differential Revision: https://phabricator.services.mozilla.com/D19288
--HG--
extra : moz-landing-system : lando
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
Both Input Events Level 1 and Level 2 declare that InputEvent.data should be
set to inserting string only on TextEditor when InputEvent.inputType is
"insertFromPaste", "insertFromPasteAsQuotation", "insertFromDrop",
"insertTranspose", "insertReplacementText" or "insertFromYank".
Currently, we support only "insertFromPaste", "insertFromDrop",
"insertReplacementText". Therefore, this patch makes TextEditor set
EditorBase::mEditActionData::mData only for them (and the instance is not
HTMLEditor's).
Differential Revision: https://phabricator.services.mozilla.com/D19287
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
No one uses CheckCurrentWordNoSuggest. So I would like to get a rid of this
method. And this method is only user of mozSpellChecker::CheckWord. So
mozSpellChecker::CheckWord shouldn't allow that aSuggestions is nullptr on
content process since we already have async API as mozSpellChecker::CheckWords.
Differential Revision: https://phabricator.services.mozilla.com/D19303
--HG--
extra : moz-landing-system : lando
Summary:
Editor changes caret visibility during drag and drop. But when destroying
editor, we don't restore caret state. So we should restore it when destroying
editor.
Tags: #secure-revision
Bug #: 1496118
Differential Revision: https://phabricator.services.mozilla.com/D18923
--HG--
extra : rebase_source : 157f2c9e69857c7f7adb916af2a319392c4d125a
