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
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
