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
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
I'm considering dropping this if statement entirely because this is only hit when we disable network state partitioning.
According to code coverage, we only see the ""_ns as the result of this ternary in our testing too.
But, if you disable network state partitioning and then block cookies from a given domain, then we would still want to partition network state I suppose, so I'll leave it like this..
Differential Revision: https://phabricator.services.mozilla.com/D198034
This patch makes CanvasDrawEventRecorder track what eventCount we
recorded an external surface reference. When the reader has increment
its processedCount above that, we will release our reference as it
should have acquired a strong reference to the data. This was previously
done when we forwarded the texture, but with remote textures, we no
longer have this event. Now we check when we start a new recording, or
attempt to clear cached resources.
Differential Revision: https://phabricator.services.mozilla.com/D197216
