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 ([email protected])
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 ([email protected])
Differential Revision: https://phabricator.services.mozilla.com/D197493
This code seems to have been broken quite some time ago, but without adverse effect.
I have filed bug 1691868 so that a proper fix can be found.
In the meantime, this preserves the current behavior and is less confusing.
Differential Revision: https://phabricator.services.mozilla.com/D104634
On Windows we were passing an empty rect to signal "entire image", and on macOS we can move the logic into MOZIconHelper.
Differential Revision: https://phabricator.services.mozilla.com/D104633
It no longer needs to be cycle-collected because it doesn't have any strong
references to other cycle-collected objects anymore.
Differential Revision: https://phabricator.services.mozilla.com/D104622
In this patch, I've tried to abstract out all of the platform-specific parts
of what was the nsIconLoaderService into something generic enough to be used
across multiple platforms. I also renamed it and namespaced it to
mozilla::widget::IconLoader.
Depends on D89788
Differential Revision: https://phabricator.services.mozilla.com/D89972
In this patch, I've tried to abstract out all of the platform-specific parts
of what was the nsIconLoaderService into something generic enough to be used
across multiple platforms. I also renamed it and namespaced it to
mozilla::widget::IconLoader.
Depends on D89788
Differential Revision: https://phabricator.services.mozilla.com/D89972
In this patch, I've tried to abstract out all of the platform-specific parts
of what was the nsIconLoaderService into something generic enough to be used
across multiple platforms. I also renamed it and namespaced it to
mozilla::widget::IconLoader.
Depends on D89788
Differential Revision: https://phabricator.services.mozilla.com/D89972
Frédéric Wang