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
This patch ensures that the global print_to_filename pref is checked
when initializing print settings from prefs.
It also fixes a regression which was preventing the Linux system dialog
from correctly reading its printer-specific print_to_filename prefs.
Differential Revision: https://phabricator.services.mozilla.com/D98975
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
This fixes a bunch of regressions:
- a wrong calculation in `GetIdleDeadlineHint()`, leading to pageload
regressions.
- in certain situations we'd use `StartupRefreshDriverTimer` instead
of `VsyncRefreshDriverTimer` when initializing timers early
- unnecessary use of `BrowserChild` on backends that don't opt for
per-browser-child vsync - i.e. all but Wayland.
This is partly done by reverting to pre-1645528 behaviour, although
with some code simplifications.
FTR: I also played with some more radical changes, but given the
complexity of the code involved I found the regression potential too
big. Thus this is the most conservative solution I could come up with.
Differential Revision: https://phabricator.services.mozilla.com/D100471
This fixes a bunch of regressions:
- a wrong calculation in `GetIdleDeadlineHint()`, leading to pageload
regressions.
- in certain situations we'd use `StartupRefreshDriverTimer` instead
of `VsyncRefreshDriverTimer` when initializing timers early
- unnecessary use of `BrowserChild` on backends that don't opt for
per-browser-child vsync - i.e. all but Wayland.
This is partly done by reverting to pre-1645528 behaviour, although
with some code simplifications.
FTR: I also played with some more radical changes, but given the
complexity of the code involved I found the regression potential too
big. Thus this is the most conservative solution I could come up with.
Differential Revision: https://phabricator.services.mozilla.com/D100471
For now, this subtest (ab)uses a fuzzy-failure allowance, to annotate a piece
of the test as a known failure on Windows (for an issue tracked in
bug 1680838).
The fuzzy annotation needs a bit of an increase, apparently, per at least one
failure log on Bug 1682294. This commit makes that increase, to avoid
test-failure-spam.
Differential Revision: https://phabricator.services.mozilla.com/D100477
This ensures that the notion of a scroll frame's scrollable ancestor used in
SetZeroMarginDisplayPortOnAsyncScrollableAncestor() to activate ancestors
when activating a scroll frame, matches what the actual ancestor is
according to display list building logic.
This avoids us taking the buggy "activate a scroll parent after the fact"
codepath (AutoCurrentActiveScrolledRootSetter::InsertScrollFrame()), which
can result in a display list with incorrect ASRs, in at least some cases.
Differential Revision: https://phabricator.services.mozilla.com/D100303
Even though this particular test-case is regressed by bug 1624080, this
is really a pre-existing bug.
The reason why we didn't crash before that bug is that we were
incorrectly not accounting for logical border-radius properties (like
border-end-end-radius) in has_author_specified_rules, which caused us to
not disable native appearance. This in turn ended up fixing up our value
returned from AddIntrinsicSizeOffset, which covered the bug.
Use saturating math properly to prevent returning negative sizes
incorrectly from that function, which causes deeper bugs down the
pipeline.
Given the crashtest relies on our particular nscoord represenation it
doesn't seem to be worth putting in WPT, but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D100186
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
We want to call it in nsFlexContainerFrame in the next part.
The method also tests form control elements via the helper
FormControlShrinksForPercentISize, not just replaced boxes, so rename it
for accuracy. We also rename the helper by dropping "I" from the
"PercentISize" because the axis the element contributingx to isn't
necessarily its inline-axis.
Differential Revision: https://phabricator.services.mozilla.com/D99951
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
This adds a new LookAndFeel implementation, RemoteLookAndFeel, which can
be used in content processes and is supplied with all of its values by the
parent process.
Co-authored-by: Cameron McCormack <cam@mcc.id.au>
Differential Revision: https://phabricator.services.mozilla.com/D97977
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
This patch doesn't change the behavior, but should improve the stability
and error handling of _selection_location_helper().
From the current intermittent pattern, `self.selection_rect_list(0)` can
fail sometimes. We set a retry limit of three times, and raise
exceptions with clearer message if we give up. Bug 1682382 tracks the
root cause behind this.
Differential Revision: https://phabricator.services.mozilla.com/D99288
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
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
Mirko Brodesser
Micah Tigley
Bogdan Tara
Masayuki Nakano
Butkovits Atila
Erik Nordin
Kartik Gautam
Sylvestre Ledru
Edgar Chen
Daniel Holbert
Mats Palmgren
Emilio Cobos Álvarez
Robert Mader
Narcis Beleuzu
Cosmin Sabou
Botond Ballo
Dorel Luca
Ting-Yu Lin
Steven MacLeod
Razvan Maries
Jed Davis
Sean Feng
Hiroyuki Ikezoe