If the channel is not a nsIPrivateBrowsingChannel, and it also has no load context (eg inside svg images) then we will over write a non-zero mPrivateBrowsingId on the OriginAttributes of the channel with 0, making NS_UsePrivateBrowsing return false for the channel.
Differential Revision: https://phabricator.services.mozilla.com/D212083
This patch refactors how we check for text formats when deciding how to handle
resources, such that more text MIME types will be rendered in-browser, rather
than downloaded.
This change requires us to move more away from using the Gecko-Content-Viewers
category in the category manager for this decision, as we need to handle an
unlimited number of MIME types behind the scenes.
Support for Gecko-Content-Viewers was left in for both the in-tree use for
application/http-index-format and dynamically determining whether image/avif
and image/jxl are supported, as well as for the message/rfc822 type used by
Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D212078
This patch refactors how we check for text formats when deciding how to handle
resources, such that more text MIME types will be rendered in-browser, rather
than downloaded.
This change requires us to move more away from using the Gecko-Content-Viewers
category in the category manager for this decision, as we need to handle an
unlimited number of MIME types behind the scenes.
Support for Gecko-Content-Viewers was left in for both the in-tree use for
application/http-index-format and dynamically determining whether image/avif
and image/jxl are supported, as well as for the message/rfc822 type used by
Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D212078
The page has
<link rel="shortcut icon" type="image/x-icon" href="data:image/icon;base64,__png_data__">
When the Favicon service tries to decode that is passes "image/icon" as the mimetype to choose the decoder type and so we try to decode it as our internal icon format (not a format used in the wild, only used internal to get pass around icon data we retrieved from the OS). This passes in an invalid format type and hits the assert. In a non-debug build we fail to create the surface pipe later when we can't find a swizzle function. We only ever create these icon files with formats R8G8B8A8, OS_RGBA, or B8G8R8A8. The favicon still gets displayed so the favicon service must be trying something more complicated if that fails.
In the normal content image loading path we prefer to sniff the content type from the image data and if that fails fall back to the specified content type. So the test had be careful not to look like png (or any other) image format so that we actually tried to decode it as an icon.
Differential Revision: https://phabricator.services.mozilla.com/D204732
A number of public APIs in Skia have changed since the update to m125,
so various places in Gecko need to be updated to track it.
Differential Revision: https://phabricator.services.mozilla.com/D209821
A number of public APIs in Skia have changed since the update to m125,
so various places in Gecko need to be updated to track it.
Differential Revision: https://phabricator.services.mozilla.com/D209821
When not using blob recordings for vector images we use simple surface providers. When we get an invalidation we will call SurfaceCache::InvalidateImage which will set a dirty bit on all blob recordings and remove all other surfaces from the surface cache. And if it finds a blob recording we will call ResumeHonoringInvalidations. This is not enough to invalidate in the case of a non-animated vector image using the webrender GetImageProvider path. Even though the surface isn't in the surface cache anymore it is still cached on the frame and when we tell it about the invalidation it will just has the image provider to update its key. That will call this code
https://searchfox.org/mozilla-central/rev/cdddec7fd690700efa4d6b48532cf70155e0386b/image/DecodedSurfaceProvider.cpp#222
which will just share the same surface as before the invalidation happened again. That will let us handle one invalidation but it still won't fix the bug, we need to call ResumeHonoringInvalidations so that we handle further invalidations.
When not using the image provider path, we don't save an image provider on the frame, that alone would avoid this problem. But we also call ResumeHonoringInvalidations for every successful call of VectorImage::Draw.
* * *
imported patch asvfref
Differential Revision: https://phabricator.services.mozilla.com/D174450
Most of these were probably disabled because of the window occlusion thing making them timeout. We fixed that in this bug so we don't need them anymore. Whatever the reason these all pass now and don't seem to be intermittent failures either.
There is still one test that we must skip on wayland for failure though, dom/media/tests/crashtests/1490700.html, but I think it's related to some webrtc feature that is not implemented on wayland perhaps.
Differential Revision: https://phabricator.services.mozilla.com/D208078
And MOZ_ASSERT_UNREACHABLE with MOZ_CRASH.
MOZ_ASSERT and MOZ_ASSERT_UNREACHABLE are only checked in debug builds, so release builds' tests are not checking these assertions.
Differential Revision: https://phabricator.services.mozilla.com/D207372
Previously the `boolean` type was also declared using a `bool` typedef in
xpidl, meaning that both were used in various places. This patch standardizes
on the built-in `boolean` type, removing the typedef.
Differential Revision: https://phabricator.services.mozilla.com/D206382
SVGs must be coded on MainThread because they need to access the LoadGroup,
etc, while other images can be decoded via the decode pool. This ensures
that CheckListenerChain() will return the right value for this instance.
Differential Revision: https://phabricator.services.mozilla.com/D203181
SVGs must be coded on MainThread because they need to access the LoadGroup,
etc, while other images can be decoded via the decode pool. This ensures
that CheckListenerChain() will return the right value for this instance.
Differential Revision: https://phabricator.services.mozilla.com/D203181
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
This code was added before we decided to do fission, when we wanted to separate out different sites that were in the same process so we could prioritize them better. We are not going down that path so we can simplify this code. There should be no change in functionality with this patch, just simpler code.
Differential Revision: https://phabricator.services.mozilla.com/D201705
GVST is how these probes sent data in Fenix and is now unnecessary (and doesn't send data in Fenix release) since Firefox Desktop has direct access to Glean. We therefore need to clean them up in some capacity.
Following the recommendations from the GeckoView Streaming (GVST) validation effort, this is a pure Glean api implementation of the metrics that fell under network in geckoview streaming.
Because these were all categorical histograms, to retain previous functionality we've added parallel instrumentation in Glean.
Differential Revision: https://phabricator.services.mozilla.com/D201024
This pref exists only for fuzzers so they don't waste time on overly large images. The way fuzzers set the pref requires it to be live.
Differential Revision: https://phabricator.services.mozilla.com/D198498
