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
The event is emitted when a property is registered via `CSS.registerProperty`.
This will be used by DevTools so we can update the Rules view when a property
is registered.
Differential Revision: https://phabricator.services.mozilla.com/D196204
It seems the discussion in the bug goes in this direction, and I think
it's the right call as described there.
Depends on D198630
Differential Revision: https://phabricator.services.mozilla.com/D198669
Just like we ignore chrome pages. This should be uncontroversial, even
though it might be the case that we don't want any of these to show up.
Not sure how to best test this...
Differential Revision: https://phabricator.services.mozilla.com/D198630
`beforeinput` event shouldn't be fired if it's caused by JS. However, we
dispatch it when the call is by chrome script or an addon because there is
no user input emulation API for WebExtension and builtin editors make the
change undoable only when JS changes the editor value with
`Document.execCommand`. Therefore, addons may want to use
`Document.execCommand` for making the change undoable.
On the other hand, nested calls of `Document.execCommand` makes the error
handlings in editor classes too complicated. Therefore, we don't allow that.
However, this causes that if web apps intercept `beforeinput` events and
prevents the default and calls `document.execCommand`, the first call of
web apps may be first nested call if the `beforeinput` event is caused by
a call of `Document.execCommand` in addon.
Therefore, this patch makes `Document` stores whether `ExecCommand` is called
by content or chrome/addon. And if the call is improperly nested, keep stopping
handling the command, but allows if and only if the first call is by
chrome/addon.
Differential Revision: https://phabricator.services.mozilla.com/D198357
In order to use the modifiers in nsGlobalWindowOuter::OpenInternal, add accessor
methods to BrowsingContext, Document, and WindowContext.
Those accessors behave in the same way as ConsumeTransientUserGestureActivation
and RevisePopupAbuseLevel, except for checking the PopupBlocker state.
Differential Revision: https://phabricator.services.mozilla.com/D197862
