This prevents grid container frames from being considered subgrid (even when
they have contain:layout/paint) when they are themselves a grid item of a
contain grid.
Differential Revision: https://phabricator.services.mozilla.com/D59790
--HG--
extra : moz-landing-system : lando
This is needed to support min() / max() / clamp(), etc, as those need to be a
tree of values and thus need heap storage.
This unfortunately grows LengthPercentage to be two pointers, which is bad as
it blows up the size of nsStylePosition enough to trigger the size assertions.
This patch comments out the assertion for now, the follow-up patches will
uncomment them.
Differential Revision: https://phabricator.services.mozilla.com/D58700
--HG--
extra : moz-landing-system : lando
The order of argument evaluation is implementation-defined, so we can't trust
whether the .Length() or the std::move() will get executed first. This is OK
right now since the constructor takes the argument by rvalue and so it can't be
emptied out before the .Length() call. However, a change to the types in the
constructor's argument list could make this still compile, but then depend on
compiler-dependent argument evaluation order to get the correct result.
Differential Revision: https://phabricator.services.mozilla.com/D59238
--HG--
extra : moz-landing-system : lando
Nowadays, ColumnSetFrame is an inner frame under ColumnSetWrapperFrame.
It always has "block-size: auto", so `aReflowInput.ComputedBSize()`
always equals to NS_UNCONSTRAINEDSIZE.
Also, -moz-column-content no longer has "max-block-size: 100%", so
NS_FRAME_CONTAINS_RELATIVE_BSIZE can never be set on ColumnSetFrame when
constructing ReflowInputs for ColumnSetFrame's children in
`ReflowInput::InitResizeFlags`. Removing the bit is not needed, either.
Differential Revision: https://phabricator.services.mozilla.com/D58732
--HG--
extra : moz-landing-system : lando
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
Nowadays, ColumnSetFrame is an inner frame under ColumnSetWrapperFrame.
It always has "block-size: auto", so `aReflowInput.ComputedBSize()`
always equals to NS_UNCONSTRAINEDSIZE.
Also, -moz-column-content no longer has "max-block-size: 100%", so
NS_FRAME_CONTAINS_RELATIVE_BSIZE can never be set on ColumnSetFrame when
constructing ReflowInputs for ColumnSetFrame's children in
`ReflowInput::InitResizeFlags`. Removing the bit is not needed, either.
Differential Revision: https://phabricator.services.mozilla.com/D58732
--HG--
extra : moz-landing-system : lando
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
The information in it is always derivable from the values of mRepeatAutoStart
and mRepeatAutoEnd. Additionally, its value is used in some cases where it has
not yet been set properly (such as CalculateRepeatFillCount).
This works out currently because the default value is zero we only accept
repeat(auto-fill, ...) and repeat(auto-fit, ...) CSS values that have a single
element in the repeat. In that case, zero is the correct value for
RepeatEndDelta.
Differential Revision: https://phabricator.services.mozilla.com/D58871
--HG--
extra : moz-landing-system : lando
This cleans up and also allows us to keep the distinction between content: none
and content: normal, which allows us to fix the computed style we return from
getComputedStyle().
Do this last bit from the resolved value instead of StyleAdjuster, because
otherwise we need to tweak every initial struct for ::before / ::after.
Differential Revision: https://phabricator.services.mozilla.com/D58276
--HG--
extra : moz-landing-system : lando
In particular, the ones where we transcode unconditionally atm (property names
and such).
There are others like cssText getters and setters which are a bit harder,
because I either need to rewrite all our serialization code to work with UTF8
(which is fine, but a lot of work), or teach webidl to have a setter that takes
UTF8String as input but returns DOMString as output (which is at best hacky).
Differential Revision: https://phabricator.services.mozilla.com/D58631
--HG--
extra : moz-landing-system : lando
This change effectively disallows sticky elements to enlarge overflow
area. That is, the position of a sticky element will be bounded by the
union of scrolled frame's border-box and the overflow area created by
other non-sticky elements within the same block formatting context.
This makes Firefox's position:sticky elements behaves like Google Chrome
in this respect.
Differential Revision: https://phabricator.services.mozilla.com/D54345
--HG--
extra : moz-landing-system : lando
This change effectively disallows sticky elements to enlarge overflow
area. That is, the position of a sticky element will be bounded by the
union of scrolled frame's border-box and the overflow area created by
other non-sticky elements within the same block formatting context.
This makes Firefox's position:sticky elements behaves like Google Chrome
in this respect.
Differential Revision: https://phabricator.services.mozilla.com/D54345
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
The two masks are used only in nsBlockFrame::Init, so they should be
defined closer to their usage.
Note that 'constexpr' declared on functions implies 'inline'.
Differential Revision: https://phabricator.services.mozilla.com/D57724
--HG--
extra : moz-landing-system : lando
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--HG--
extra : moz-landing-system : lando
This matches the new servo layout engine too, and thus removes some #[cfg]
gunk. Just use `flow` since it doesn't simplify the layout code as much.
Differential Revision: https://phabricator.services.mozilla.com/D45973
--HG--
extra : moz-landing-system : lando
We also need to adjust the scroll range we use. We do this by adding GetScrollRangeForUserInputEvents which just uses the range that GetAvailableScrollingDirectionsForUserInputEvents computed.
This should give two improvements:
1) CanScrollOn will not report that the user can scroll in an overflow hidden direction.
2) CanScrollOn will report that the user can scroll in an overflow hidden direction if the document is pinch zoomed in so that the user can scroll around the layout viewport.
Differential Revision: https://phabricator.services.mozilla.com/D56301
--HG--
extra : moz-landing-system : lando
This is similar to GetAvailableScrollingDirections but also takes into account any resolution.
Differential Revision: https://phabricator.services.mozilla.com/D57610
--HG--
extra : moz-landing-system : lando
Changes:
This test is a permafail on ubuntu1804, and should be marked as such as the migration to ubunt1804 is actively underway with target date of end of December 2019.
With a fail-if annotation, the hope is that if this test suddenly begins passing we will be notified of it (as opposed to skipping it outright).
Differential Revision: https://phabricator.services.mozilla.com/D57381
--HG--
extra : moz-landing-system : lando
In this way, we can avoid duplicates in FlexItem's normal constructor
and 'strut' constructor.
Differential Revision: https://phabricator.services.mozilla.com/D55821
--HG--
extra : moz-landing-system : lando
Otherwise code like StyleChildrenIterator won't find it, plus it is the right
thing to do anyway.
You don't really want this to inherit from the root element, even though given
this content is under our control (only in chrome documents) it is less of an
issue.
Differential Revision: https://phabricator.services.mozilla.com/D56637
--HG--
extra : moz-landing-system : lando
The line-box's visual overflow area includes margin/border/padding area on
its descendants, as well as extra empty space for text-indent and text-align.
None of that area contains text & merits a backplate. So, we can't rely on
the line-box's visual overflow area to determine the backplate -- we have to
actually dig down to find the text frames.
Also, this patch simplifies our suite of backplate reftests in several ways.
Most notably, this patch:
- removes unnecessary backplatable whitespace in the testcase (since that's
awkward to mock up in the reference case).
- uses a linear-gradient for the background instead of a longer data URI.
- uses the predictably-sized Ahem font inside of tests' form controls.
Differential Revision: https://phabricator.services.mozilla.com/D52065
--HG--
extra : moz-landing-system : lando
The line-box's visual overflow area includes margin/border/padding area on
its descendants, as well as extra empty space for text-indent and text-align.
None of that area contains text & merits a backplate. So, we can't rely on
the line-box's visual overflow area to determine the backplate -- we have to
actually dig down to find the text frames.
Also, this patch simplifies our suite of backplate reftests in several ways.
Most notably, this patch:
- removes unnecessary backplatable whitespace in the testcase (since that's
awkward to mock up in the reference case).
- uses a linear-gradient for the background instead of a longer data URI.
- uses the predictably-sized Ahem font inside of tests' form controls.
Differential Revision: https://phabricator.services.mozilla.com/D52065
--HG--
extra : moz-landing-system : lando
So the reason we get the current bogus result is that overflow:hidden
are block-formatting contexts (BFC) and in paginated mode they are
implemented as block frames with NS_BLOCK_CLIP_PAGINATED_OVERFLOW
to do the clipping. When we have a child float that doesn't fit,
we split it and currently we report that as Overflow-Incomplete
(which is correct for a normal block, but not a BFC) which leads
to creating an overflow-container continuation which has zero
size which we then clip. We should report it as Incomplete
instead, except if we already are an overflow-container.
Differential Revision: https://phabricator.services.mozilla.com/D56416
--HG--
extra : moz-landing-system : lando
This works in chrome because they don't event create an image box for this case,
which is totally against the spec.
The spec doesn't consider an image with a null image request, but our behavior
changes in some other places as well because of it...
Depends on D56367
Differential Revision: https://phabricator.services.mozilla.com/D56368
--HG--
extra : moz-landing-system : lando
This is covered by existing tests, via the removal of the rule in forms.css
Differential Revision: https://phabricator.services.mozilla.com/D56355
--HG--
extra : moz-landing-system : lando
Previously we were just checking overflow hidden here, which is not enough because we can scroll overflow hidden if we are zoomed in.
Differential Revision: https://phabricator.services.mozilla.com/D55918
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
Note that the GetXULPrefSize API might still do a "::BoxReflow" under the hood,
inside its call to RefreshSizeCache.
Also: we can't use GetLogicalUsedMargin() in this special case, because the
child may not have been reflowed (which is what populates the "used margin"
frame property). So instead, we pull the margin off of the reflow state.
As noted in the code-comment alongside that call, this won't work with
percent margins, but hopefully we can just avoid those in our frontend code
that uses XUL-in-grid-items.
Also, this patch makes the grid call ReflowChild() on its grid items using
a loose guess at their position, rather than at position 0,0. This helps
popup frames figure out their size during reflow and size their children
properly.
Differential Revision: https://phabricator.services.mozilla.com/D54886
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
I couldn't repro this with the STR in the bug, but I can repro by inspecting a
grid in print preview, where we don't properly honor the re-reflow request
because $reasons.
Differential Revision: https://phabricator.services.mozilla.com/D55264
--HG--
extra : moz-landing-system : lando
On Chrome, visual viewport resize event is fired repeatedly during dynamic
toolbar transitions and visual viewport height obtained by the VisualViewport
API is also changed, but in terms of layout the height value is never used
until the dynamic toolbar height reaches to zero or is changed from zero.
The height used at the time is the height for vh units when the toolbar height
reaches to zero and the ICB height when the toolbar height is changed from zero.
To do so, we need to have another visual viewport size in parallel to the
original one and use them depending on situations.
Differential Revision: https://phabricator.services.mozilla.com/D52338
--HG--
extra : moz-landing-system : lando
:ntim was about to add another widget-affecting property (pointer-events) to
menupopups to replace the mousethrough attribute, see bug 1597120.
But pointer-events is inherited, and thus changing pointer-events on any element
would cause a change list of length == the number of descendants of the element,
which is not amazing.
So I suggested using DidSetComputedStyle instead, as this is fairly
popup-specific, but we may as well be consistent and do the same everywhere.
This removes the code to handle the -moz-window-* properties on the root frame,
as I haven't seen any usage of them (we always set them in panel or menupopup).
Differential Revision: https://phabricator.services.mozilla.com/D53377
--HG--
extra : moz-landing-system : lando
This means we no longer have any use for the frame state bit
"NS_STATE_FLEX_MEASUREMENTS_INTERRUPTED". Now, if a flex container
has N children and only the last child is interrupted, we'll only
purge the last child's measurement (and we'll do it promptly at the
end of the whole interrupted reflow).
Differential Revision: https://phabricator.services.mozilla.com/D53687
--HG--
extra : moz-landing-system : lando
It is a bit awkward to use raw MOZ_LOG directly, so I added FLEX_LOG()
to easily add `printf()` style logs.
"\n" is not need because MOZ_LOG() already appends one.
I hope it is OK to change the log module name to "FlexContainer". It's
shorter to type either by using
`MOZ_LOG=FlexContainer:debug ./mach run` or by setting
`logging.FlexContainer=debug` in [runprefs] section in `~/.mozbuild/machrc`
Differential Revision: https://phabricator.services.mozilla.com/D53299
--HG--
extra : moz-landing-system : lando
This was a follow-up from the backplate stuff which I requested but didn't
happen.
Differential Revision: https://phabricator.services.mozilla.com/D53170
--HG--
extra : moz-landing-system : lando
I'm not aware of any usage of LogicalPoint and LogicalPoint in frame
tree dump, but I still want to implement them for the sake of
completeness.
Differential Revision: https://phabricator.services.mozilla.com/D52965
--HG--
extra : moz-landing-system : lando
Note: The output format of BaseSize is "3 x 5", so a pair of parentheses
is added around %s in "logical-size=(%s)" to make it looks better.
Differential Revision: https://phabricator.services.mozilla.com/D52964
--HG--
extra : moz-landing-system : lando
This change uses parentheses, i.e. '(' and ')', to enclose the dimension
of LogicalRect. This match the output of BaseRect's operator<<.
Note: This introduces inconsistency in the frame tree dump because some
of the output format still use braces to enclose the data. But in later
patches, I'll gradually change the format to use parentheses.
Differential Revision: https://phabricator.services.mozilla.com/D52963
--HG--
extra : moz-landing-system : lando
WritingMode.h already depends on ostream header implicitly via
nsBidiUtils.h -> nsString.h. For completeness, I still add #include
<ostream>.
While I'm here, I make the format of debug prints in nsLineBox more
consistent with the counter-part in nsFrame. Some of them will be
revised in the later patches.
Differential Revision: https://phabricator.services.mozilla.com/D52962
--HG--
extra : moz-landing-system : lando
Without this change, the junit test in this commit fail, the failure
rendered result is the area of the position:fixed element covered by
the dynamic toolbar before scrolling is rendered as blank.
Depends on D50418
Differential Revision: https://phabricator.services.mozilla.com/D50419
--HG--
extra : moz-landing-system : lando
Per the spec, if multiple track sizes are given, the pattern is repeated as
necessary to find the size of the implicit tracks:
1. The first implicit grid track after the explicit grid receives the first
specified size, and so on forwards.
2. The last implicit grid track before the explicit grid receives the last
specified size, and so on backwards.
We use a positive index of the auto track sizes for (1) and a negative index
for (2), so we can apply the correct specified implicit size.
Differential Revision: https://phabricator.services.mozilla.com/D52265
--HG--
extra : moz-landing-system : lando
In most cases, we run an animation on an object by changing its
offset-distance/offset-rotate, but keep its offset-path the same.
Building and flattening the path is sometime expensive, especially for
large path, so caching it makes sense to us and have a significant
performance improvement. This is for the main thread motion path
animations.
Note: Even though we support compositor animations for motion path,
nsIFrame::GetTransformMatrix() is still called during the animations for
other usages, so we may still build the gfx::Path on the main thread
without this patch, so this improvement becomes necessary for most cases.
Differential Revision: https://phabricator.services.mozilla.com/D46667
--HG--
extra : moz-landing-system : lando
So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
--HG--
extra : moz-landing-system : lando
The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51805
--HG--
extra : moz-landing-system : lando
This fixes css/css-contain/contain-paint-{002,012,024}.html when not using the
fast path (i.e., with the following patch).
Also invert the check in IsStackingContext as IsFrameOfType is a virtual method,
and IsContain* is just a bitflag.
Differential Revision: https://phabricator.services.mozilla.com/D51804
--HG--
extra : moz-landing-system : lando
The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51805
--HG--
extra : moz-landing-system : lando
This fixes css/css-contain/contain-paint-{002,012,024}.html when not using the
fast path (i.e., with the following patch).
Also invert the check in IsStackingContext as IsFrameOfType is a virtual method,
and IsContain* is just a bitflag.
Differential Revision: https://phabricator.services.mozilla.com/D51804
--HG--
extra : moz-landing-system : lando
Update the comments, name, and fields to show it is agnostic of isize/bsize.
Differential Revision: https://phabricator.services.mozilla.com/D51739
--HG--
extra : moz-landing-system : lando
Accept assertions to avoid intermittent test failures due to assertion count mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D50660
--HG--
extra : moz-landing-system : lando
This distinguishes better between the overloaded aspect of the PerFrameKey and the
actual mixed value.
Depends on D37803
Differential Revision: https://phabricator.services.mozilla.com/D37804
--HG--
extra : moz-landing-system : lando
This static method is assumed to have the same signature as the type's constructor,
and so we must have an implementation of ComputePerFrameKey for each constructor
a display item provides that is called by MakeDisplayItem. Notably this excludes
the MakeClone constructor for a lot of items.
There is a default varargs implementation on nsDisplayItem which everyone
inherits by default, so types which previously didn't overload this method
still don't need to.
Providing an implementation of ComputePerFrameKey on some display item type
shadows the varargs implementation, so one doesn't need to worry about overloading
one constructor but forgetting about another -- if you do, the compiler will only
see the overload and complain that the signature doesn't match.
One slightly annoying result of this is that display items which previously
inherited an overloaded implementation from a superclass now must provide
their own manual implementations. Although as far as I could tell, all of
those cases had a trivial implementation of key=0 (the super class supported
custom keys but the subclasses didn't make use of it).
In those cases I just hardcoded key=0, but it's possible that it would be
better to call into the superclass' implementation to be more robust to changes.
Differential Revision: https://phabricator.services.mozilla.com/D37803
--HG--
extra : moz-landing-system : lando
The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51683
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Split off of Bug 1590894
Rename these to support unprefixed version
Also add alias to keep compatibility
Differential Revision: https://phabricator.services.mozilla.com/D50989
--HG--
extra : moz-landing-system : lando
The idea of these are not to penalize legit uses of scroll anchoring, and
catching pathological cases fast.
The current algorithm I thought of is just whether the average of all the
consecutive scroll anchoring adjustments is less than a given threshold.
If the average adjustment is close to zero and the user is not scrolling, it
means that we're not making much progress.
It is important that zero adjustments don't get counted, since those are common
during window resizes and don't have side-effects anyway.
Exact number may need tuning, let me know if you want it
nightly-and-early-beta-only for now or something.
Depends on D51038
Differential Revision: https://phabricator.services.mozilla.com/D51024
--HG--
extra : moz-landing-system : lando
Split off of Bug 1590894
Rename these to support unprefixed version
Also add alias to keep compatibility
Differential Revision: https://phabricator.services.mozilla.com/D50989
--HG--
extra : moz-landing-system : lando
font-inflation-1e.html is adapted from font-inflation-1a.html with the
writing-mode set on <html> instead of <body>. It can trigger the
assertion "current writing mode should match that of our flow root" in
nsFontInflationData::FindFontInflationDataFor().
The root cause is: nsCanvasFrame can generate the position:absolute
custom content container to contain elements like AccessibleCaret. When
the container is constructed, the container's writing-mode is always
horizontal-rl, which is getting from nsCanvasFrame that uses
ViewportFrame's style.
If <html> has a vertical writing-mode, custom content container's used
mWritingMode becomes orthogonal to ViewportFrame, because <html>'s used
mWritingMode is propagated all the way up to ViewportFrame.
This patch solves the above issue by making the custom content container
a font inflation root, so FindFontInflationDataFor() stops at it instead
of finding all the way up to the ViewportFrame.
Differential Revision: https://phabricator.services.mozilla.com/D48942
--HG--
extra : moz-landing-system : lando
Currently, `nsFrameSelection::CommonPageMove()` is called before every caller
calls `nsFrameSelection::ScrollSelectionIntoView()`. However, when an editing
host has focus, the scroll target may be outside of it. In such case, without
moving caret, user may want only to scroll the scrollable element.
Chrome behaves like so. Chrome also can scroll outside scrollable element
of focused editing host. However, it scrolls caret into view only when
caret is moved actually. Therefore, it makes sense to follow this behavior.
This patch makes `nsFrameSelection::CommonPageMove()` also call
`nsFrameSelection::ScrollSelectionIntoView()`. However, it newly takes
`SelectionIntoView` flag for making callers can choose the condition. I.e.,
`ScrollSelectionIntoView()` should be called always, or only when selection
is actually changed, or shouldn't be called.
Differential Revision: https://phabricator.services.mozilla.com/D50178
--HG--
extra : moz-landing-system : lando
`nsFrameSelection::CommonPageMove()` emulates click in selection limiter
when scrollable frame is outside of focused editing host. However, the
clicked position should be considered with scrollable element's page
scroll amount rather than height of editing host since the height may be
much taller than the scrollable frame.
Differential Revision: https://phabricator.services.mozilla.com/D50177
--HG--
extra : moz-landing-system : lando
Currently, `nsFrameSelection::CommonPageMove()` is called before every caller
calls `nsFrameSelection::ScrollSelectionIntoView()`. However, when an editing
host has focus, the scroll target may be outside of it. In such case, without
moving caret, user may want only to scroll the scrollable element.
Chrome behaves like so. Chrome also can scroll outside scrollable element
of focused editing host. However, it scrolls caret into view only when
caret is moved actually. Therefore, it makes sense to follow this behavior.
This patch makes `nsFrameSelection::CommonPageMove()` also call
`nsFrameSelection::ScrollSelectionIntoView()`. However, it newly takes
`SelectionIntoView` flag for making callers can choose the condition. I.e.,
`ScrollSelectionIntoView()` should be called always, or only when selection
is actually changed, or shouldn't be called.
Differential Revision: https://phabricator.services.mozilla.com/D50178
--HG--
extra : moz-landing-system : lando
`nsFrameSelection::CommonPageMove()` emulates click in selection limiter
when scrollable frame is outside of focused editing host. However, the
clicked position should be considered with scrollable element's page
scroll amount rather than height of editing host since the height may be
much taller than the scrollable frame.
Differential Revision: https://phabricator.services.mozilla.com/D50177
--HG--
extra : moz-landing-system : lando
I discovered this while improving `ScrollFrameHelper::IsPhysicalLTR()`
in Part 1. Our code base needs a notion of physical direction. Let's add
it to WritingMode.
Differential Revision: https://phabricator.services.mozilla.com/D49818
--HG--
extra : moz-landing-system : lando
After bug 1102175, the root scroll frame always obtains its used
WritingMode from either body element or root element. The `if (mIsRoot) {}`
block in `GetFrameForDir()` becomes redundant, so does
`GetFrameForDir()` itself.
Differential Revision: https://phabricator.services.mozilla.com/D49817
--HG--
extra : moz-landing-system : lando
This patch:
- Gives layout/generic/AnonymousContentKey.h an include for `<stdint.h>` to
provide the uint8_t type, and TypedEnumBits.h to provide the
MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS macro. (This is a change in another
directory, but it's needed in order for layout/style/ServoStyleSet.cpp to
build successfully.)
- Adds a missing "nsINode" forward-decl to dom/base/IdentifierMapEntry.h,
because it uses that type in function declarations. (This change is needed
in order for layout/style/CachedInheritingStyles.cpp to build successfully.)
- Gives CSSStyleRule.cpp an include for PseudoStyleType.h,
nsCSSPseudoElements.h, and CSSEnabledState.h because it uses those types.
- Gives GeckoBindings.cpp an include for gfxTextRun.h, to provide the definition
of type gfxFontGroup (so GeckoBindings can call GetFirstValidFont() on an
object of that type).
- Gives Loader.h an include for nsIContentInlines.h, to provide the inline
function IsInUAWidget().
- Gives Rule.cpp an include for HoldDropJSObjects.h, to provide DropJSObjects().
- Gives nsImageLoader.cpp an include for DocumentInlines.h (and Document.h for
good measure), to provide the inline function GetPresContext().
- Gives nsStyleStruct.cpp an include for DocumentInlines.h, to provide inline
function Document::GetPresContext().
- Gives nsStyleTransformMatrix.h an include for Units.h (instead of gfxPoint.h,
which isn't useful) to provide the CSSPoint type.
- Gives nsStyleTransformMatrix.h an include for ServoStyleConsts.h, to provide
LengthPercentage and the various StyleRotate/StyleScale/StyleTransform/etc
types. (These can't be easily forward-declared, because some of them are
legitimate types whereas others are type aliases. We could theoretically
forward-declare all of the underlying types and then repeat the type aliases,
but that'd be verbose and unmaintainable.)
Depends on D50165
Differential Revision: https://phabricator.services.mozilla.com/D50166
--HG--
extra : moz-landing-system : lando
The issues fall into these categories:
- Files that used StaticPrefs::layout_XYZ() API or gfxVars::XYZ that needed an
include. (Addressed by adding the missing include.)
- Files that use mozilla::dom::XYZ or mozilla::gfx::XYZ without qualifying the
namespace & without a 'using' decl. (Addressed by adding "using".)
- A few other includes for types/inlines that were used without their header.
Depends on D50162
Differential Revision: https://phabricator.services.mozilla.com/D50163
--HG--
extra : moz-landing-system : lando
In particular, remove useless virtual keywords per our style guide, and remove
redundant argument names (argument names where the name is contained in the type
of the argument), since they're somewhat useless.
I think the result looks neater.
Differential Revision: https://phabricator.services.mozilla.com/D50074
--HG--
extra : moz-landing-system : lando
This seems to fix it for me, and it's pretty straight-forward, but I _think_
we'd still paint the old image if the image is huge and it's loading, which
may be counter-productive. Maybe we should guard the whole "paint mOldImage"
with and if (!oldImageIsDifferent), wdyt?
Differential Revision: https://phabricator.services.mozilla.com/D50062
--HG--
extra : moz-landing-system : lando
There's so much noise.
Every time I read it I feel lost in a sea of virtual keywords :)
This should help.
Differential Revision: https://phabricator.services.mozilla.com/D50022
--HG--
extra : moz-landing-system : lando
Where possible I ported tests to use the shadow DOM. The following could
potentially be ported, but don't think it worth of it:
test_bug414907.xul - uses children nodes in constructor which is very
different in shadow DOM world
test_bug233643.xul - really tests XBL behavior
test_anonymous_content.py - bug on file already to create shadow DOM
test from scratch
Differential Revision: https://phabricator.services.mozilla.com/D49341
--HG--
rename : devtools/client/inspector/test/browser_inspector_highlighter-xbl.js => devtools/client/inspector/test/browser_inspector_highlighter-custom-element.js
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando