This probably made more sense when everything was in the same process,
so that prefs like the image cache size etc only measured web content.
But that's achieved via e10s nowadays, so probably having different
cache tables for chrome:// URIs is overkill. Plus, we probably want to
also clear resource:// URIs etc when flushing chrome caches and so on.
Differential Revision: https://phabricator.services.mozilla.com/D177765
We can't actually enable the warning because there are some warnings generated by includes coming from outside of imagelib.
Note that change in AOMDecoder::Init is actually a behaviour change: the new behaviour is to return the error code if we fail to decode the alpha image. This matches what we do for the dav1d decoder.
Depends on D173000
Differential Revision: https://phabricator.services.mozilla.com/D173001
This flag is not supported by most event targets and can have unexpected
side effects (namely spinning a nested event loop). All consumers have
been replaced with a new function which is more explicit about this side
effect.
Differential Revision: https://phabricator.services.mozilla.com/D173985
This means that for trivial images whose header specifies large dimensions but with no image data we don't use a lot of memory.
Differential Revision: https://phabricator.services.mozilla.com/D173119
And also make it return a better result when mDecoder already exists, Complete is not what we want to return.
Depends on D172994
Differential Revision: https://phabricator.services.mozilla.com/D172998
Because it has the same name as the base class function Decoder::Decode but different arguments, which is confusing.
Depends on D172998
Differential Revision: https://phabricator.services.mozilla.com/D173000
This prevents a crash that would occur if a redecode of an animated AVIF happened after changing the `sequences.enabled` pref from `true` to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D170190
This is semantically similar to the existing available() method, however will
not block, and doesn't need to do the work to actually determine the number of
available bytes.
As part of this patch, I also fixed one available() implementation which was
incorrectly throwing NS_BASE_STREAM_WOULD_BLOCK.
Differential Revision: https://phabricator.services.mozilla.com/D170697
I looked at the failures compared to the passing results. The passing results look very faint and blurry. The failures look much better actually.
Differential Revision: https://phabricator.services.mozilla.com/D171552
These crashtests rely upon either a requestAnimationFrame callback or a
MozAfterPaint event. Those currently won't happen when the compositor is
paused, and on Windows these crashtests are occluded, which will now pause
the compositor. To deal with this, we disable the occlusion tracking pref
on Windows. Other platforms seem not to treat the crashtests as occluded,
so their compositors keep running.
Differential Revision: https://phabricator.services.mozilla.com/D171137
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
The iterator used to read from an AVIF sample index will return `true` from
`HasNext()` even if the next sample is incomplete. We should error completely
out of the decode when this happens, so that we are always guaranteed to have a
sample to decode when there is no error in the parser.
Differential Revision: https://phabricator.services.mozilla.com/D168643
This fixes an assertion failure due to the assumption before Bug 1682662 that
all metadata decodes will completely decode a sample. That is no longer the case
because telemetry for image sizes can be sent without a full decode.
Differential Revision: https://phabricator.services.mozilla.com/D168645
This removes all implementations of these types. Some implementations in JS
code were also removed in the previous part, when updating tests to use
`Services.io.registerProtocolHandler`.
Code which used to access these members should go through the IOService now
instead.
Differential Revision: https://phabricator.services.mozilla.com/D162805
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
This removes all implementations of these types. Some implementations in JS
code were also removed in the previous part, when updating tests to use
`Services.io.registerProtocolHandler`.
Code which used to access these members should go through the IOService now
instead.
Differential Revision: https://phabricator.services.mozilla.com/D162805
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
This patch doesn't change behavior; these APIs were already effectively
infallible, in the sense that it was impossible for them to return anything
other than NS_OK.
The actual API changes here are in xpcom/io/nsIPipe.idl and
xpcom/io/nsPipe3.cpp, and the rest of this patch is just updates to callsites,
removing code that handled failure-flavored return values from these functions.
(All of this removed code was already dead code, effectively.)
Differential Revision: https://phabricator.services.mozilla.com/D161947
This will push through any unknown marker errors from libjpeg, but still
fail for other errors. Dropping markers prevents infinite loops in processing.
Differential Revision: https://phabricator.services.mozilla.com/D161187
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
To release the images, `ClearReleasingImages` basically takes all the `RefPtr<Image>` out of `mReleasingImagesOnMainThread` under a lock and then clears them, all on the main thread. This can be safely done before as late as XPCOMShutdownFinal on the main thread in order to avoid leaks.
Differential Revision: https://phabricator.services.mozilla.com/D160624
Bug 1780834 caused this bug. If we are not complete then we might need to
wait for more data to come in that has the ICCP chunk.
Differential Revision: https://phabricator.services.mozilla.com/D159137
This patch attempts to read color primary information from platform
agnostic decoders. It doesn't use any of this information to change how
the video frame is displayed.
It also cleans up some VPX transfer characteristics, to ensure they are
actually retrieved from the codec information, when available.
Differential Revision: https://phabricator.services.mozilla.com/D156362