This attribute is not used in Gecko, but exists for use by other
applications. Specifically, the APP_TYPE_EDITOR type is given permission
to load privileged images as tested by browser_docshell_type_editor.js.
Before these changes, that test passed because the docshell was loaded
in a different process, so the cache was empty when each load occurred,
but after my changes the process ends up being re-used, so the image
cache bypasses this check.
This changes the image cache key to also include the app type
information so that it will be compared before re-using the entry.
Differential Revision: https://phabricator.services.mozilla.com/D126557
It is useful/necessary for WebCodecs image decoding support to be able
to calculate a frame count for the encoded image without actually
decoding every frame. It needs to be able to provide results without the
complete buffer as well.
Differential Revision: https://phabricator.services.mozilla.com/D212831
It is useful/necessary for WebCodecs image decoding support to be able
to calculate a frame count for the encoded image without actually
decoding every frame. It needs to be able to provide results without the
complete buffer as well.
Differential Revision: https://phabricator.services.mozilla.com/D212831
This attribute is not used in Gecko, but exists for use by other
applications. Specifically, the APP_TYPE_EDITOR type is given permission
to load privileged images as tested by browser_docshell_type_editor.js.
Before these changes, that test passed because the docshell was loaded
in a different process, so the cache was empty when each load occurred,
but after my changes the process ends up being re-used, so the image
cache bypasses this check.
This changes the image cache key to also include the app type
information so that it will be compared before re-using the entry.
Differential Revision: https://phabricator.services.mozilla.com/D126557
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
