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
This is the most important situation. If selection is collapsed to a edge of a
link, the other browsers does not insert new content into the link. So, from
the point of view of web developers, this cause should work exactly same as
the other browsers.
Note that the new failures in `editing/run/inserttext.html` are passed only
on Gecko. So, the test should be updated after fixing this bug.
Differential Revision: https://phabricator.services.mozilla.com/D101004
We always compute the tabindex value, so just return it to the caller
all the time. This allows us to use early-returns which makes the code a
bit easier to follow.
This patch shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D100423
Steps to reproduce:
1. Open https://bugzilla.mozilla.org/home
(Note the cursor is already blinking in the <input>
"Enter a bug number or some search terms")
2. Pinch-zoom in.
3. Tap on the <input> "Enter a bug number or some search terms."
4. Pan/scroll the page, and the scrolling is very laggy.
Without this patch, AccessibleCaret disables APZ incorrectly via the
above operations. Here's an analysis.
In step 2, `OnScrollEnd()` called at the end of the pinch-zoom operation
is supposed to reset `mIsScrollStarted` to `false`, but `GetCaretMode()`
returns `CaretMode::Cursor` because the page already has a focus on
<input>. We are early-returned from `OnScrollEnd()` because
`mLastUpdateCaretMode` is still the default value `CaretMode::None`.
In step 3, tapping the <input> will call `UpdateCaretsForCursorMode()`,
setting `mIsCaretPositionChanged` to `true`. Then
`UpdateShouldDisableApz()` incorrectly sets `mShouldDisableApz` to
`true` because we still have `mIsScrollStarted=true`.
In step 4, the operation is laggy because APZ is disabled.
This patch fixed this bug by removing the guarding statement
`mLastUpdateCaretMode != GetCaretMode()` from three callback methods.
The statements were added in the very first patch introducing
`AccessibleCaretManager`. I don't recall why we needed them. (Perhaps to
avoid unnecessary updates notified from other PresShell?). Anyway, since
then, these callbacks have evolved to update carets only if any caret is
logically visible, so I don't see why we need these guards nowadays. By
doing so, `mIsScrollStarted` can be reset to `false` in `OnScrollEnd()`
in step 2.
Differential Revision: https://phabricator.services.mozilla.com/D99284
Those methods have two sources to check after call: the return value and the pointer. This can be confusing as a caller may think they should check both when they don't need to. Since the two always behaves together (a valid pointer + NS_OK, or nullptr + NS_ERROR_FAILURE), this replaces the return value with the pointer.
Differential Revision: https://phabricator.services.mozilla.com/D79196
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
