This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
When the iframe is inside a scaled container, the offset to the reference frame
needs to be scaled.
This change fixes both a rendering issue (bug 1682197) and a hit-testing issue
(bug 1682200) altogether for non WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D100218
This avoids a problem where we receive the IPC message from the child
with updated intrinsics before an <embed> or <object> has had its frame
constructed in the parent, and drop the update.
Differential Revision: https://phabricator.services.mozilla.com/D99304
As there's no incremental reflow for non-print documents, we can't rely
on FinishReflow getting called.
Not ultra-pretty, better ideas welcome.
Differential Revision: https://phabricator.services.mozilla.com/D96790
CSSPixel::ToAppUnits() requires computation at runtime. Since most of
the layout computations require `nscoord`, this patch defines extra
intrinsic sizes in app units.
Differential Revision: https://phabricator.services.mozilla.com/D96258
This patch moves the preferred aspect-ratio calculation from each
replaced elements' GetIntrinicRatio() into GetAspectRatio(), because
they share the same logic.
For nsImageFrame, the cached mIntrinsicRatio now stores only the image's
intrinsic ratio, not considering the aspect-ratio property.
This patch fixed "object-fit:contain" for canvas, image because
GetIntrinicRatio() no longer considers aspect-ratio. This also fixed
replaced elements' size when both "aspect-ratio:<ratio>" and
"contain:size" is specified.
This also makes us pass some of the aspect-ratio tests because we change
GetIntrinicRatio() into GetAspectRatio() in
nsLayoutUtils::IntrinsicForAxis() in Part5, which is used by nsBlockFrame
(via nsLayoutUtils::IntrinsicForContainer) to implement GetMinISize().
Differential Revision: https://phabricator.services.mozilla.com/D91229
For now, GetAspectRatio() is just an alias for GetIntrinicRatio(). In
Part 7, we're going to have GetAspectRatio() consider aspect-ratio
property so that each replaced elements only need to report their
intrinsic ratio via GetIntrinicRatio(). Non-replaced element can also
call GetAspectRatio() to get the ratio suitable to calculate layout
size.
As of this patch, all the replaced elements'
GetIntrinsicRatio() (including nsImageFrame::mIntrinsicRatio) consider
aspect-ratio properties (added in bug 1639963). This is wrong, because
it affects replaced element's content ratio. So we adapt only callers
[1] involving the computation of the frame's external sizes to retain
the behavior after Part 7.
This change shouldn't change behavior.
[1] Exceptions include 1) a caller in nsIFrame::ComputeSize() checking
the frame has no intrinsic ratio; 2) other frame classes implementing
nsIFrame::GetIntrinsicRatio() by calling their parent's
GetIntrinicRatio(). nsSubDocumentFrame::GetIntrinicRatio() is an
example.
Differential Revision: https://phabricator.services.mozilla.com/D91227
This works, though probably we want to do some follow-up tweaks, like
the adding of the onload blocker and so on, so that we can avoid the
UpdateDimensions hack.
We may also want a PrintObject in the nsPrintJob tree, perhaps...
Differential Revision: https://phabricator.services.mozilla.com/D90310
Also combine the border and padding arguments for
nsContainerFrame::ComputeSizeWithIntrinsicDimensions(), too. This method
is used as a helper to implement ComputeSize() for various replaced
elements. Its callers are all within nsIFrame's derived classes'
overridden methods, so I'm not bothering to convert them in a separate
patch.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D90064
When <object> targets to a svg image, we use nsSubDocumentFrame. The
intrinsic ratio should be overridden by aspect-ratio while computing
its size on this frame.
This update in nsSubDocumentFrame also works in iframe.
Differential Revision: https://phabricator.services.mozilla.com/D79362
In order to apply Automatic content-based minimum sizes, we have to know
the content size on the block axis. We cannot get the content size until
we finish the reflow of the child frames. So we have to keep a flag
which indicates the size of the ratio-dependent axis is overrideen by
aspect-ratio in ReflowInput.
We will set the correct return value in the next patch, For now, we
always return AspectRatioUsage::None.
Differential Revision: https://phabricator.services.mozilla.com/D79335
WR handles snapping of primitives and clips, and prefers the input
data to be exact floats. This fixes an inconsistency between the
clip and bounds of iframes in WR when there is a fractional
device-pixel ratio set.
Differential Revision: https://phabricator.services.mozilla.com/D85219
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
parser/htmlparser/tests/crashtests/515533-1.html most cleanly creates this crash if you repeat it many times.
It contains an iframe to a local file (so it's a same process iframe). The document in the iframe has an inline script that does
window.location.replace("data:text/plain,");
since crashtests have the pref browser.tabs.remote.dataUriInDefaultWebProcess set (to get more testing of fission) this makes the iframe now in a different process from it's parent.
When the bug happens we create the retained nsDisplaySubDocument before the process change, the document inside the iframe has a presshell, and importantly, it does not yet have a root frame. Then the remoteness change happens on the iframe, ResetFrameLoader is called on the nsSubDocumentFrame to remove the old frame loader. So now the nsSubDocumentFrame can't find a presshell (either via views or the frameloader).
The reason that the document in the iframe not having a root frame when the nsDisplaySubDocument is created is important is because if we had a root frame then the root frame would be the mFrame of the nsDisplaySubDocument and when the root frame got destroyed for the remoteness change that frame destruction would make sure that the nsDisplaySubDocument cannot be re-used. The nsSubDocumentFrame sticks around though, so the nsDisplaySubDocument doesn't think anything changed.
Differential Revision: https://phabricator.services.mozilla.com/D65888
There are two distinct fixes in this patch.
1) Fix the rect we pass to EffectsInfo for both webrender and non-webrender case. The rect needs to be in coordinates of the subdocument but it was including the border/padding of the containing iframe. I also intersected it with the content rect so it doesn't extend outside of the subdocument, this doesn't fix anything AFAIK. I didn't track what caused this, it was likely in the first iteration of this code.
2) For webrender we double included the content rect offset in the rect we passed to PushIFrame because GetContentRectLayerOffset already includes that offset. This part is a regression from bug 1406715.
Differential Revision: https://phabricator.services.mozilla.com/D60208
