MakeAndAddRef ensures that the freshly-allocated object immediately gets a
refcount of 1 (before it's even passed to AddScriptRunner). This avoids
several potential footguns that otherwise exist with a zero-refcount
freshly-allocated object.
It also makes the ownership-transfer semantics more clear
(via the already_AddRefed type that it produces) - AddScriptRunner is taking
ownership of the object, rather than using it temporarily while the caller
maintains ownership.
Differential Revision: https://phabricator.services.mozilla.com/D299039
Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
Prefer aspect-ratio to the tentative BSize if we have both tentative
ISize and BSize.
Also make auto aspect-ratio handling a bit more explicit.
To prevent some regressions, we need to:
* Fix size-containment aspect ratio for <embed> (nsSubDocumentFrame).
* Fix RasterImage::GetIntrinsicRatio with uneven ratios.
* Avoid SVG root from using the aspect ratio from the viewbox, see
bug 2035918.
Differential Revision: https://phabricator.services.mozilla.com/D296982
When we're replicating a fixed-positioned frame that happens to contain a
subdocument, we were losing track of the primary frame of the element.
The regressing bug made us rely a bit more in the frame tree structure
here (of FindContainerFrame() and such), but this was a pre-existing bug.
This prevents us from clobbering it and is enough to fix the crash and restore
pre-regression behavior, so it is the minimal thing to uplift.
Further clean-ups incoming.
Differential Revision: https://phabricator.services.mozilla.com/D279297
This allows to clean up even more view code, since views now are just a
link between layout and widget at the root and little else (so the whole
view children and so on can go), but that will be done in separate
patches since these patches are not risk-free.
Notable changes:
* PresShell::WillPaint() now recurses into subdocuments. That was done
previously via CallWillPaintOnObservers().
* Embedder frame is tracked directly by nsSubDocumentFrame an
PresShell. It might be possible to simplify this further,
if bug 1997773 sticks.
Differential Revision: https://phabricator.services.mozilla.com/D232057
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
`MutationEvent_Bindings::MODIFICATION`,
`MutationEvent_Bindings::ADDITION` and `MutationEvent_Bindings::REMOVAL`
will be removed. Therefore, we need alternative `enum class` for that.
This patch makes `nsIFrame` and subclasses use the new one.
Differential Revision: https://phabricator.services.mozilla.com/D263053
The asr of some display items depends on the items that it contains. When we do a partial display list update and we merge display list we can change what an item contains so we might have to update the asr of the item. UpdateASR performs this work. Unfortunately it doesn't quite do it correctly.
Items whose asr depends on the items that it contains will pick the asr that is an ancestor (or equal to) of the asr of every item that it contains. Additionally we want the asr to be an ancestor (or equal to) the initial asr for the item.
aContainerASR in UpdateASR contains the asr that is an ancestor of every contained item. So UpdateASR assumes that if the item is not a wrap list item that it wants the container asr as its asr. This is not correct. Additionally it assumes that if the item is a wrap list item (or subclass) that it wants the ancestor behaviour for it's asr. This is also not correct. What each display item wants for its asr is more complicated then that.
The pernosco session https://bugzilla.mozilla.org/show_bug.cgi?id=1764863#c1 gives an example of this going wrong. In that case the item is a transform item and it only contains items whose asr is a descendant of the asr of the transform item. The transform item is not a wrap list, so we set the asr of the transform item to a descendant of the asr that it should be.
To fix this we add a function to all display items that opts them in to this ancestor behaviour for asrs if they want it. Some display item types only want the ancestor behaviour in some cases so it can't just be based on the display item type. In making this change we need to look at all display item types that can return non-null from GetChildren (if they can't have children the asr won't change dynamically based on children/the contents). There are four such classes (and then all of their subclasses): nsDisplayContainer, nsDisplayTransform, nsDisplayPerspective, nsDisplayWrapList. In practice nsDisplayContainer is always Ancestor asr (but we still pass Ancestor at all places we create one). nsDisplayPerspective and nsDisplayTransform are always Constant asr. and nsDisplayWrapList has a very large tree of subclasses with various different behaviours of asr.
This also fixes a bug in UpdateASR: if aContainerASR is nothing then we should set the asr to the frame asr rather then early exiting.
Differential Revision: https://phabricator.services.mozilla.com/D262257
This is rather tricky / unfortunate, but this is the low-risk fix for
now. The issue is as follows:
When we construct a subdocument frame, we try to show its viewer by
using a script runner which will call ShowViewer().
If ShowViewer() gets called before the subdoc frame gets laid out
(has the NS_FRAME_FIRST_REFLOW bit set), we pick an (arbitrary) 10x10
device pixel size, and initialize the page with that viewport.
Then, eventually, the frame gets laid out to the correct size and fires
a resize event.
If we have container queries around, we need to lay out the page while
styling, which causes the layout to happen before the script blocker
checkpoint, and thus the viewport to get initialized with the right size
to begin with.
This generally shouldn't be bad, but google chat at least seems to rely
on this resize event (and the divergence being caused by container
queries is rather unfortunate).
For now, do the low risk fix of always using the "initial" subdoc frame
size to show the viewer.
We should ideally sort this out better. Even our "good" behavior is
quite bizarre (e.g, I'd expect going from display: block to none to
trigger a resize event and the viewport to go back to 0... As you noted,
chrome's inner layout sizes do change when the frame is display: none).
But it seems worth to land this at least in the interim.
Differential Revision: https://phabricator.services.mozilla.com/D233399
The info that we get from the check is only used for compositor hit test info and it takes a decent amount of time to check.
Differential Revision: https://phabricator.services.mozilla.com/D229290
Use LayoutDevice units for most these things, since it's what they are:
ScreenIntSize(presContext->AppUnitsToDevPixels(size.width), ...
Is clearly a lie :)
Differential Revision: https://phabricator.services.mozilla.com/D228586
Printing has a weird code-path which doesn't use the refresh driver.
Update frame sizes explicitly, and remove the hack in
nsDisplayRemote::Paint (which is what probably papered over this).
Differential Revision: https://phabricator.services.mozilla.com/D222372
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
Daniel Holbert