Its only user was the BSPTree test suite, for its purposes
define a TestPolygon using an empty BSPTestData class instead.
Differential Revision: https://phabricator.services.mozilla.com/D162929
This fixes a bug which caused Firefox windows to become frozen after some time.
Full credit goes to Susan and RandyS for bisecting the regressor of this bug, and
to Jeff DeFouw for debugging the issue and finding the cause.
The bug here is a "state race" between the VsyncDispatcher state and
the VsyncSource state. Both are protected by locks, and the code that
runs in those locks respectively can see a different orders of invocations.
VsyncDispatcher::UpdateVsyncStatus does this thing where it updates its state inside
a lock, gathers some information, and then calls methods on VsyncSource *outside* the lock.
Since it calls those methods outside the lock, these calls can end up being executed
in a different order than the state changes were observed inside the lock.
Here's the bad scenario in detail, with the same VsyncDispatcher being used from
two different threads, turning a Remove,Add into an Add,Remove:
```
Thread A Thread B
VsyncDispatcher::UpdateVsync
|
|----> Enter VsyncDispatcher lock
| | VsyncDispatcher::UpdateVsync
| | state->mIsObservingVsync = false |
| | (We want to stop listening) |
| | |
|<---- Exit VsyncDispatcher lock |
| |----> Enter VsyncDispatcher lock
| | |
| | | state->mIsObservingVsync = true
| | | (We want to start listening)
| | |
| |<---- Exit VsyncDispatcher lock
| |
| |----> Enter VsyncSource::AddVsyncDispatcher
| | |
| | |----> Enter VsyncSource lock
| | | |
| | | | state->mDispatchers.Contains(aVsyncDispatcher)
|----> VsyncSource::RemoveVsyncDispatcher | | | VsyncDispatcher already present in list, not doing anything
| | | | |
| | | |<---- Exit VsyncSource lock
| | | |
| | |<---- Exit VsyncSource::AddVsyncDispatcher
| |----> Enter VsyncSource lock
| | |
| | | Removing aVsyncDispatcher from state->mDispatchers
| | |
| |<---- Exit VsyncSource lock
| |
|<---- Exit VsyncSource::AddVsyncDispatcher
```
Now the VsyncDispatcher thinks it is still observing vsync, but it is
no longer registered with the VsyncSource.
This patch makes it so that two calls to AddVsyncDispatcher followed by one call
to RemoveVsyncDispatcher result in the VsyncDispatcher still being registered.
AddVsyncDispatcher is no longer idempotent.
Differential Revision: https://phabricator.services.mozilla.com/D162760
We used to provide links to the bug numbers but this was broken
somewhere along the way. Now it is provided the failure IDs from which
it can attempt to extract a bug number, as well as always display any
failure ID and message whenever possible.
Differential Revision: https://phabricator.services.mozilla.com/D162734
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
The stuff calls PanGestureBlockState::SetNeedsToWaitForContentResponse which sets
mWaitingForContentResponse flag, but the flag will clobbered in
MaybeRequestContentResponse().
Differential Revision: https://phabricator.services.mozilla.com/D160432
This in effect reverts part of bug 1756400, so that we only do the full
per-language fontconfig substitution processing for locales that use
CJK or Arabic script. These are the locales where it is likely that
there may be custom per-language/locale font preferences that need to
be respected.
(In theory fontconfig could be set up with per-language rules even for
distinctions like 'en-US' vs 'en-GB', or 'en' vs 'fr' vs 'de', etc.,
and we will no longer respect these. But it is almost vanishingly unlikely
that separate font mappings for such distinctions will really be needed,
and the cost of doing all the lookups separately for every lang tag,
even within simple writing systems like Latin, is excessive.)
No automated tests, as this is heavily dependent on the system configuration.
Differential Revision: https://phabricator.services.mozilla.com/D162304
it started as a single method new_frame_ready with a composite parameter, to be split into two functions that end up calling the same HandleFrameOneDoc with a composite parameter so the extra function doesn't provide anything.
Differential Revision: https://phabricator.services.mozilla.com/D162299
Only transactions that contain the generate_frame flag are tracked by the pending frame and frame build counters.
This patch attempts to make this clearer with two small adjustments:
Firstly by putting the IncPendingFrameCount call right next to Transaction::GenerateFrame.
Secondly, undoing the hack in wr_notifier_wake_up. The latter is called outside of normal rendered/tracked frames and was calling HandleFrameOneDoc which decrements the rendered frame counter. To compensate it had to manually increment both counters via IncPendingFrameCount and manually decrement the built frame counter via DecPendingFrameBuildCount. Instead this patch introduces the aTrackedFrame argument so that HandleFrameOneDoc only fiddles with the counters when needed and wake_up does not have to hack around it.
Differential Revision: https://phabricator.services.mozilla.com/D162298
mSkippedComposite's purpose is to keep track of the fact that the window is not up to date because the previous composite was skipped. This informs RetrySkippedComposite that a new frame is needed to get the latest changes rendered. As soon as we successfully schedule a composite know that the latest changes are en route to be rendered so we don't need RetrySkippedComposite to push an additional frame later.
Differential Revision: https://phabricator.services.mozilla.com/D162297
The previous name could have related to any situation where a composite is needed such as when animating or receiving transactions, but the function is actually specifically about scheduling a new composite if the previous one was skipped.
Differential Revision: https://phabricator.services.mozilla.com/D162295
- Ensure that the pending frame count is decremented by HandleFrameOneDoc even after some of the rare early-outs.
- Always check TooManyPendingFrames in CompositeToTarget.
It is unclear that these will actually catch (all of) the extraneous skipped frames. If anything, the simplification will make further investigation easier.
Differential Revision: https://phabricator.services.mozilla.com/D162294
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
The stuff calls PanGestureBlockState::SetNeedsToWaitForContentResponse which sets
mWaitingForContentResponse flag, but the flag will clobbered in
MaybeRequestContentResponse().
Differential Revision: https://phabricator.services.mozilla.com/D160432
According to crash data, some devices by OPPO and realme and OnePlus seem to
crash when using Font Match API. I would like to disable it until root cause
finds.
Differential Revision: https://phabricator.services.mozilla.com/D162185
By default, BorrowSnapshot is pessimistic and forces DrawTargetWebgl to return a data snapshot on
the assumption that the snapshot might be used off thread. However, if we actually know the DrawTarget
we're going to be drawing the snapshot to, then we can check if they're both DrawTargetWebgls with
the same internal SharedContext. In that case, we can use a SourceSurfaceWebgl snapshot which can
pass through a GPU texture to the target. This requires us to plumb the DrawTarget down through
SurfaceFromElement all the way to DrawTargetWebgl to make this decision.
Differential Revision: https://phabricator.services.mozilla.com/D162176
When we fallback without recreating the GPU process, we should ensure
that the gfxVar updates have been processed before recreating the
compositor sessions. This is achieved by blocking on the sync
PGPU::SendDeviceStatus IPDL message. This additional sync message only
happens during fallback and thus should be fairly cheap.
Differential Revision: https://phabricator.services.mozilla.com/D162020
It seems like Chrome allows this and it's relatively common.
We don't have a good reason to continue blocking these profiles.
Differential Revision: https://phabricator.services.mozilla.com/D162024
APZ cannot currently scroll in directions which are overflow:hidden
(it does not know the full scroll range bounds in those directions).
Therefore, main-thread scrolling in these directions should not be
handed off to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D161351
Adrien Champion
Brad Werth
Botond Ballo
Butkovits Atila
Barret Rennie
Lee Salzman
Jonathan Kew
Stanca Serban
Cristian Tuns
Sylvestre Ledru
Cosmin Sabou
Andrew Osmond
André Bargull
Noemi Erli
Markus Stange
Marco Castelluccio
Hiroyuki Ikezoe
Shravan Narayan
sotaro
Tom Ritter
Nicolas Silva
Razvan Cojocaru
Makoto Kato
Chris H-C
Mathew Hodson
Marian-Vasile Laza
Jeff Muizelaar
Emilio Cobos Álvarez
Csoregi Natalia