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
A missing #include of jsapi.h was causing a build failure when building the
entire browser with ENABLE_RECORD_TUPLE set. Removed dependencies on this
header file.
Differential Revision: https://phabricator.services.mozilla.com/D156494
`SelectionActionDelegate.Selection.clientRect` isn't fission compatible. It is
better to use screen coordinate for selection data, instead of client
coordinate since it has no easy way to calculate client coordinate with
fission.
If we can have `screenRect`, `mTempMatrix` and `mTempRect` are unnecessary, so
we should be marked as deprecated too.
Differential Revision: https://phabricator.services.mozilla.com/D161416
I would like screen coordinate version by screen pixel for
`getElementBoundingScreenRect` for GeckoView to support fission since it
returns CSS pixel.
Differential Revision: https://phabricator.services.mozilla.com/D161415
There's only one worrying timeout
(css/css-contain/container-queries/inline-size-bfc-floats.html), but it
isn't a "hard" hang, but an invalidation loop.
Let's enable this by default on nightly to get some feedback while we
work on it and the remaining issues that block enabling them by default.
Differential Revision: https://phabricator.services.mozilla.com/D162292
Naming of MIR and LIR nodes WasmLoadObjectField et al is somewhat confusing:
* It is inconsistent which of the fields point to the base of the memory area
to access, and which if any are the keepalive-object pointer, eg:
- WasmLoadObjectField: `obj` is the base pointer
- WasmLoadObjectDataField: `data` is the base pointer, `obj` is the keepalive
* having `Data` in the name doesn't really convey the meaning "also carries a
keepalive pointer"
They are renamed thusly:
WasmLoadObjectField -> WasmLoadField
WasmLoadObjectDataField -> WasmLoadFieldKA
WasmStoreObjectDataField -> WasmStoreFieldKA
WasmStoreObjectDataRefField -> WasmStoreFieldRefKA
Changes:
* change `Data` in the name to `KA` at the end, to indicate that the node also
takes a keepalive operand
* consistently use `ka` as the name of the keepalive MIR/LIR node
* consistently use `obj` as the name of the base pointer MIR/LIR node
Differential Revision: https://phabricator.services.mozilla.com/D161252
The Element caller only cares about avoiding a flush and can use the
observable parent layout stuff.
The scrollframe one clearly wants the cross-process version according to
the comment.
Differential Revision: https://phabricator.services.mozilla.com/D162477
There's only one worrying timeout
(css/css-contain/container-queries/inline-size-bfc-floats.html), but it
isn't a "hard" hang, but an invalidation loop.
Let's enable this by default on nightly to get some feedback while we
work on it and the remaining issues that block enabling them by default.
Differential Revision: https://phabricator.services.mozilla.com/D162292
This is the first part of the bug. A clarification in the spec states
that a grid item spanning multiple tracks, which include a flexible
track, should not participate in auto min sizing calculation and should
have a width of 0.
https://w3c.github.io/csswg-drafts/css-grid-1/#min-size-auto
For the reftest, the previous overrides are removed as the correct
behaviour is now implemented.
Differential Revision: https://phabricator.services.mozilla.com/D160900
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
There's a bug (bug 1800022) that wheel event listeners in the browser process
badly interact with overscroll even so we'd avoid the bug here.
Differential Revision: https://phabricator.services.mozilla.com/D161752
Otherwise prefs set in the previous test case will persist. In fact
some of test cases were lacking "browser.swipe.navigation-icon-move-distance".
Differential Revision: https://phabricator.services.mozilla.com/D161751
The stuff calls PanGestureBlockState::SetNeedsToWaitForContentResponse which sets
mWaitingForContentResponse flag, but the flag will clobbered in
MaybeRequestContentResponse().
Differential Revision: https://phabricator.services.mozilla.com/D160432
