We simplified to just rely on the behavior of the plain argument. That is,
width: fit-content(50%) behaves the same as width: 50%; in all circumstances,
just clamped by min/max-content.
Note: for block axis, we treat fit-content() as initial value its minimal
and maximal value are identical and equal to the initial value in block axis.
From: https://github.com/w3c/csswg-drafts/issues/3731#issuecomment-661408877
Note: this patch doesn't include any update on flex and grid layout. We
may have to come back to check it.
Differential Revision: https://phabricator.services.mozilla.com/D113199
This implements fit-content() for basic layout support. For intrinsic
contribution, we will do that in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D111506
Support fit-content for preferred size, min size, and max size. This
patch only implement the style system. For layout part, we will do that
in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D107161
As per https://drafts.csswg.org/css-will-change/#will-change.
> If any non-initial value of a property would cause the element to
> generate a containing block for absolutely positioned elements,
> specifying that property in will-change must cause the element to
> generate a containing block for absolutely positioned elements.
But in this case the transform property wouldn't apply to the element so
there's no reason to create a stacking-context.
Differential Revision: https://phabricator.services.mozilla.com/D114121
For grid layout, we set UseAutoBSize flag during measuring reflow to
resolve the grid track sizing. We still have to respect aspect ratio
for the calculation of the content contribution.
Differential Revision: https://phabricator.services.mozilla.com/D104936
Based on https://drafts.csswg.org/css-grid/#grid-item-sizing, the grid
items should ignore aspect-ratio if it's stretched in that axis.
1. If the alignment value is stretch: don't apply aspect ratio.
2. If the alignment value is normal: apply aspect ratio if we have one.
3. Other values: apply aspect ratio if we have one.
Note:
We also clamp margin block min size in nsBlockFrame::ComputeFinalSize(), so
grid-aspect-ratio-021.html is still passed without this patch. However, we
add this test case just in case and let other browsers catch this.
Differential Revision: https://phabricator.services.mozilla.com/D105082
The inconsistent usage of block size and aspect ratio in ComputeSize() and
ComputeISizeValue() cause this assertion.
We use StyleSizeOverrides when measuring the content block sizes of flex
items, and the expected computed value of block size is auto.
And so in ComputeISizeValue(), we should use any field in StyleSizeOverrides
that having an override rather than fetching it from the style system.
Differential Revision: https://phabricator.services.mozilla.com/D111031
We have to apply min/max transferred size if inline size is auto or intrinsic
size keywords.
The basic principle is that sizing constraints transfer through the
aspect-ratio to the other side to preserve the aspect ratio to the extent
that they can without violating any sizes specified explicitly on that
affected axis.
Note: block-aspect-ratio-021.html tests the similar case with the non-zero
content size. However we don't have the similar tests for intrinsic size
keywords, so I add them in this patch as well.
Differential Revision: https://phabricator.services.mozilla.com/D110725
This matches Chrome and Safari, as well as what we do for all other <input>s.
<input>s were changed to inline block in 1539469 with a couple of font inflation reftests marked as failing to follow up on. https://hg.mozilla.org/mozilla-central/rev/a1201db1b8cc is the follow up which made inputs not be font inflation containers. The same change for textarea fixes similar reftest failures for textarea. I read through the commit message for the change and doing the same for textareas seems to make sense but I don't understand it in detail.
Differential Revision: https://phabricator.services.mozilla.com/D109603
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
Remove a bit of the aStyleDisplay gunk that shouldn't be needed because
of two reasons:
* Stylo is faster / has the style display one pointer-chase away, as
opposed to the old style system.
* We now check the MAY_BE_TRANSFORMED bit first now, and we deal with
SVG-transformed frames, so for non-transformed frames IsTransformed
should just be a bit-check now.
Differential Revision: https://phabricator.services.mozilla.com/D109511
Chrome and Safari move selection at middle button down and does not modify the
range at middle button up. However, they handle middle button down with
`Shift` key is "continue selection". So, we should handle selection in
nsIFrame when `mousedown` event for middle mouse button is fired, but ignore
multiple selection, drag and drop and maintaining selection for aligning the
behavior to the other browsers.
This patch splits `nsIFrame::HandlePress()` and calls new method which
moves selection from `nsIFrame::HandleEvent()` when middle button is pressed.
(Note that this patch does not check whether middle click paste is enabled
because Chrome moves selection even on Windows which Chrome always disable
middle click paste on.)
With this change, "paste" event target is changed. Previously, we used target
of the preceding `mouseup` event, but we start to use the target of the
preceding `mousedown` event.
Note that even with this patch, we still behave differently from Chrome even
in the following cases:
- middle mouse button down in selected range, we collapse it, but Chrome keeps
the selection.
- middle mouse button click in selected range, we dispatch "paste" event, but
Chrome collapse selection and not dispatch "paste" event.
- middle mouse button down in selected range and up in different element,
Chrome does not modify the range nor dispatch "paste" event.
- Shift + middle mouse button in editable `<table>` works as non-editable
in Chrome, but our editor handles it with special path. Therefore, we
don't modify the range but dispatch "paste" event in the selected range.
Changing them requires bigger change and probably requires some other features'
behavior changes. Therefore, we shouldn't touch these issues until they are
actually reported as web-compat issues.
Differential Revision: https://phabricator.services.mozilla.com/D103997
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.
This patch fixes two callsites:
- The first callsite is an assertion whose condition becomes slightly stricter
but should still be valid, in a scenario where we are at an oop-iframe
boundary.
- The second is in IsFrameScrolledOutOfView(), which is part of an API that we
use to optimize away animations if we can tell they're in an invisible
subtree (see calls to IsScrolledOutOfView() in KeyframeEffect.cpp). If we
run up against an out-of-process iframe boundary when calling
GetCrossDocParentFrame() here, we'll still be OK -- we should still be able
to figure out whether the animation is invisible, via our call to
nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess() a few lines further
down. (Also: worst-case, we'll just run the animation even though it's not
visible; so there's no loss of correctness.)
Differential Revision: https://phabricator.services.mozilla.com/D108878
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.
This patch is focusing on some callsites where we've got a frame that needs a
repaint, and we're propagate that information up its ancestor chain. It's OK
for these notifications to stop when we hit the edge of of an out-of-process
iframe, because painting/compositing at that granularity is handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D108877
This also prevents incorrectly selecting two words when double-clicking at
the end of the first word (before the inter-word space).
We also update the selectAtPoint testcase to target more widely-spread glyphs,
to check that it is behaving accurately across a larger distance.
Differential Revision: https://phabricator.services.mozilla.com/D107309
Based on the discussion in
https://github.com/w3c/csswg-drafts/issues/5721#issuecomment-781702159,
the default ratio-dependent axis is block axis (though the spec issue is
for replaced elements, but I think the behavior should be consistent).
So we should apply aspect-ratio not matter what the inline size is (e.g.
nscoord_MAX, auto or other values).
In the test case, the min-block-size is 1073741823, and its transferred
min-inline-size is also 1073741823, so we get a 1073741823 (i.e. nscoord_MAX)
preferred inline size (i.e. result.ISize(aWM) == NS_UNCONSTRAINEDSIZE).
However, we still have to apply aspect-ratio because the style of block-size is
auto, and so mFlags.mBSizeIsSetByAspectRatio should be set unconditionally here.
I still keep this assertion because it helps me catch this potential
issue. (Just reword it anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D107764
