Change to derive from nsDisplayEffectsBase, since the backdrop-filter
can still have a visual bounds (and effect) even if the child
stacking context has no items. Also use the same approach to get
the bounding rect and implement GetBounds as nsDisplayFilters uses.
Differential Revision: https://phabricator.services.mozilla.com/D145295
This has a TODO about empty page names on previous sibling frames, to match
Chrome's behavior of page break coalescing we should be looking to the frame
before that sibling and check for page breaks there instead.
Differential Revision: https://phabricator.services.mozilla.com/D140423
Basically, the transferred min & max sizes shouldn't override the min &
max sizing properties, so applying it earlier than these properties
should be identical. This just makes the flex base size and main size be
more correct at the beginning (and so other adjustments of sizes
in flex algorithm can override the transferred min/max sizes), for
non-replaced elements.
Note:
In Chromium code, it clamps the flex items' base size by transferred min &
max sizes, but the computation of items' used min & used max sizes doesn't
include the transferred min & max sizes.
So in this patch, I'm trying to make this patch simple: we let minimum &
maximum sizes only taken into account for flex base size and only for
non-replaced elements for now. So the behavior should be similar to other
browsers.
And we may have to update this tentative solution once these spec words get
updated.
Differential Revision: https://phabricator.services.mozilla.com/D144499
This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
Now that we don't include overflow in outlines (bug 1739894) the
overwhelmingly common case is that innerRect == GetRectRelativeToSelf(),
except on a couple special cases.
Avoid storing the property in those cases. The test introduced in the
patch above still ensures we invalidate rendering correctly even without
the presence of the assert.
Depends on D141320
Differential Revision: https://phabricator.services.mozilla.com/D141321
This doesn't change behavior but makes some code a bit nicer to read and
documents some of the code that wasn't obvious otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D141236
This doesn't change behavior just yet, but seems worth doing separately.
With this patch, we can render content overlaid on top of an image
frame, by attaching a shadow root to it. The idea is to use this for
text recognition (OCR) of text inside images.
I chose to implement this using the DynamicLeaf stuff that I removed in
bug 1746310 (because nsMenuPopupFrame was its only user).
That seems simpler than either a new frame class, or more special cases
in the frame constructor, etc. But let me know if you disagree.
There are further changes that we want to do. For example, trying to
select the overlaid text with the mouse right now will start dragging
the image. For that, we might need to tweak our selection / mouse
dragging code. But those seem all changes that can go on top of this.
Differential Revision: https://phabricator.services.mozilla.com/D140638
None of these changes should change the behavior.
- In `ConsiderChildOverflow()`, replace the legacy term "visual" overflow.
- `GetOverflowAreasRelativeToSelf()`, `ScrollableOverflowRectRelativeToSelf()`,
`InkOverflowRectRelativeToSelf()` can really be terser.
- Replace `mRect.TopLeft()` with `Position()`, and
`nsRect(nsPoint(0, 0), GetSize())` with `GetRectRelativeToSelf()`, making them
shorter and clearer.
- Move `GetOverflowRect()` to private section because it's an implementation
detail of `InkOverflowRect()` and `ScrollableOverflowRect()`.
Differential Revision: https://phabricator.services.mozilla.com/D140437
When a position:sticky element "sticks" in the scroll container's scrollport, we
compute its containing block's overflow areas by including its overflow areas
located at its relative position. This makes the element's normal position
unreachable because its overflow areas located at its "normal position" might
not be within its containing block's overflow areas. Block frame doesn't have
this problem because `nsLineBox` always includes the element's normal position
rect in its own rect.
Therefore, when including a sticky child frame's overflow area into its parent's
overflow area, the overflow areas located at its normal position should be
included as well. This behavior is consistent with a relatively positioned child
frame. (A position:relative frame's normal position is always reachable when
scrolling, at least in both axes that grow positively.)
Differential Revision: https://phabricator.services.mozilla.com/D140373
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
We already call MaybeQueueCacheUpdateForStyleChanges from DidSetComputedStyle for reconstructed frames.
However, at that point, nsIContent::GetPrimaryFrame (and thus LocalAccessible::GetFrame) returns null, which means we're unable to check for style changes.
Instead, we now handle style changes for reconstructed frames in PruneOrInsertSubtree, at which point the frame is definitely available.
Differential Revision: https://phabricator.services.mozilla.com/D138627
This adds a round trip from double -> float -> double because
CSSRect is float but it should be ok because most users of gfxRect (RectDouble)
should be using Rect instead anyways.
Differential Revision: https://phabricator.services.mozilla.com/D137811
Depends on D136163
I have a feeling this isn't exactly the right way to pass this info, since the old WR code must have known about the perspective node without using my new flag.
Differential Revision: https://phabricator.services.mozilla.com/D136180
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
The assertion here was added during the iterator refactoring in bug 1732349,
but is actually bogus. The old code would have returned via the MOZ_TRY_VAR
that wrapped the call to blockFrame->GetLineNumber(); that's replaced by
iter->FindLineContaining(), so we should now check for an error there and
similarly just return to the caller, not assert.
Differential Revision: https://phabricator.services.mozilla.com/D134950
Bug 1550869 made all the non-editable images return a `FrameTarget` with
`userFrameEdge=true`. When the user moves the mouse pointer to select an image
from its left edge, the mouse pointer needs to reach the right edge of the image
in order to complete the selection. This makes it difficult to select an image
at the end of a line.
This patch restores the behavior to select a non-draggable & non-editable image
to it was before bug 1550869. That is, we recognize the image selection when the
mouse pointer moves passed the middle point of the image
width (`OffsetsForSingleFrame`). Both blink and webkit have the same behavior,
but no spec text dictates this behavior, so I mark the wpt test as "tentative".
Differential Revision: https://phabricator.services.mozilla.com/D133960
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
Applying it to SVG-transformed frames is wrong, and causes us to
rasterize rather massive SVGs. This is consistent with the other CSS
3d transforms code, and our rendering of the test-case matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D132040
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
nsIScrollableFrame::IsScrollingActive basically means "has this scroll frame been scrolled recently or is this the root scroll frame". Neither of which is relevant when we are async scrolling a scrollframe on the compositor.
What determines if we can scroll a scroll frame async is ScrollFrameHelper::mWillBuildScrollableLayer, aka nsIScrollableFrame::IsMaybeAsynchronouslyScrolled.
The code in nsDisplayStickyPosition::GetStickyScrollContainer already mostly neuters nsDisplayStickyPosition is this isn't the case, this just takes it one step further.
This also removes one more user of nsIScrollableFrame::IsScrollingActive, there are only a handful left.
Differential Revision: https://phabricator.services.mozilla.com/D126427
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
We store this new bit in nsIFrame instead of in ReflowInput to record a
change to padding (inspired by the mHasBSizeChange bit). That is because
we may construct a ReflowInput more than one time before reflowing the
frame. The first construction of ReflowInput (in
SizeComputationInput::InitOffsets) will update
nsIFrame::UsedPaddingProperty() using the latest style data, so
we *cannot* determine the padding change in any of the subsequent
construction of ReflowInput.
dynamic-change-inline-size-001.html is the scenario fixed by
bug 1307853. We've already passed this test without this patch.
dynamic-change-inline-size-002.html is equivalent to 001.html except
it's written with "box-sizing:content".
dynamic-change-inline-size-003.html is adapted from testcase 2 in bug
1729122 comment 4. Both tests pass after this patch.
Differential Revision: https://phabricator.services.mozilla.com/D126422
I'm not aware of any reason we shouldn't do this, as it is interoperable
with other browsers, and it causes compat issues from sites that forget
to use the prefixed version.
Note this removes some #[parse(aliases)]. These only affect devtools
autocomplete behavior, and we avoid autocompleting -moz-prefixed
keywords when possible, so even though it's a slight behavior change,
it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D126718
We only need the actual iterator once, to get the line number; subsequently, we can use
the new CanProvideLineIterator method to check if we've found a block frame without
paying the cost of actually initializing it.
This eliminates the last remaining caller of nsIFrame::GetLineNumber, so that method
(which is prone to inefficient usage) can be removed altogether.
Differential Revision: https://phabricator.services.mozilla.com/D126532
This means nsBlockFrame::GetLineIterator is also infallible, so callers that know
they're dealing with an nsBlockFrame (not an arbitrary nsIFrame) don't need to
check for null.
Differential Revision: https://phabricator.services.mozilla.com/D126470
Previously, to check whether two frames were on the same line, you had to call nsIFrame::GetLineNumber on both of them.
If the lines were in a different containing block, this wastefully created line iterators.
With this new method, you can get the containing blocks for both frames and only create a single line iterator if the blocks are the same.
To achieve this, nsIFrame::CanProvideLineIterator was also added and is used by GetContainingBlockForLine.
Accessibility will use this new functionality in its new text boundary implementation.
Differential Revision: https://phabricator.services.mozilla.com/D126433
This frame property's type is small enough to fit directly in the property
table's 64-byte slot; so, this patch makes us store the data directly there
(rather than allocating it externally and storing a pointer in the table).
This patch shouldn't impact behavior at all.
Differential Revision: https://phabricator.services.mozilla.com/D126031
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125738
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Depends on D125610
Differential Revision: https://phabricator.services.mozilla.com/D125611
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
GetOffsetToCrossDoc takes a valid non null pointer of nsIFrame, so it will not
walk up the frame tree across process boundaries.
If the call site needed the offset up to a frame in a different process, which
means the function call used for obtaining the nsIFrame needs to be audited such
as bug 1727229, which is for auditing GetReferenceFrame call sites
(GetOffsetToCrossDoc is often used with GetReferenceFrame, something like
`GetOffsetToCrossDoc(GetReferenceFrame())`.
FWIW, I did skim all GetOffsetToCrossDoc call sites [1], all look okay to me,
they are in auto scrolling, event handling, display list building, in the parent
process (i.e. XUL), etc. etc. Those features have been addressed in Fission.
[1] https://searchfox.org/mozilla-central/search?q=nsIFrame%3A%3AGetOffsetToCrossDoc&path=&case=true®exp=false
Differential Revision: https://phabricator.services.mozilla.com/D123553
IsVisibleConsideringAncestors has a PresShell::IsUnderHiddenEmbedderElement which
is representing ancestor's visibility state in different process (but only for
contents processes). so it doesn't need to walk up the frame tree across process
boundaries.
Differential Revision: https://phabricator.services.mozilla.com/D123556
Collapsing selection with middle click is compatible behavior with Chrome.
However, some Firefox users don't like this behavior, and we have not done it
before. Therefore, this patch adds a hidden pref to prevent the new Chrome
compatible behavior.
Keeping compatible behavior is important and middle click is mainly used for
autoscroll. Therefore, if auto scroll is disabled, we should ignore the new
pref for better compatibility.
Unfortunately, we collapse selection before `AutoScrollChild` handles
`mousedown` event with the listener in the system group (
`nsIFrame::HandleEvent()` is called before that). Therefore, we cannot prevent
the selection change from `AutoScrollChild` only when it starts scroll.
For solving this issue, we need a lot of big changes. Therefore, for now,
this patch just checks whether the pref is enabled or not.
And also the new pref is ignored when middle click paste is enabled because
it may be followed by "paste" event even when user clicks non-editable nodes.
Then, if web apps handle "paste" event, the new selection range may be
important. Therefore, we should ignore the new pref in this case.
Differential Revision: https://phabricator.services.mozilla.com/D122931
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
If middle button click with `Shift` key occurs, Chrome and Safari extend the
selection in most cases. However, if the clicked position is in a link,
Chrome does:
* If editable, collapse selection into the link instead of extending selection.
* If not editable, not extending selection and open tabs.
We should follow this behavior for both backward compatibility and web-compat.
Differential Revision: https://phabricator.services.mozilla.com/D119252
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
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
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
Bug 1637130 renamed visual overflow to ink overflow to match the spec
terms. This is a follow-up to rename the struct that stores small ink
overflow in nsIFrame.
Differential Revision: https://phabricator.services.mozilla.com/D107735
UnionRectEdges() and UnionEdges() are equivalent, and the later has a
modern interface with a shorter name. Let's remove the former.
Differential Revision: https://phabricator.services.mozilla.com/D107315
I'm not sure whether we should deal with ancestor scales and such. There
seemed to be a discussion about that in D77436 but dealing with
partially-3d-transformed content sounds like a massive pain. For now
this fixes the start point, which is a progression.
Differential Revision: https://phabricator.services.mozilla.com/D106896
I assume nsIFrame::IsAbsolutelyPositioned()'s callers really want to
check whether a frame is a real abspos frame, not just check a frame has
a abspos style. This could potentially change the behavior, but I feel
its the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D106580
IsFontSizeInflationContainer() is a helper of nsIFrame::Init(). That is,
when it is called from a caller like
nsCSSFrameConstructor::CreateFloatingLetterFrame(), the
`NS_FRAME_OUT_OF_FLOW` bit is not set yet. There is also a hint at the
call site
https://searchfox.org/mozilla-central/rev/362676fcadac37f9f585141a244a9a640948794a/layout/generic/nsIFrame.cpp#770
To fix it, we need to change the condition to check only the
floating style.
layout/reftests/bidi/with-first-letter-2b.html is one of the testcases
that can trigger the following assertion without this patch.
###!!! ASSERTION: should not be container for font size inflation
Differential Revision: https://phabricator.services.mozilla.com/D106579
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
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 is a preparation patch for Part 2 -- We need a way to ignore
aspect-ratio when measuring a flex item's content block-size, because we
don't want the stretched inline-size transferring through aspect-ratio
to set block-size.
This patch hasn't changed the behavior yet. Part 2 is going to utilize
mAspectRatio.
Differential Revision: https://phabricator.services.mozilla.com/D106383
`UseAutoISize` flag is buggy when used on table flex items because it
never propagates to inner table frame.
Luckily, we can fix it by replacing the flag with StyleSizeOverrides
emplacing an 'auto' mStyleISize, because when computing the size, the
size overrides already propagates from table wrapper to inner table via
the following path:
`nsTableWrapperFrame::ComputeSize()` [1] ->
`nsTableWrapperFrame::ComputeAutoSize()` ->
`nsTableWrapperFrame::InnerTableShrinkWrapISize()` ->
`nsTableFrame::ComputeSize()`.
Part 3 is going to propagate the size overrides to inner table in
`nsTableWrapperFrame::CreateReflowInputForInnerTable()` during reflow.
This patch fixes the content size suggestion for table flex items.
Combining this patch with Part 3, we can fix those reftests in Part 4.
[1] In this patch, the table wrapper is still using nsContainerFrame's
ComputeSize(), but Part 3 is going to override it.
Differential Revision: https://phabricator.services.mozilla.com/D103438
aspect-ratio applies to all elements except inline boxes and internal ruby or
table boxes. So we should return false for inline frames, table internal frames
(i.e. except nsTableFrame and nsTableWrapperFrame), and ruby internal frames.
Also, we can drop ComputeSizeFlags::SkipAspectRatio because this frame
bit can replace this flag.
Note: it seems nsRubyBaseContainerFrame and nsRubyTextContainerFrame are
inline, so we return false for them.
This will be very useful when computing the intrinsic size because
IntrinsicForAxis() computes the intrinsic size for all descendant frames and
some of descendants may not support aspect-ratio. It's pretty hard to achieve
this by just adding a flag for this function.
Differential Revision: https://phabricator.services.mozilla.com/D104296
After Part 5 & Part 6, we don't need to override flex item's flex-basis
proprety or preferred main size in ComputeSize() and
ComputeSizeWithIntrinsicDimensions(), we can change the two style sizes
to references, and give both of them to shorter names.
Differential Revision: https://phabricator.services.mozilla.com/D102475
FlexItem::StyleCrossSize() hasn't been used in this patch, but it will
be used in a later patch that revises size overrides in flex item's
final reflow.
Differential Revision: https://phabricator.services.mozilla.com/D101796
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
After Part 5 & Part 6, we don't need to override flex item's flex-basis
proprety or preferred main size in ComputeSize() and
ComputeSizeWithIntrinsicDimensions(), we can change the two style sizes
to references, and give both of them to shorter names.
Differential Revision: https://phabricator.services.mozilla.com/D102475
FlexItem::StyleCrossSize() hasn't been used in this patch, but it will
be used in a later patch that revises size overrides in flex item's
final reflow.
Differential Revision: https://phabricator.services.mozilla.com/D101796
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
After Part 5 & Part 6, we don't need to override flex item's flex-basis
proprety or preferred main size in ComputeSize() and
ComputeSizeWithIntrinsicDimensions(), we can change the two style sizes
to references, and give both of them to shorter names.
Differential Revision: https://phabricator.services.mozilla.com/D102475
FlexItem::StyleCrossSize() hasn't been used in this patch, but it will
be used in a later patch that revises size overrides in flex item's
final reflow.
Differential Revision: https://phabricator.services.mozilla.com/D101796
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
We have to set the flag, AspectRatioUsage::ToComputedISize if we
resolve the min-content/max-content/fit-content by aspect-ratio, so that
we can handle min-width:auto well.
Differential Revision: https://phabricator.services.mozilla.com/D99406
ComputeISizeValue() takes aspect-ratio into account. Also, add a
ComputeSizeFlag which skips aspect-ratio in ComputeISizeValue(), so
internal table boxes can use this flag to skip aspect-ratio.
Differential Revision: https://phabricator.services.mozilla.com/D99290
We may use the block size to compute the inline size if there is a
non-auto finite aspect-ratio and definite block size, so we need more
information on the block axis. Therefore, we have to pass LogicalSize
for containing block and boxing size adjustment.
Differential Revision: https://phabricator.services.mozilla.com/D99289
Otherwise we stop moving focus because, when we find the scrollable
area, we determine that we need to focus the fieldset, but then the
focus manager early-returns in `nsFocusManager::SetFocusInner`.
Depends on D100423
Differential Revision: https://phabricator.services.mozilla.com/D100424
We always compute the tabindex value, so just return it to the caller
all the time. This allows us to use early-returns which makes the code a
bit easier to follow.
This patch shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D100423
Based on the spec, if the aspect-ratio property value is:
1) auto: we should always use content-box dimensions.
2) <ratio>: the aspect-ratio works with box sizing dimensions.
3) auto && <ratio>: we use content-box dimensions in all cases.
So we need an extra flag to address that we should use box-sizing or
always use content-box dimensions while computing the size in
ratio-dependent axis.
This also updates some wpts for non-replaced elements because we should
use content-box if aspect-ratio is 'auto && <ratio>'.
Differential Revision: https://phabricator.services.mozilla.com/D100072
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
We want to call it in nsFlexContainerFrame in the next part.
The method also tests form control elements via the helper
FormControlShrinksForPercentISize, not just replaced boxes, so rename it
for accuracy. We also rename the helper by dropping "I" from the
"PercentISize" because the axis the element contributingx to isn't
necessarily its inline-axis.
Differential Revision: https://phabricator.services.mozilla.com/D99951
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
