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
It's not clear to me this ever worked before either, I don't think the logic
before my patch was sound before.
But oh well. This should work, gotta add a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D62777
--HG--
extra : moz-landing-system : lando
And add an assertion to ensure callers get it right. The only thing that needs
it AFAICT is the canvas frame background, so remove the border-image caller...
Differential Revision: https://phabricator.services.mozilla.com/D61950
--HG--
extra : moz-landing-system : lando
This removes nsStyleImageRequest by moving the load state to LoadData instead
(where other lazy state like the resolved URL and load id lives).
That way we can use cbindgen for more stuff (there's no blocker for using it for
all images now), and we can undo the image tracking shenanigans that I had to do
in bug 1605803 in nsImageFrame.
This removes the mDocGroup member because well, there's no real upside of that
now that quantum DOM is not a thing.
It also removes the static clones of the image requests, and the need for each
computed value instance to have its own request. These were needed because we
needed the image loader for the particular document to observe the image
changes. But we were also tracking the request -> loader for other purposes.
Instead, Now all the images get loaded with GlobalImageObserver as a listener,
which looks in the image map and forwards the notification to all the interested
loaders instead dynamically.
The style value is only responsible to load the image, and no longer tracks /
locks it. Instead, the loader does so, via the image tracker.
Differential Revision: https://phabricator.services.mozilla.com/D58519
--HG--
extra : moz-landing-system : lando
This removes nsStyleImageRequest by moving the load state to LoadData instead
(where other lazy state like the resolved URL and load id lives).
That way we can use cbindgen for more stuff (there's no blocker for using it for
all images now), and we can undo the image tracking shenanigans that I had to do
in bug 1605803 in nsImageFrame.
This removes the mDocGroup member because well, there's no real upside of that
now that quantum DOM is not a thing.
It also removes the static clones of the image requests, and the need for each
computed value instance to have its own request. These were needed because we
needed the image loader for the particular document to observe the image
changes. But we were also tracking the request -> loader for other purposes.
Instead, Now all the images get loaded with GlobalImageObserver as a listener,
which looks in the image map and forwards the notification to all the interested
loaders instead dynamically.
The style value is only responsible to load the image, and no longer tracks /
locks it. Instead, the loader does so, via the image tracker.
Differential Revision: https://phabricator.services.mozilla.com/D58519
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
This patch:
- Gives layout/generic/AnonymousContentKey.h an include for `<stdint.h>` to
provide the uint8_t type, and TypedEnumBits.h to provide the
MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS macro. (This is a change in another
directory, but it's needed in order for layout/style/ServoStyleSet.cpp to
build successfully.)
- Adds a missing "nsINode" forward-decl to dom/base/IdentifierMapEntry.h,
because it uses that type in function declarations. (This change is needed
in order for layout/style/CachedInheritingStyles.cpp to build successfully.)
- Gives CSSStyleRule.cpp an include for PseudoStyleType.h,
nsCSSPseudoElements.h, and CSSEnabledState.h because it uses those types.
- Gives GeckoBindings.cpp an include for gfxTextRun.h, to provide the definition
of type gfxFontGroup (so GeckoBindings can call GetFirstValidFont() on an
object of that type).
- Gives Loader.h an include for nsIContentInlines.h, to provide the inline
function IsInUAWidget().
- Gives Rule.cpp an include for HoldDropJSObjects.h, to provide DropJSObjects().
- Gives nsImageLoader.cpp an include for DocumentInlines.h (and Document.h for
good measure), to provide the inline function GetPresContext().
- Gives nsStyleStruct.cpp an include for DocumentInlines.h, to provide inline
function Document::GetPresContext().
- Gives nsStyleTransformMatrix.h an include for Units.h (instead of gfxPoint.h,
which isn't useful) to provide the CSSPoint type.
- Gives nsStyleTransformMatrix.h an include for ServoStyleConsts.h, to provide
LengthPercentage and the various StyleRotate/StyleScale/StyleTransform/etc
types. (These can't be easily forward-declared, because some of them are
legitimate types whereas others are type aliases. We could theoretically
forward-declare all of the underlying types and then repeat the type aliases,
but that'd be verbose and unmaintainable.)
Depends on D50165
Differential Revision: https://phabricator.services.mozilla.com/D50166
--HG--
extra : moz-landing-system : lando
So the issue here is that this test-case has a zero-sized border, but still with
a border-image (which we should paint).
So the first time we get here, the image is not loaded, and thus we don't get
here:
https://searchfox.org/mozilla-central/rev/e0b0c38ee83f99d3cf868bad525ace4a395039f1/layout/painting/nsDisplayList.h#4254
Which means that we end up with zero bounds and thus we don't even get to the
border painting code.
However, when the image loads, we get to MarkNeedsDisplayItemRebuild(), but that
doesn't schedule any paint, only marks the frames as modified in order for
display items to be rebuilt _eventually_.
Thus eventually, where we force a repaint by other means, we paint correctly.
This only works in more general cases because we get to the nsImageRenderer code
which does vastly different stuff.
InvalidateFrame() seems to do the right thing and schedule a paint, so use it.
It's not clear to me which one of nsIFrame::InvalidateFrame() or
nsIFrame::SchedulePaint() we should use...
If I understand correctly, InvalidateFrame() will only do something iff there
are display items for the frame, so that should make the IsVisible() check
redundant.
Note however that I think there's still a race condition, if we get to paint in
between the SIZE_AVAILABLE notification (the one where we actually invalidate
the display items), and the LOAD notification (the one the border-image code
checks).
I'll send a separate patch for that, I think SIZE_AVAILABLE should be a
strong-enough hint and that allows us to remove nsStyleImage::IsLoaded()...
The RequestReflow stuff also looks highly suspicious... shape-outside
sync-decodes, and it seems we could end up invalidating reflow from the reflow
code...
Differential Revision: https://phabricator.services.mozilla.com/D41005
--HG--
extra : moz-landing-system : lando
CORS only works on http channels, so anything else that tries to do a
CORS-enabled request fails catastrophically.
resource:// images are useful for extension developers, so don't perform CORS
checks on them. We may want to also do file:// and fix bug 1565509, while at it,
if we consider it's causing developer pain.
Differential Revision: https://phabricator.services.mozilla.com/D40651
--HG--
extra : moz-landing-system : lando
That way we don't need to re-request a reflow. This code can run from reflow
itself, so requesting a reflow from here can break invariants.
There's the question of whether this code should be running at all for
continuations, but this patch fixes a bug regardless of whether we do that or
not.
Differential Revision: https://phabricator.services.mozilla.com/D41021
--HG--
extra : moz-landing-system : lando
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
I wrote this patch by first removing UNIFIED_ from layout/style/moz.build, and
then rebuilding, and then addressing build errors one by one.
Nearly all of the build errors were for using the "Document" type without a
proper namespace, and I've addressed this by sprinkling "using namespace"
declarations in the affected .cpp files (and removing a few now-unnecessary
dom:: prefixes on types in those files).
The only other errors were for WorkletGlobalScope.h which needed an #include to
provide the type "DOMHighResTimeStamp", and nsHTMLStyleSheet.h which needed a
forward-declaration for the type "mozilla::dom::Document".
Differential Revision: https://phabricator.services.mozilla.com/D22767
--HG--
extra : moz-landing-system : lando
When the underlying image request (imgIRequest) changes for an image, we
need to ensure that we invalidate the cached WebRenderImageData such that
the image container stored therein is updated to be for the correct
image. This gets a little tricky because some display items store both
the current and previous images, and choose to display the latter if the
former is not yet ready. We also don't know what image the image
container belongs to. As such, we now compare the producer ID of the
current frame in the image container, to the expected producer ID of the
current image request. If they don't match, we must regenerate the
display list.
Differential Revision: https://phabricator.services.mozilla.com/D19699
We already avoid scene rebuilding for animated image frame updates, but
we can easily apply this to still images. If the decoding is happening
slowly and in chunks for some reason (really large image, slow network),
then we may save some work.
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The function doesn't do painting synchronously but schedule painting if
certain conditions are met. Hence the rename.
Differential Revision: https://phabricator.services.mozilla.com/D15021
--HG--
extra : moz-landing-system : lando
This patch allows us to intercept invalidation requests for display
items, and avoid regenerating the display list for animated images which
are using SharedSurfacesAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D7504
Has a single caller, from which we pass the arguments. We can just avoid that.
Differential Revision: https://phabricator.services.mozilla.com/D8276
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Sylvestre Ledru
Emilio Cobos Álvarez
Narcis Beleuzu
longsonr
Simon Giesecke
Boris Zbarsky
Mihai Alexandru Michis
Andrew McCreight
Ciure Andrei
Eric Rahm
Chris Peterson
Cameron McCormack
Daniel Holbert
Edgar Chen
Thomas Nguyen
Brindusan Cristian
Masayuki Nakano
Ryan Hunt
Andrew Osmond
Ting-Yu Lin
Timothy Nikkel
Brian Hackett