We use it to merge blobs, but that doesn't match the spec. Per:
https://html.spec.whatwg.org/#the-list-of-available-images
We should key off the URI, and thus a revoked image should be able to be
reused if the request is cached. This works to allow printing revoked
blob images, which other browsers allow.
I don't see any way to make that work easily while preserving the blob
image optimization. That being said, it seems other browsers also
re-decode when creating different URLs for the same blob (see the
test-case attached to the bug), so it seems we should be able to live
without it.
Differential Revision: https://phabricator.services.mozilla.com/D90544
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
If you do a diff, all of the different shared surfaces get merged together,
because the diffing process removes all PIDs from the paths. This means
you end up hitting an assertion when the diffing process tries to combine
entries with the same path but different kinds.
Differential Revision: https://phabricator.services.mozilla.com/D83585
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
Current gecko dispatches tasks of releasing image::Image to main thread at some places. The task was dispatched individually. Then there were cases that the releasing took long time. It increased peak memory usage and caused a problem like Bug 1639280. When main thread is very busy like WebGL, it takes longer time until the Image is released on main thread. If Images are released quickly on main thread, we could reduce peak memory usage.
When SurfaceCache::ReleaseImageOnMainThread() is called, there could be already an ongoing task for releasing Image. It could reduce a duration until release on main thread.
Differential Revision: https://phabricator.services.mozilla.com/D82864
If the scrollable div ends up as the first-encountered scrollframe, it gets a
big displayport that is just over 5000px CSS pixels tall (on GeckoView). When we
check for images being "nearly visible" we expand that displayport further by a
pref-controlled multiplier, which ends up doubling the displayport height to
over 10000 CSS pixels. So for the image to actually get detected as outside the
"nearly visible rect" it needs to be positioned further down in the iframe.
This test was previously passing on GeckoView because the scrollable div was
not getting detected as the first-encountered scrollframe; the root scrollframe
for the top-level document was the one getting the displayport even though it
didn't really need it. A later patch in this bug changes the first-encountered
scrollframe, causing this test to fail without this patch.
Differential Revision: https://phabricator.services.mozilla.com/D82777