Both are aliases to IntrinsicISizeType::MinISize and
IntrinsicISizeType::PrefISize.
Remove MOZ_ASSERT in nsLayoutUtils::IntrinsicForAxis and
nsContainerFrame::DoInlineIntrinsicISize since IntrinsicISizeType is a
enum class nowadays, which cannot have other values.
I've compiled this patch with DEBUG_INTRINSIC_WIDTH defined in
nsLayoutUtils.cpp, and fixed aWM undefined in
nsLayoutUtils::MinSizeContributionForAxis().
Differential Revision: https://phabricator.services.mozilla.com/D94618
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
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
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
This includes a update of the ini file. I noticed the color
of the video is not equal to "rgb(0, 128, 0)" (i.e. background-color: green).
It is "rgb(1, 128. 1)" on Mac (without WebRender),
"rgb(0, 125, 0)" on Mac (with WebRender), and "rgb(1, 128, 2)" on Linux.
Perhaps it is a bug of our video rendering or video scaling. Therefore,
I added fuzzy into the ini file with max 0-3 difference per channel.
(Note: The size of this video is 50x50, so the max number of pixels is 2500.)
Differential Revision: https://phabricator.services.mozilla.com/D79337
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
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
--HG--
extra : moz-landing-system : lando
When window is resized, the cue would usually be zoomed in or out automatically with the video and keep its relative position to video.
However, if video is being applied the explicit percentage value on its 'width' or 'height', we have to recompute cue's position in this situation, because the width or height of the video would be scaled again after applied the first size scaled which is caused by resizing.
Differential Revision: https://phabricator.services.mozilla.com/D36138
--HG--
extra : moz-landing-system : lando
Also, make the assertion shorter & more to the point. In particular,
I'm removing the note about stray whitespace, which is based on one
previous scenario that caused extra child frames; but I don't have
much confidence that potential future causes of this assertion-failure
will have that specific problem as their root cause.
Differential Revision: https://phabricator.services.mozilla.com/D28547
--HG--
extra : moz-landing-system : lando
Spec quote from https://drafts.csswg.org/css-contain/#containment-size :
"Replaced elements must be treated as having an intrinsic width and height of 0"
To achieve that, we just need to:
(a) make all of these frame classes' GetPrefISize and GetMinISize methods return 0 if they're styled with contain:size.
(b) make all of these frame classes' GetIntrinsicSize() and GetIntrinsicRatio() methods return 0,0.
In some cases, these methods are implemented in terms of common helper methods
(and sometimes member variables). For those cases, this patch adjusts the
helper methods (and variables) rather than the getters themselves.
Also: in one case (nsHTMLCanvasFrame), I needed to update its ComputeSize
method to remove a dependency on the "real" intrinsic size & ratio. I believe
the other classes' ComputeSize implementations do the right thing automatically
by sharing code & data with their intrinsic-size codepaths.
Differential Revision: https://phabricator.services.mozilla.com/D28159
--HG--
rename : testing/web-platform/tests/media/white.webm => testing/web-platform/tests/css/css-contain/support/white.webm
extra : moz-landing-system : lando
This patch shouldn't affect behavior; it's just simplifying existing code with
a new convenience constructor.
Differential Revision: https://phabricator.services.mozilla.com/D28918
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando