Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
This doesn't change behavior on its own, but it's likely we want to make
the tab focusability more complicated in bug 1895184, and this will make
changes to this area less painful.
Differential Revision: https://phabricator.services.mozilla.com/D209525
`Selection.modify` with `"line"` calls `nsIFrame::PeekOffsetForLine` (which
is also used to move caret). To compute the destination,
`nsIFrame::PeekOffsetForLine` is used, but it may return a native anonymous
node because its helper function, `GetSelectionClosestFrame`, does not check
the boundary. On the other hand, it's used by pointing device event handlers
too. In this case, it needs to return a native anonymous node. Therefore,
the helper method requires additional flag to consider whether it can return
native anonymous node.
Differential Revision: https://phabricator.services.mozilla.com/D198358
The methods are in `nsCaret`, `nsFrameSelection` and `dom::Selection`. That
makes harder to read, and they are called each other, so, they are reused for
different purpose. Therefore, it must be better to move them into a new class.
Then, the name differences may become more unclear. If you think so, feel free
to request renaming some methods of them.
Differential Revision: https://phabricator.services.mozilla.com/D197288
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Note: Per my local test, the testcase is not 100% reliable because the selection
highlight can disappear intermittently for unknown reason after Step 2. As a
result, the testcase intermittently fails *without* my patch, but it's still
better than no test at all.
Differential Revision: https://phabricator.services.mozilla.com/D179027
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
A disabled form controls cannot be focused, and its frame selection is different
from the one for not-editable content. Use GetLastFocusedFrameSelection() (added
in Bug 253870) to get the correct frame selection that is visible to the user.
Add some basic tests for disabled <textarea> such as long pressing to select,
dragging, etc. They should behave the same as normal <textarea>.
Differential Revision: https://phabricator.services.mozilla.com/D151800
A disabled form controls cannot be focused, and its frame selection is different
from the one for not-editable content. Use GetLastFocusedFrameSelection() (added
in Bug 253870) to get the correct frame selection that is visible to the user.
Add some basic tests for disabled <textarea> such as long pressing to select,
dragging, etc. They should behave the same as normal <textarea>.
Differential Revision: https://phabricator.services.mozilla.com/D151800
To support magnifying glass on GeckoView, I would like to add `dragcaret`
event and, clientX and clientX in CaretStateChangedEvent chrome event.
Actually, accessible caret fires `presscaret` and `releasecaret` when
accessbile caret is pressed or released. But when dragging this caret, no
chrome event is fired. Since magnifying glass listens to moving this caret,
I would like `dargcaret` for GeckoView.
Also, Users' dragging point is necessary to set better position of magnifying
glass windows. So I also want client point of dragging point on `presscaret`
and `dragcaret` event.
This event and properties are on layout.accessiblecaret.magnifier.enabled=true,
So this can be only for GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D137965
For reducing the legacy behavior emulator of `nsContentUtils::ComparePoints`
and make it simpler, this patch makes it take `int64_t` as the offset.
Additionally, it's named "ComparePoints_AllowNegativeOffsets`.
Differential Revision: https://phabricator.services.mozilla.com/D132549
They are defined as "unsigned long" by the standards. So we should use
`uint32_t` rather than `int32_t` with the methods. However, layout code
uses `int32_t` a lot for representing the offset. Therefore, this patch
adds `*_FixOffset1` etc for the cases which cannot fix easily in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D131110
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
