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
In the unit-tests, flushing is not done. This was prevented implicitly
by nulling `mPresShell`. This change makes that explicit by stubbing
`MaybeFlushLayout`.
Note that `IsTerminated`, which is called in the same context is already
virtual, so I expect this to not have a noticeable performance-impact.
Depends on D102607
Differential Revision: https://phabricator.services.mozilla.com/D102608
Encapsulates flushing-related functionality.
Please see part 25) for further simplifcation of `LayoutFlusher`.
Depends on D102413
Differential Revision: https://phabricator.services.mozilla.com/D102414
