Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
This fixes rendering of background-image when CSS zoom is in effect.
Note that we want to scale the resolution by the _inverse_ of the
zoom, since having a higher image resolution means that the CSS
size gets shrunk and viceversa.
Differential Revision: https://phabricator.services.mozilla.com/D192130
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
In bug 1844755, a bunch of the time is spent allocating initial values.
There used to be more document-dependent initial values before
bug 1834487, but now that's only about default-font and direction.
This improves the situation by sharing initial structs that don't depend
on the document.
Differential Revision: https://phabricator.services.mozilla.com/D184256
This shouldn't change behavior but reduces the amount of code paths
where we update the internal image state.
Depends on D170594
Differential Revision: https://phabricator.services.mozilla.com/D170595
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
I don't think there's ever a way these should differ.
Got some include hell from removing ReferrerInfo.h from Document.h but
hopefully should be straight-forward to review.
Depends on D173154
Differential Revision: https://phabricator.services.mozilla.com/D173155
This preserves the previous behavior more exactly and fixes the display
of the icons, which have src="" but expect list-style-image to take
effect.
Depends on D173265
Differential Revision: https://phabricator.services.mozilla.com/D173266
This will mean we always pass FLAG_SYNC_DECODE_IF_FAST (unless we are already passing the sync decode flag). The fact that we weren't doing this already is an oversight, we want to do this for all images we paint on the normal painting path. However what makes this more important is that we folded nsImageBoxFrame into nsImageFrame recently (bug 1815229), and nsImageBoxFrame eagerly decodes all its images and keeps them decoded, and also uses FLAG_SYNC_DECODE_IF_FAST (because with multiple sized decodes eager decodes don't cover everything). So this should help us avoid regressing visually with xul images.
Differential Revision: https://phabricator.services.mozilla.com/D171828
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
This pref has been false since forever, completely untested, and I see
no references to it anywhere. I'm pretty sure having a loading image
placeholder wouldn't be web compatible, particularly in the current days
with all the lazy-loading shenanigans etc.
I propose just removing this code, and simplifying surrounding code for
clarity.
Differential Revision: https://phabricator.services.mozilla.com/D170158
* 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
We're about to add a new Kind, so this makes it a bit easier to follow
once that's done, IMO. Also prevents people from forgetting to update
that method in the future.
Depends on D169982
Differential Revision: https://phabricator.services.mozilla.com/D169983
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
Since we are initializing nsImageMap lazily, it's possible for area elements
stays non-focusable when autofocus code tries to focus it. So to fix
this, we need to ensure nsImageMap is initialized early enough.
Differential Revision: https://phabricator.services.mozilla.com/D168166
Since we are initializing nsImageMap lazily, it's possible for area elements
stays non-focusable when autofocus code tries to focus it. So to fix
this, we need to ensure nsImageMap is initialized early enough.
Differential Revision: https://phabricator.services.mozilla.com/D168166
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
Ting-Yu Lin
Emilio Cobos Álvarez
Sean Feng
Sandor Molnar
Timothy Nikkel
Narcis Beleuzu
Tiaan Louw
Cristian Tuns
Iulian Moraru
Cristina Horotan
Jonathan Kew
Robert Longson
Noemi Erli
Manuel Bucher
Martin Robinson
Csoregi Natalia
Razvan Cojocaru