This is mostly just changing `new Foo()` to `MakeRefPtr<Foo>()`.
Notablye exceptions:
* In one case where the result gets stuck in a `nsCOMPtr` instead of a `RefPtr`,
I use `MakeAndAddRef` instead, to follow precedent from elsewhere in the
codebase (and avoid the appearance of a pointer-type-mixup).
* In cases where the class has a private constructor, we can't use MakeRefPtr,
so I use `do_AddRef(new Foo())` to make it slightly clearer (in an easily
greppable way) that the 'new' invocation is instantly being stuffed into
a smart pointer.
Differential Revision: https://phabricator.services.mozilla.com/D298475
Just put the map and the state in the Document, we don't need a separate
thread-safe-refcounted object.
This makes it easier to propagate changes to it to the refresh driver
without awkward back-pointers or what not.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D255692
The background image is associate to the table frame, but the table wrapper frame is the primary frame, thus IsPrimaryFrameOfRootOrBodyElement returns false and we don't propagate to the root when we should. So I changed IsPrimaryFrameOfRootOrBodyElement to handle this case and renamed it. I checked the other root element frame types, only table frames had this issue.
Differential Revision: https://phabricator.services.mozilla.com/D217923
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
This patch doesn't change any user-observable behavior.
StaticAutoPtr lets us remove a handful of explicit 'delete' statements, by
making deletion happen automatically when these variables are cleared.
Differential Revision: https://phabricator.services.mozilla.com/D127336
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
Daniel Holbert