This is still fairly incomplete (i.e. no capturing, etc), but it allows
a transition to "start", and then finish (on the next frame always, for
now) or timeout, appropriately.
I think it's in a reviewable shape, given that. There's one known
divergence from the spec, which is described in
https://github.com/w3c/csswg-drafts/issues/10822
Differential Revision: https://phabricator.services.mozilla.com/D220843
As per comments in bug 1910411's patches and others, it's not a useful
metric, specially now that we have LCP and so on.
Actually there doesn't seem to be any consumer of it since bug 1892001.
Differential Revision: https://phabricator.services.mozilla.com/D218489
I don't think HasObservers() || HasImageRequests() is the right check in
general given we have other tick reasons like that.
Differential Revision: https://phabricator.services.mozilla.com/D218378
Deal with throttled docs only once upfront, since
ShouldThrottleFrameRequests is kind of expensive (doing a full
IntersectionObserver check).
Add proper spec quotes too, while at it. This also fixes the failure
that got the previous patch backed out.
Differential Revision: https://phabricator.services.mozilla.com/D217708
Deal with throttled docs only once upfront, since
ShouldThrottleFrameRequests is kind of expensive (doing a full
IntersectionObserver check).
Add proper spec quotes too, while at it. This also fixes the failure
that got the previous patch backed out.
Differential Revision: https://phabricator.services.mozilla.com/D217708
Deal with throttled docs only once upfront, since
ShouldThrottleFrameRequests is kind of expensive (doing a full
IntersectionObserver check).
Add proper spec quotes too, while at it. This also fixes the failure
that got the previous patch backed out.
Differential Revision: https://phabricator.services.mozilla.com/D217708
This will make bug 1800882 simpler. Ideally we'd follow the spec a lot
more closely to the letter (e.g. per spec we should deal with a document
frame request callback calling something like
window.frames[0].contentWindow.requestAnimationFrame() and running that
in the same tick, but for now this doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217197
This telemetry was trying to measure three things:
* The time spent during style / layout in a tick. This is useful.
* The times SetNeed{Style,Layout} flush have been called. This is not a
particularly useful metric, there's not much to learn or change from
it. Any call is basically free as long as they're consecutive /
there's no flush in between.
* The number of times layout / style has been flushed during a tick.
This is more useful than the above but, similarly, there's not too
much to be learned here. Number of flushes can be completely
orthogonal to how expensive it has been.
It also had a number of flaws:
* It is recorded per-PresShell, so we get multiple pings per tick.
* Similarly, if a sub-frame dies before the tick, we just never report
that time.
Instead, refactor it to make it simpler, and just record the first
metric reliably. This simplifies the code substantially, and I don't
think we're losing much.
The histograms are also expired. We might want to renew this, I'll file
a follow-up to either properly renew this if we plan to look at it, or
remove the code entirely from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D210907
We should be more consistent about what stuff runs and what doesn't when
the pres context is getting torn down...
MANUAL PUSH: Trivialish orange fix CLOSED TREE
Not sure how testable this is, for a11y purposes. The other consumer is
some XRSession stuff which doesn't seem to care too much about the
timing of this.
Differential Revision: https://phabricator.services.mozilla.com/D210384
This doesn't change behavior intentionally, though it annotates places
where our code doesn't match the spec right now, and adds comments and
quotes the HTML spec in the relevant places.
Some things that this highlights:
* Resize steps are fired at the wrong time.
* Some of our animation stuff seems sketchy / out of place too to me
(AnimationTimeline observes the refresh driver at the style phase).
* Focus fix-up is out of order (that's known, bug 1788741 for tests).
* Our layout flush stuff should probably be better integrated / closer
to the resize observer loop.
* Display observers are run before stuff like ResizeObserver runs. That
might be a problem for accessibility's NotificationController?
Again, these are intentionally not addressed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D210279
There's no call to AddRefreshObserver(FlushType::Layout), so we don't
need to track layout flushes. The only reason we need
mLayoutFlushObservers is so that reflows triggered from the style flush
get processed. But at that point, we can just flush layout directly.
There's no really good distinction between style flushes and layout
flushes with container queries anyways, so this makes the code simpler
to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D209924
The CSS Box Sizing specification indicates that last remembered sizes
are recorded "at the time that ResizeObserver events are determined and
delivered" [1].
In bug 1807253, we changed the implementation of when proximity to the
viewport of `content-visibility: auto` nodes are determined and of when
resize observations are broadcast, in order to align with the latest
version of the HTML specification [2]. We continue to use an internal
`Document::mLastRememberedSizeObserver` to update last remembered sizes
but it has been causing issues (e.g. bug 1867090 and bug 1880928) and
could be replaced by a direct update before broadcasting resize
observations.
This is what the current patch is doing. The elements currently observed
by `Document::mLastRememberedSizeObserver` are now stored on a
`Document::mElementsWithLastRememberedSize` hashset and a new function
`Document::UpdateLastRememberedSizes` is called before broadcasting
resize observations, and peforms the work of `LastRememberedSizeCallback`
and of `CalculateBoxSize` (with `aBox=Content_box`).
The only behavior change is in the `while(true)` loop from
`DetermineProximityToViewportAndNotifyResizeObservers`: at each step
we update the last remember sizes for elements of arbitrary depth, and
don't use these depths for calculating `shallowestTargetDepth`. This is
fine, since our `LastRememberedSizeCallback` only records current box
sizes without causing significant side effects (e.g. execution of
JavaScript code) that may require a relayout.
[1] https://drafts.csswg.org/css-sizing-4/#last-remembered
[2] https://html.spec.whatwg.org/#update-the-rendering
Differential Revision: https://phabricator.services.mozilla.com/D202571
Most are brought over straightforwardly, their Telemetry callsites reworded
to use Glean, with mirroring to the Telemetry probes taken care of by the Glean
Interface For Firefox Telemetry (see the telemetry_mirror property).
There were two special cases: PERF_DOM_CONTENT_LOADED_FROM_RESPONSESTART_MS,
and PERF_DOM_CONTENT_LOADED_MS. Both were removed as they were unused.
Differential Revision: https://phabricator.services.mozilla.com/D200867
This is unfortunately somewhat hard to test, because paint suppression
is not really quite observable by the page.
This makes sure that we don't report resize observations etc until the
page has been laid out for other reasons.
Differential Revision: https://phabricator.services.mozilla.com/D194910
The basic idea is to check if there are pending tasks also right after RefreshDriver tick has been handled, not only before tick.
But in this new case we can't predict how much time is needed for other tasks, so just a bit of time is given.
The patch tweaks also other things: CanDoCatchUpTick (which is used by catch-up ticks and FinishedWaitingForTransaction) should
return false if the active timer is blocked because of mSuspendVsyncPriorityTicksUntil.
And to make it easier to check whether driver is blocked, mSuspendVsyncPriorityTicksUntil is changed to rely on local time, not the time stamp
from vsync.
The low priority notify is changed so that it uses member variables from the driver and in case it does trigger a tick, it uses the most recent skipped
values.
Differential Revision: https://phabricator.services.mozilla.com/D193409
Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
The basic idea is to check if there are pending tasks also right after RefreshDriver tick has been handled, not only before tick.
But in this new case we can't predict how much time is needed for other tasks, so just a bit of time is given.
The patch tweaks also other things: CanDoCatchUpTick (which is used by catch-up ticks and FinishedWaitingForTransaction) should
return false if the active timer is blocked because of mSuspendVsyncPriorityTicksUntil.
And to make it easier to check whether driver is blocked, mSuspendVsyncPriorityTicksUntil is changed to rely on local time, not the time stamp
from vsync.
The low priority notify is changed so that it uses member variables from the driver and in case it does trigger a tick, it uses the most recent skipped
values.
Differential Revision: https://phabricator.services.mozilla.com/D193409
This patch doesn't change behavior; it just removes some redundant checks.
(Note that the tight-scoping around nsAutoMicroTask/ReduceAnimations is
important for the RAII object to be torn down at the intended time; but it
doesn't need its own if-check.)
Depends on D191909
Differential Revision: https://phabricator.services.mozilla.com/D191911
Butkovits Atila