In this particular case the issue wouldn't end up in any sort of memory
corruption if we didn't safely crash, but these are quite tricky to
reason about, so it's better to avoid the reentrancy altogether if
possible.
I tried to convert the fuzzer test-case in a crashtest but failed (as
in, it didn't crash without the patch under the test harness).
Differential Revision: https://phabricator.services.mozilla.com/D115943
This patch doesn't change behavior; it's just switching us between two
functions that do the same thing. (One is literally a trivial wrapper for the
other.)
We're using the new "InProcess" version of this API as a way of annotating
callsites that have been vetted as behaving properly in out-of-process iframes.
The code here, InvalidateImages, is walking up an invalidated image's
ancestor-chain, to invalidate any rendering observers of those ancestors. It's
OK that this walk will stop at the process boundary, because we don't support
rendering observers for cross-origin out-of-process content anyway.
Differential Revision: https://phabricator.services.mozilla.com/D108739
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
No behavior change, but the new place seems more appropriate.
StyleComputedUrl::ResolveImage is the only caller of ImageLoader::LoadImage,
and it calls it unconditionally modulo an special-case for documents.
Differential Revision: https://phabricator.services.mozilla.com/D103716
No behavior change, but the new place seems more appropriate.
StyleComputedUrl::ResolveImage is the only caller of ImageLoader::LoadImage,
and it calls it unconditionally modulo an special-case for documents.
Differential Revision: https://phabricator.services.mozilla.com/D103716
Without blocking onload (which preserves behavior before this patch
series) or requiring a decode for stuff like invisible bullets.
Differential Revision: https://phabricator.services.mozilla.com/D101072
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
