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
WebRenderBridgeChild::GetFontKeyForScaledFont can currently cause a IpcResourceUpdateQueue race.
If we're in the middle of a transaction building a blob image, GetFontKeyForScaledFont is called
in the blob image building code using the transaction's IpcResourceUpdateQueue as expected, such
that resource updates are sent out when the transaction is finalized.
However, TextDrawTarget calls into PushGlyphs without passing along its IpcResourceUpdateQueue,
calling GetFontKeyForScaledFont without it, and causing it to immediately send out the resource
update.
So if a blob image uses a font key and submits a resource update, but a display list is built
after that also using the font key within the transaction, the display list will fail to send
the resource update because it thinks the blob image already did, even though the blob image
transaction has not yet been finalized.
The simple fix is to just pass IpcResourceUpdateQueue from TextDrawTarget into PushGlyphs, thus
ensuring the resource updates are properly ordered.
Differential Revision: https://phabricator.services.mozilla.com/D140438
Because these images are loaded as embeds/objects we can't get a hold of them to apply most usual methods of waiting for decode (img.decode, using a special powers image notifications observer). This should hopefully be enough to avoid hitting this in automation.
Backout the patch for bug 1722422 (the one that changed it from an assert to a leak) because I think it's easier to classify/recognize the assert than the leak in the logs.
Differential Revision: https://phabricator.services.mozilla.com/D139464
Destroying an already_AddRefed if it holds a non-null pointers asserts because it leaks. But we want the leak here, so leak in a way that doesn't assert.
Differential Revision: https://phabricator.services.mozilla.com/D139266
Destroying an already_AddRefed if it holds a non-null pointers asserts because it leaks. But we want the leak here, so leak in a way that doesn't assert.
Differential Revision: https://phabricator.services.mozilla.com/D139266
I've also tested the behavior in Chrome and I think this is
the correct way of doing it. Chrome also only notifies the
cached entry once, it won't notify it even if I manually
trigger it after pageload.
Differential Revision: https://phabricator.services.mozilla.com/D138346
We're checking animation consumers, not locked status. We don't care
about animation consumer count of non-animated images.
Depends on D137765
Differential Revision: https://phabricator.services.mozilla.com/D137766
If a vector image does not have an intrinsic size as returned by
VectorImage::GetWidth and VectorImage::GetHeight, currently factor-of-2
scaling is disabled. With this patch, we just assume a default size of
100x100, adjusted by the intrinsic ratio if available, to get the
baseline size for determing appropriate factor-of-2 sizes.
Differential Revision: https://phabricator.services.mozilla.com/D133395
If we are shutting down, the document for a VectorImage may be cleared.
If a refresh tick raced with the shutdown, we might try to deref the
null document.
Differential Revision: https://phabricator.services.mozilla.com/D132953
Previously with ImageContainers, we would put the new preferred surface
into the ImageContainer. When we check if we should invalidate, it would
have a different image key, and hence invalidate the image frame and
schedule a paint.
With ImageProviders, it returns the same key in this case, because the
ImageProvider represents a particular surface. As such, we need to
actually track when we get a substituted ImageProvider, and invalidate
the image frame more aggressively to ensure we get the preferred size.
Differential Revision: https://phabricator.services.mozilla.com/D132583
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Instead treat these protocols as "never-expiring" protocols, and clean
up revalidation code while at it.
Depends on D132347
Differential Revision: https://phabricator.services.mozilla.com/D132348
