With the patches of bug 1815229, these errors appear:
browser/base/content/test/performance/browser_startup_images.js | Loaded image resource://gre-resources/loading-image.png should have been shown
It's a real issue, where we eagerly load the broken image icon and so on
even though we don't use them.
This fixes it by lazily-loading the icon once, only when needed.
Differential Revision: https://phabricator.services.mozilla.com/D170159
nsImageFrame has support for displaying style URIs / an owned image
request, so use it.
The main behavior difference is that we don't fire `load` / `error`
events for those images anymore, but I don't see any event listener for
those around, so I think they can go.
Differential Revision: https://phabricator.services.mozilla.com/D168958
* Use static prefs.
* Move IconLoad to the cpp file since it's only used in one translation
unit.
This is in preparation to make the image loads lazy.
Differential Revision: https://phabricator.services.mozilla.com/D170157
We're about to use it a bit more.
Switch to CancelAndForgetObserver, since we will call it in the future from
other places that aren't frame destruction. This doesn't change behavior of the
existing caller because we call mListener->SetFrame(nullptr), which effectively
no-ops the listener
Differential Revision: https://phabricator.services.mozilla.com/D169985
It's not for content: url() only anymore (we also use it for
list-style-image, and soon for XUL images too). The difference is that
the frame owns that request (vs. the image content).
Depends on D169981
Differential Revision: https://phabricator.services.mozilla.com/D169982
The fix is the one line in
nsImageLoadingContent::MaybeForceSyncDecoding, but I added new asserts
that should prevent this from regressing in the future.
Differential Revision: https://phabricator.services.mozilla.com/D154815
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
This doesn't change behavior just yet, but seems worth doing separately.
With this patch, we can render content overlaid on top of an image
frame, by attaching a shadow root to it. The idea is to use this for
text recognition (OCR) of text inside images.
I chose to implement this using the DynamicLeaf stuff that I removed in
bug 1746310 (because nsMenuPopupFrame was its only user).
That seems simpler than either a new frame class, or more special cases
in the frame constructor, etc. But let me know if you disagree.
There are further changes that we want to do. For example, trying to
select the overlaid text with the mouse right now will start dragging
the image. For that, we might need to tweak our selection / mouse
dragging code. But those seem all changes that can go on top of this.
Differential Revision: https://phabricator.services.mozilla.com/D140638
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
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
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 patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
Precomputing the skipBEnd bit is odd / wrong. Using the PreReflow
version causes no regression, and allows us to simplify the code.
It also reverts the test annotations added to bug 1675376 which were
caused by the extra argument to GetLogicalSkipSides() somehow.
Differential Revision: https://phabricator.services.mozilla.com/D97418
Precomputing the skipBEnd bit is odd / wrong. Using the PreReflow
version causes no regression, and allows us to simplify the code.
It also reverts the test annotations added to bug 1675376 which were
caused by the extra argument to GetLogicalSkipSides() somehow.
Differential Revision: https://phabricator.services.mozilla.com/D97418
This patch moves the preferred aspect-ratio calculation from each
replaced elements' GetIntrinicRatio() into GetAspectRatio(), because
they share the same logic.
For nsImageFrame, the cached mIntrinsicRatio now stores only the image's
intrinsic ratio, not considering the aspect-ratio property.
This patch fixed "object-fit:contain" for canvas, image because
GetIntrinicRatio() no longer considers aspect-ratio. This also fixed
replaced elements' size when both "aspect-ratio:<ratio>" and
"contain:size" is specified.
This also makes us pass some of the aspect-ratio tests because we change
GetIntrinicRatio() into GetAspectRatio() in
nsLayoutUtils::IntrinsicForAxis() in Part5, which is used by nsBlockFrame
(via nsLayoutUtils::IntrinsicForContainer) to implement GetMinISize().
Differential Revision: https://phabricator.services.mozilla.com/D91229
