If insertion string ends with ASCII whitespace and there is no following
content in the block, `HTMLEditRules::AdjustWhitespaces()` needs to insert
`<br>` element. It's called only by `HTMLEditRules::AfterEditInner()` and
that does only simple things with `WSRunObject`. Therefore, this moves the
code into `AfterEditInner()`.
For making it adjust the whitespaces, `HTMLEditRules::WillInsertText()` needs
to notify `AfterEditInner()` of dirty range with `mDocChangeRange`. Therefore,
this patch makes it set `mDocChangeRange` manually after inserting composition
string.
On the other hand, there is another bug. `WSRunObject` was designed to treat
only inserting text for `WSRunObject::InsertText()`. I.e., not designed to
treat replacing existing composition string with new string. Therefore,
`WSRunObject::InsertText()` adjusts whitespaces only around start of
composition string. Therefore, if composition string ends with an ASCII
whitespace, it's not replaced with NBSP and that causes:
- failing `WSRunObject::AdjustWhitespaces()` inserts `<br>` element at
`AfterEditInner()` of committing composition.
- then, next composition's first `WSRunObject::InsertText()` removes the
last whitespace due to not followed by `<br>` nor any other content.
Therefore, this patch makes `WSRunObject` takes 2 DOM points to be able to
treat replaced range.
In strictly speaking, the latter change require more changes and tests for
supporting replacement with any other methods. However, it's risky and out
of scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D26423
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
`nsPICommandUpdater` is a scriptable interface, but nobody refers it from JS,
and it's implemented only by `nsCommandManager`. Therefore, we can get rid
of this interface.
Additionally, `nsCommandManager::Init()` is called only by `nsDocShell`, which
is the only instantiater of the class, and returns error only when given window
is nullptr. Therefore, we can make the constructor take the window instead.
Differential Revision: https://phabricator.services.mozilla.com/D25729
--HG--
extra : moz-landing-system : lando
`nsIControllerCommandTable` isn't implemented with JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, it's inherited only by nsControllerCommandTable. So, all users
in C++ can treat the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D25727
--HG--
extra : moz-landing-system : lando
`nsICommandManager` isn't implemented by JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, this patch makes all users in C++ use `nsCommandManager` which is
the only implementation of `nsICommandManager`. This avoids QI from
`nsICommandManager` to `nsPICommandUpdater`.
Differential Revision: https://phabricator.services.mozilla.com/D25726
--HG--
extra : moz-landing-system : lando
This is the last step to be able to call matchMedia on display: none iframes.
This is green, except for some startup preference query tests that I'm going to
address in a blocking bug (making LangGroupFontPrefs global, basically).
The setup is similar to the ShadowRoot one, except we don't eagerly keep the
StyleSet around up-to-date, we only fill it if it ever had a pres context.
Differential Revision: https://phabricator.services.mozilla.com/D23903
--HG--
extra : moz-landing-system : lando
If user disables clipboard events, it means that they don't want to expose
clipboard data to web apps even if web apps cannot handle "paste" operation.
Therefore, they must not want to leak clipboard data with `InputEvent.data`
and `InputEvent.dataTransfer`.
This patch makes `InputEvent::GetData()` and `InputEvent::GetDataTransfer()`
returns empty string or new `DataTransfer` object which has only empty string
if:
- They are called by content JS.
- The event is a trusted event.
- `inputType` value is `insertFromPaste` or `insertFromPasteAsQuotation`.
The reason why we don't return null for both is, Input Events spec declares
`data` or `dataTransfer` shouldn't be null in the `inputType` values. And
the reason why we don't return empty `DataTransfer` is, web apps may expect
at least one data is stored in non-null `dataTransfer` value.
Differential Revision: https://phabricator.services.mozilla.com/D25350
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
No one (m-c, c-c and bluegriffon) uses nsIPlaintextEditor.setWrapColumn from
script. It is used from C++ only.
Differential Revision: https://phabricator.services.mozilla.com/D25363
--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
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
