The old code operates in the CSS pixel coordinate, so we should use the type
system to express that. With this patch, nsImageControlFrame, nsImageFrame, and
nsImageMap now have no usage of nsIntPoint.
Differential Revision: https://phabricator.services.mozilla.com/D136647
Part of how invalidation works with WebRender is that we assume frames
with a WebRenderUserData object attached to them are in view. This means
for images that we must ensure we create an empty
WebRenderImageProviderData object even when we have no provider or
surface for display. This will allow us to invalidate properly when we
get the FRAME_COMPLETE notification from imagelib indicating that the
redecode has completed.
Differential Revision: https://phabricator.services.mozilla.com/D135077
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
Given the compat reports in bug 1484928, I don't think it's worth
keeping the current behavior.
Our behavior should match other browsers now. Rather than making
content: url() work everywhere even for otherwise-replaced elements,
just special-case this since that's what other browsers seem to do.
Differential Revision: https://phabricator.services.mozilla.com/D131797
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
I'm not aware of any reason we shouldn't do this, as it is interoperable
with other browsers, and it causes compat issues from sites that forget
to use the prefixed version.
Note this removes some #[parse(aliases)]. These only affect devtools
autocomplete behavior, and we avoid autocompleting -moz-prefixed
keywords when possible, so even though it's a slight behavior change,
it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D126718
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125738
Support fit-content for preferred size, min size, and max size. This
patch only implement the style system. For layout part, we will do that
in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D107161
This patch has no functional change beyond changing prototypes and
adding storage for ImageIntRegion for each ImageContainer.
Differential Revision: https://phabricator.services.mozilla.com/D114984
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
https://drafts.csswg.org/css-images-4/#image-set-notation has:
> [...] it also specifies the image’s natural resolution, overriding any other
> source of data that might supply a natural resolution.
Astounding that there was literally no WPT for this at all. I added three: one
for backgrounds, one for list-style-image, and one for `content`. Cursor is not
handled on this patch because that one requires a fair amount of extra work.
Differential Revision: https://phabricator.services.mozilla.com/D112474
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
