In bug 1883435 comment 2 chutten mentions that including
nsGlobalWindowInner.h from GleanMetrics.h causes a stylo build failure.
This is because nsGlobalWindowInner.h itself brings a bunch of DOM
bindings template soup that bindgen isn't great at dealing with.
That can be fixed in various ways. However, there is a simpler fix,
which is not including GleanMetrics at all.
It's trivial to do, and given it's a massive autogenerated file, and
Document.h is a very common header, it's worth doing this if only for
build times.
Fix a bunch of unused includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D203625
This patch adds fetchpriority support for the `<img>` element, also
exposing the corresponding attribute in the WebIDL. As in D197493, we
try and minimize the change and rely on a mapping configurable under a
preference to ease future experiments. We use initial mapping
PRIORITY_LOW/PRIORITY_HIGH/PRIORITY_LOW for fetchpriority=low/high/auto
and allow further adjustments in the image code.
Internal fetchpriority mapping is covered by the following tests:
- `image-initial-load.h2.html` (typos fixed here)
- `image-dynamic-load.h2.html`
DOM tests are covered by the following tests (pref enabled to make them
pass):
- `idlharness.https.html`
- `attr-img-fetchpriority.html`
Differential Revision: https://phabricator.services.mozilla.com/D202222
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
Previously, for `rel=preload as=fetch`, the internal priority,
`nsISupportsPriority`, was not adjusted. Now, the adjustment happens in
`FetchPreloader::CreateChannel`.
For `rel=preload as=font`, previously, the internal priority was always
set to high in `FontLoaderUtils::BuildChannelSetup`. Now, the internal
priority is a parameter, whose value potentially depends on the
`fetchpriority` attribute.
Note the minor correction of calling `SetPriority` instead of
`AdjustPriority` in `FontLoaderUtils::BuildChannelSetup`.
Differential Revision: https://phabricator.services.mozilla.com/D194205
Updated HTML parser to allow <hr> in <select>.
Updated internal toolkit UI for <select> dropdown to create
menuseperators for hrs.
Updated WPT expectations:
- HTML5Lib WebKit parsing for it now passes 100%
Also includes Android support, but Fenix does not support separators
in the menus used (single/multiple) yet so they are not rendered.
Differential Revision: https://phabricator.services.mozilla.com/D189065
Updated HTML parser to allow <hr> in <select>.
Updated internal toolkit UI for <select> dropdown to create
menuseperators for hrs.
Updated WPT expectations:
- HTML5Lib WebKit parsing for it now passes 100%
Also includes Android support, but Fenix does not support separators
in the menus used (single/multiple) yet so they are not rendered.
Differential Revision: https://phabricator.services.mozilla.com/D189065
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374