We do it right after layout to make sure sizes are up-to-date and before
determining proximities to viewport of 'content-visibility: auto' to
make sure we are not incorrectly recording the size of a previously
"skipping its content" node.
This change is covered by tests added in D202403.
Differential Revision: https://phabricator.services.mozilla.com/D202731
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
This patch doesn't change behavior.
As noted in the code-comment: ideally we should fully-modernize to nsTHashMap
or similar, but that's a larger project and will require a bit of care to be
sure we're preserving the semantics that this struct imposes on itself right
now (e.g. subdocuments clearing their parent-document pointer, as part of
removal from the map). For now, I'm just taking the incremental/trivial win of
using UniquePtr to remove explicit `new`/`delete` statements.
Differential Revision: https://phabricator.services.mozilla.com/D202904
GeckoView disables spell checker. When disabling it and contenteditable
attribute is changed, we may not initialize editor.
So we should ignore an error of spell check.
Differential Revision: https://phabricator.services.mozilla.com/D202408
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
The order of items in the mTopLayer array determines the order that we build display items, so if it changes we need to mark the frames as modified so that retained display list partial updates can properly merge.
Differential Revision: https://phabricator.services.mozilla.com/D201214
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
Glean-based Use Counter metrics are cheaper and work as well,
so let's use them instead.
Though we do have metric name strings available in a string table in GleanJSMetrics.cpp,
access is through metric_entry_t which has information not available to usecounters.py.
So for now we return char* literals from the use counter increment fns.
Differential Revision: https://phabricator.services.mozilla.com/D199933
This code runs unconditionally from "update the rendering". It flushing
throttled animations kinda defeats the point of throttled animations.
This was kind of papered before bug 1807253 because we didn't
unconditionally flush if there were resize observers.
Differential Revision: https://phabricator.services.mozilla.com/D200194
Glean-based Use Counter metrics are cheaper and work as well,
so let's use them instead.
Though we do have metric name strings available in a string table in GleanJSMetrics.cpp,
access is through metric_entry_t which has information not available to usecounters.py.
So for now we return char* literals from the use counter increment fns.
Differential Revision: https://phabricator.services.mozilla.com/D199933
Glean-based Use Counter metrics are cheaper and work as well,
so let's use them instead.
Though we do have metric name strings available in a string table in GleanJSMetrics.cpp,
access is through metric_entry_t which has information not available to usecounters.py.
So for now we return char* literals from the use counter increment fns.
Differential Revision: https://phabricator.services.mozilla.com/D199933
This makes ticking the document timeline happens only when we make
forward progress. It seems otherwise we can end up with an extra no-op
tick which might resolve the ready time unexpectedly.
It's also cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D194406
