We can relax about `GetElementOrParentElement*()` because they just return
`nullptr` when selection anchor is a `Document` node.
Additionally, this patch renames the internal APIs to the names similar to
modern DOM API.
Finally, this adds automated test for
`nsIHTMLEditor.getElementOrParentByTagName()`.
Differential Revision: https://phabricator.services.mozilla.com/D70152
--HG--
extra : moz-landing-system : lando
When it refers computed value of style, it may flush pending notifications.
Therefore, they should be marked as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D70151
--HG--
extra : moz-landing-system : lando
Some methods take `StyleType` to work them with specified values or computed
values. This method hides `StyleType` into `CSSEditUtils` and splits the
public methods which took `StyleType` to 2 methods, one is for working with
specified values, the other is for working with computed values.
Additionally, this patch fixes some argument name and type.
Differential Revision: https://phabricator.services.mozilla.com/D70149
--HG--
extra : moz-landing-system : lando
When it refers computed value of style, it may flush pending notifications.
Therefore, they should be marked as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D70151
--HG--
extra : moz-landing-system : lando
Some methods take `StyleType` to work them with specified values or computed
values. This method hides `StyleType` into `CSSEditUtils` and splits the
public methods which took `StyleType` to 2 methods, one is for working with
specified values, the other is for working with computed values.
Additionally, this patch fixes some argument name and type.
Differential Revision: https://phabricator.services.mozilla.com/D70149
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
underline and strike use `text-decoration` property, which is a
shorthand and may include other longhand property values, e.g.
`text-decoration-color`. In order to set `aAll` flag correctly, we
should not just compare the computed values between `firstValue` and
`theValue`. This patch makes the HTMLStyleEditor more independent of
the serializations of the computed values on text-decoration.
If https://github.com/w3c/editing/issues/241 is accepted, we can just
replace `text-decoration` with `text-decoration-line` and drop this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D69619
--HG--
extra : moz-landing-system : lando
Only `TypeInState` stores last caret position. So, only it can detect the
case caret is moved from outside of `<a href>` element and is now at start
or end of it.
Note that this patch does not assume `<a href>` has an empty text node with
another inline element. If we supported it, the loop would be more complicated
and it's really unrealistic edge case. Therefore, it's reasonable to ignore
the case.
And also this patch works with `ArrowUp`/`ArrowDown`/`PageUp`/`PageDown`
cases. However, I have no idea to reject such cases. But I guess that
it does not so bad behavior for users because caret does not moved in
a text node in `<a href>`.
Depends on D69479
Differential Revision: https://phabricator.services.mozilla.com/D69480
--HG--
extra : moz-landing-system : lando
The selection validation should be checked in the constructor of
`ParagraphStateAtSelection` because
`EditorBase::IsSelectionRangeContainerNotContent()` needs edit action data.
Additionally, this patch adds a test for `nsIHTMLEditor.getParagraphState()`.
Differential Revision: https://phabricator.services.mozilla.com/D69316
--HG--
extra : moz-landing-system : lando
I'm still not sure how the crash occurs especially on Thunderbird. However,
it could be possible if `pointToInsert` is modified with an orphan node (i.e.,
when `pointToInsert.GetContainer()` returns `nullptr`). Therefore, this patch
makes it check whether the inserted node stays at expected position or not,
and if it's not, make it keep inserting next content nodes to previous position
because it must look like odd that inserting to different position.
Differential Revision: https://phabricator.services.mozilla.com/D69154
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D69315
--HG--
extra : moz-landing-system : lando
`AlignStateAtSelection` class is instantiated outside of editor class so that
we shouldn't make each user guarantee that there is selection range
(fortunately, the putting off cost is really low).
And as far as I tested, Blink and WebKit does not throw exception when
`Document.qeuryCommand*("justify*")` is called without selection ranges.
So, this patch also prevents exception in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D68755
--HG--
extra : moz-landing-system : lando
Now, `WSType` is used only by `WSRunScanner`, `WSRunObject` and `WSScanResult`.
We should hide this mysterious `enum` from other classes for making other
developers easier to understand. Therefore, this patch moves `WSType` into
`WSScanResult` and share it with `WSRunScanner` with making them friends.
Depends on D68675
Differential Revision: https://phabricator.services.mozilla.com/D68676
--HG--
extra : moz-landing-system : lando
Surprisingly, each value meaning of `WSFragment::mType` is different from
`WSFragment::mRightType` and `WSFragment::mLeftType`. It uses only 3 bits,
`WSType::normalWS`, `WSType::leadingWS` and `WSType::trailingWS`.
According to the second `if` block of `WSRunScanner::GetRuns()`, the latter
2 values mean whether the fragment starts from and/or ends by a hard line.
And also, according to there, `normalWS` means the run is visible or not.
(However, according to the first `if` block, `Visible::Yes` might be set to
for empty fragment too, but I have no better idea of its name.)
Therefore, `mType & WSType::leadningWS` can call "is start of hard line",
`mType & WSType::trailingWS` can call "is end of hard line",
`mType == WSType::normalWS` can call "is visible and not edges of hard line"
and `mType & WSType::normalWS` can call "is not edges of hard line".
So, 3 `bool` members can represent all of their status. Therefore, we should
get rid of this odd use case of `WSType`.
Depends on D68674
Differential Revision: https://phabricator.services.mozilla.com/D68675
--HG--
extra : moz-landing-system : lando
Similarly, it indicates the previous content type of the fragment.
Depends on D68673
Differential Revision: https://phabricator.services.mozilla.com/D68674
--HG--
extra : moz-landing-system : lando
It means why the `WSFragment` ends by. I.e., it tells next content type of
the fragment.
Differential Revision: https://phabricator.services.mozilla.com/D68673
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D68747
--HG--
extra : moz-landing-system : lando
I give up to write a clean patch for this bug with current design. The trigger
is indeed bug 1618089, but this is a hidden regression of bug 1530649.
Starting from bug 1530649, `WSRunObject` started to use `EditorDOMPoint` for
storing the specified point. And it may store (or only store) child node.
Therefore, if it points a text node and it's removed by
`WSRunObject::DeleteRange()`, the point becomes invalid even if its offset
is still valid. Therefore, we should make `mStartScanPoint` and `mEndScanPoint`
forget their child before DOM tree change ideally, but it means that we need
to compute offset of the child every time before changing the DOM tree. We
cannot accept this safest approach due to performance reason.
Therefore, this patch just invalidates `mStartScanPoint`'s child node only when
it's reused after the DOM tree is modified.
Differential Revision: https://phabricator.services.mozilla.com/D68048
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
Helps to determine which methods of `nsFrameSelection` are intended to
be called only for the `eNormal` Selection.
Driven by the idea that state of `nsFrameSelection` relevant only for
the `eNormal` Selection should later move to a `NormalSelection` class.
Differential Revision: https://phabricator.services.mozilla.com/D67445
--HG--
extra : moz-landing-system : lando
