nsStyleStructList.h was initially made generated in bug 873368 to avoid
manually maintaining boilerplate for if-dispatch, while the if-dispatch
was replaced by jump table in bug 1171842, so the boilerplate went away.
However, in bug 1122781 (before bug 1171842), boilerplate for dependency
check, so it still needs to be generated.
The dependency table is removed in the previous patch, so we no longer
have any boilerplate in the style struct list, and thus it doesn't need
to be generated anymore.
MozReview-Commit-ID: GkbJZ98ojbE
--HG--
extra : rebase_source : a148b97c051bb6c88846cf6ba617c4edef70ca24
extra : source : f1c7d19cde195fb90ac2627d16ed69d020de01b9
The aSamePointerStructs argument is unused now.
Also, aIgnoreVariables can be true everywhere now, since variable changes can't
generate change hints, and anonymous boxes and such don't care about whether
they really changed or not.
Only one caller cares about struct equality, and that already compares variables
manually as an optimization on the rust side.
We had this optimization inconsistently in some cases but not others.
MozReview-Commit-ID: F2EISKlxR3K
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
With all videocontrols UIs implemented in HTML, there is no need to handle
XUL content in videocontrols.
MozReview-Commit-ID: Jq3SecscssO
--HG--
extra : rebase_source : 2f928a221919e7f66f9392d6dac6cf971b75776b
In nsFrame::ComputeSize and nsFrame::ComputeSizeWithIntrinsicDimensions, the
following expressions
isFlexItem && usingFlexBasisForISize
isFlexItem && !usingFlexBasisForISize
are sometimes compiled by recent gcc/clang in the opposite order, viz
[!]usingFlexBasisForISize && isFlexItem. In this case the transformation is
correct as can be seen by analysing code earlier in these functions.
Unfortunately this causes Valgrind/Memcheck to report a branch on undefined
data which, in this case, is a false positive.
A simple fix is simply to initialise usingFlexBasisForISize to false at its
declaration point.
--HG--
extra : rebase_source : 39877e4ea8ec678288e6b49af120445c96ef8c0a
This patch doesn't affect behavior; it just adjusts a variable for clarity.
Really, this variable tracks which axis (inline vs. block) is the main axis (if
we're a flex item). So, this patch morphs the variable to more directly track
that.
The variable's old name 'usingFlexBasisForISize' was confusing, because even
when it was set to 'true', we might not *really* be using the flex-basis in
place of the ISize property. In particular: when we have 'flex-basis:auto', we
don't use 'flex-basis' in place of the ISize/BSize property -- rather, that
indicates that 'flex-basis' is *deferring* to the main-axis size property.
Hopefully the new name/type makes it clearer what we're actually tracking.
MozReview-Commit-ID: ITkb4zuEwgQ
--HG--
extra : rebase_source : 99ebae4e7f6bb87c8001ca589db5e4f375344da3
This patch doesn't affect behavior - it's just refactoring / de-duplicating.
(The refactored function does include some new "legacy box" code, just for
completeness & to ensure that the included assertion passes. But beyond the
assertion, that new code isn't exercised right now -- this function's only
callsites are skipped if the NS_STATE_FLEX_IS_EMULATING_LEGACY_BOX state-bit is
set on the container. Hence, this patch still doesn't affect behavior, even
though it's adding some new logic in the refactored-out function.)
MozReview-Commit-ID: G5aCzwTwkTa
--HG--
extra : rebase_source : 695a2341074b1c344a1c5831989b95a693e16970
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
The DOMMatrix.cpp changes are because it was sneaking in headers via another
unified file.
MozReview-Commit-ID: GPp9WOywI5D
--HG--
rename : dom/base/nsGenericDOMDataNode.cpp => dom/base/CharacterData.cpp
rename : dom/base/nsGenericDOMDataNode.h => dom/base/CharacterData.h
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
Also, fix a bug when copying back the planned limits after
updating it for the first span group. It should only copy
back track sizes that were actaully spanned by those items,
other content-sized tracks' limits should remain at "infinity".
If an image container is empty, it will not produce an image key for use
with WebRender. This is generally not a sign of failure because the
producer likely has yet to populate the container with data. As such, we
should not immediately attempt to fallback. In fact, fallback can make
things worse in this situation, as we will create an image client to
send over the data, but then find that there is no data to share (or
find that there is, due to a race with the producer thread, and use
image clients when we could use shared surfaces).
Unfortunately this means that we need to export a couple more headers, but that
should be ok.
In particular, we have to export some headers that are #included by
nsCSSFrameConstructor.h, because nsCSSFrameConstructor.h itself will now be
included in more places outside of layout/, by .cpp files that don't necessarily
have the ability to indirectly #include its other headers, unless we export
them.
MozReview-Commit-ID: 2n9KHW6Yjrd
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
-Wmissing-prototypes is a new optional warning available in clang ToT. It warns about global functions that have no previous function declaration (e.g. from an #included header file). These functions can probably be made static (allowing the compiler to better optimize them) or they may be unused.
Confusingly, clang's -Wmissing-prototypes is equivalent to gcc's -Wmissing-declarations, not gcc's -Wmissing-prototypes. A function prototype is a function declaration that specifies the function's argument types. C++ requires that all function declarations specify their argument types, but C does not. As such, gcc's -Wmissing-prototypes is a C-only warning about C functions that have no previous function *prototypes* (with argument types), even if a previous function *declaration* (without argument types) was seen.
MozReview-Commit-ID: FGKVLzeQ2oK
--HG--
extra : rebase_source : 81e62163bf41a5d5dd87abf5397e6e8c62ed4096
extra : source : 653a9fc279e2f6a6d066474a94a70d65ac703d6b
Because the scrollable parent might be transformed by its ancestors.
MozReview-Commit-ID: FuCPLg54z7h
--HG--
extra : rebase_source : 7c11c5384d2aed6c663b915fcacae7c627052a43
Some included headers for source code in layout directory are left unused. This
patch merely removes these redundant headers. All of these headers are still
found in use for other code, so all of them and their related cpp files are kept
still.
MozReview-Commit-ID: KCleuWyOV8Z
--HG--
extra : rebase_source : 6e892dcd8ad8c1f56069d4d93bc7124641361232
When sizing the container under a min- or max-content constraint,
the item's min/max-content contribution needs to be clamped (when
Automatic Minimum Size / clamping applies) if its size is 'auto'.
That'll give the container the right intrinsic size. In Reflow,
we'll size the track initially to the clamped min-content
contribution again (in the Resolve Intrinsic Track Sizes step),
but since the container now has a definite size we'll grow
the track in the Maximize Tracks step up to its limit
(i.e. the clamp size).
For more details on the underlying issue, see:
https://github.com/w3c/csswg-drafts/issues/2303
At this point in the series:
- AxisOrientationTracker::IsCrossAxisHorizontal() has zero callers, so it can
be deleted.
- AxisOrientationTracker::IsMainAxisHorizontal() only has two callers, and
both are inside its own class. So it's effectively become an implementation
detail of its class, and it can be made private. (I'm not entirely removing
it, because it does make its two callers more readable. The callers are
working with a physical-axis-dependent type, 'LayoutDeviceIntSize', which
comes from an API that isn't logical-axis-friendly, "GetMinimumWidgetSize",
so they're not easily logicalized. So: it's nice to keep
IsMainAxisHorizontal() around as an internal convenience method to tell us
whether to extract the width or height inside of these two specific
methods. But we don't want to introduce more callers, so let's leave it
around & make it private.)
MozReview-Commit-ID: 1iz1e52NmxV
--HG--
extra : rebase_source : e8e92bbaadb5b8e636bd1dda79cb0041ce36a2ea
This patch doesn't affect behavior. Each of these macros only had one caller
remaining, and this patch simply expands each of these macros at its sole
callsite.
Note that I'm using the "IsMainAxisHorizontal()" helper in *both* expansions
here, which makes the alternative variant "IsCrossAxisHorizontal()" unused as
of this patch. The next patch in this series will remove that now-unused
method, which will reduce the "Horizontal"-querying API surface here.
The documentation for the macros is still relevant to their still-existing
"_LOGICAL" variants (and those variants do still have callers), so I'm updating
the documentation to be about those variants.
MozReview-Commit-ID: 5i32VYXzo3r
--HG--
extra : rebase_source : 4697e6c23ea743e6b928b091c9dfc9ca1ce4c403
This patch doesn't change behavior.
The GET_MAIN_COMPONENT macro (some of whose calls I'm removing here) makes a
call to IsMainAxisHorizontal() under the hood. So I want to get rid of calls
to this this macro, to get closer to killing that method.
In this code, we're interested in the flex item's min-size property in the flex
container's main axis. This patch makes us simply use MinISize/MinBSize (in
terms of the *flex container's* writing mode) to get the appropriate min-size
property. The call to IsRowOriented() (querying the flex container's
"flex-direction" property) tells us whether the inline or block axis is the
main axis.
This patch also does away with an unnecessary axis-specific 'overflow-{x/y}'
check, which we don't need to bother with, as noted in a new code-comment (due
to how the 'overflow' subproperties influence each other).
MozReview-Commit-ID: Kqyh69W5IQJ
--HG--
extra : rebase_source : 92d20c8b607d9526c19f387258248388d1c89d85
This patch doesn't affect behavior. It does the following:
- Changes the AxisOrientationTracker "GetMainComponent/GetCrossComponent" APIs
to take a LogicalSize rather than a nsSize.
- Changes FlexItem::mIntrinsicRatio to be a LogicalSize rather than a nsSize.
- Simplifies the MainSizeFromAspectRatio() helper-function (in particular, it
removes a call to IsCrossAxisHorizontal(), which is an API I'm gradually
removing in this patch series.)
MozReview-Commit-ID: KXUmaUVPMZa
--HG--
extra : rebase_source : 345e95978a8abd3ed3ab5b8acabbc6f163785f63
This patch doesn't change our behavior -- not in opt builds, at least. In debug
builds, this patch does change an assertion condition, to remove a usage of
IsCrossAxisHorizontal(). This means debug builds may proceed a bit further
when loading e.g. bug 1384266's testcase (which up until now was tripping this
assertion). Now that testcase fails a slighlty later assertion (which I'll
sort out on that bug).
The first hunk of this patch is just a simplification -- replacing a
complicated condition (IsRowOriented==IsOrthogonalTo) with a simpler
formulation of the same condition. I'm making that simplification in this
patch so that we're more clearly consistent about what condition we depend on
for baseline alignment. After this patch, that (simplified) condition matches
the condition that we assert inside of GetBaselineOffsetFromOuterCrossEdge().
Note: I'm adding two XXXdholbert comments in this patch, for outstanding issues
that I ran across which are out-of-scope for this patch series.
MozReview-Commit-ID: 5x5xqWWilQZ
--HG--
extra : rebase_source : b25e8bfd7425f76b9784df0bd60fc454d4089347
This patch doesn't affect behavior.
It removes a helper-function that simply returned nsStylePosition::mWidth or
mHeight -- whichever was in the flex container's cross axis. This helper was
only used to answer the question "is the cross size 'auto'", at a single
callsite. So, this patch replaces the helper with a new helper that more
directly answers that question. The new helper's implementation uses logical
axes for its reasoning, too, whereas the removed one used physical axes (and in
particular, it relied on AxisOrientationTracker::IsCrossAxisHorizontal(), which
I'll be getting rid of later in this patch series).
MozReview-Commit-ID: EJ8MObTauZH
--HG--
extra : rebase_source : 74caa7a1d06a2a9c5113d4e3cfabaa1d0e9ec1ab
This patch mostly[1] doesn't affect behavior. It just changes some ReflowInput
width/height-setting logic to use ISize/BSize setters instead of width/height
setters.
To help with this, I'm also adding some more getters to answer the question "is
this flex item's {inline,block} axis the same as the flex container's
{main,cross} axis", for convenience/readability at callsites. (All of these
getters are simply giving a different view of the same underlying single bit of
information.)
[1] One way this patch *kind of* affects behavior: it generalizes the
conditions under which we set the NS_FRAME_CONTAINS_RELATIVE_BSIZE flag on a
flex item. But that doesn't actually have any user-visible effects right now,
because that flag's only purpose is to determine whether we should reflow, and
currently we always reflow all flex items. If/when that changes, though
(i.e. when we start reflowing flex items more selectively), this patch is
adding a reftest that may test this generalized behavior. (The reftest actually
trivially passes right now, due to unrelated bug 1441348.)
MozReview-Commit-ID: 4NEKLBAjowh
--HG--
rename : layout/reftests/flexbox/flexbox-resizeviewport-1-helper.html => layout/reftests/flexbox/flexbox-resizeviewport-2-helper.html
rename : layout/reftests/flexbox/flexbox-resizeviewport-1-ref.xhtml => layout/reftests/flexbox/flexbox-resizeviewport-2-ref.xhtml
rename : layout/reftests/flexbox/flexbox-resizeviewport-1.xhtml => layout/reftests/flexbox/flexbox-resizeviewport-2.xhtml
extra : rebase_source : c6535e1cdcb1757a16cd02e0d485638827344c23
This patch doesn't affect behavior. It just replaces some (correct) physical-axis-dependent code with equivalent logical-axis-dependent code.
MozReview-Commit-ID: 27QJU2cFWh
--HG--
extra : rebase_source : 856e90428468aac0d93854a0bc20e78c2dcb8c57
This patch doesn't change behavior. It just makes us use logical axes/types instead of physical ones for this particular API and its caller.
MozReview-Commit-ID: Jt6SECGI9EU
--HG--
extra : rebase_source : 60d7e52ed9a53f0c0d3ebf3103cbdab476606ddb
This patch doesn't change behavior. It's purely to allow the next patch to be more surgical. Specifically, this patch:
- splits a subtract-and-clamp operation into two separate operations.
- splits one a comment into two.
...so that the next patch can swap out these variables for new ones, without
pushing these lines over 80 characters.
MozReview-Commit-ID: 4N5sI755CqF
--HG--
extra : rebase_source : 96af106d739256a6871e75d0d34e9691cfbfb0c2
Poking at the frame tree has problems: If we poke in negative (using
eSkipNativeAnonymousContent), as we were doing, we mess up the case where we're
actually _not_ doc-level, and _not_ ::before or ::after. This can't happen for
content documents, but can happen for chrome (since nsDocElementBoxFrame
implements nsIAnonymousContentCreator).
If we poke in positive, as we used to, you get that right, but mess up the
root scrollbar case.
Instead, use a node property to mark doc level anon content. This is a case rare
enough that it seems worth to not steal a node bit.
To recap the failure:
* The initial value of -moz-control-character-visiblity is different on beta
and nightly.
* XUL has a global rule setting -moz-control-character-visibility on the root,
to a value so that it's the initial one on nightly, but the non-initial one
on beta.
* Changes to this property cause a reframe.
* Reframes of a nsIAnonymousContentCreator anon content reframe the container.
* We were failing to inherit correctly for the nsIAnonymousContentCreator
content for the root XUL element on the initial styling, inheriting from the
default computed values instead, since we failed to reach the root element's
primary frame from GetFlattenedTreeParentForDocumentElementNAC ->
AppendDocumentLevelNativeAnonymousContentTo, since the primary frame is set
_after_ processing children.
This seems somewhat risky to change, and inconsistent with any other stuff
the frame constructor does, see bug 973390.
* Given that, the next restyle of the root element, in this case caused due to
the customizable UI, we _found_ the actual correct parent, recomputed the
style, saw that -moz-control-character-visiblity had changed, and reframed.
But we were reframing the whole window, not just the NAC, because of the
fourth bullet point. Reframing the whole window caused us to lose the popup
state (that's bug 1440506).
Worse than that is the fact that given we reframe and reconstruct the
anonymous countent again, we go back to the initial bogus state, just
awaiting for the next restyle to reframe the whole window.
I wish there was a bullet-proof way to test it that isn't just counting reframes
and relying on which properties reframe or not, but due to the nature of
nsIAnonymousContentCreator's NAC, it's not possible in any easy way I can think
of.
MozReview-Commit-ID: IPYB5trsN8R
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : e56505706bb2799b59bbfb3bbcce4a9ce86892f4
This patch makes a bunch of tests start passing, so it removes some 'fails' annotations.
MozReview-Commit-ID: DCxkXFnztLc
--HG--
extra : rebase_source : 53f4d38c0bf8915fc420f971ba36f4c0ad7aa8ed
This patch doesn't change behavior; it's simply a rename.
I'm also fixing one mistyped mention of this variable in a comment in
nsFlexContainerFrame.cpp. (The comment had "Reflow" rather than "Height" in
its mention of this variable-name.)
MozReview-Commit-ID: KRW7FCVSlto
--HG--
extra : rebase_source : 2a27ea3bf9d3eabc437db398d24e374ce48ba677
In particlar, this patch:
- ...renames a bunch of 'auto'-BSize-measurement functions/variables from
"Height" to "BSize". (I thought about splitting this part out, but
typically the correctness of the renames was intrinsically tied to the logic
generalizations that I'm performing here, and vice versa, so it seemed
clearest to group it all together.)
- ...replaces some calls to IsMainAxisHorizontal() with the more general
"FlexItem::IsInlineAxisMainAxis()" API, for cases when we're reasoning about
whether a flex item's main-size is really just its (easier-to-resolve) ISize.
- ...replaces some calls to IsCrossAxisHorizontal() with either
IsColumnOriented() or FlexItem::IsInlineAxisCrossAxis() (depending on
whether we're reasoning about the flex container's cross-size vs. a flex
item's cross size).
This makes a bunch of tests start passing (including a "received" w3c
reftest/wpt-test), so this patch also removes some failure annotations.
MozReview-Commit-ID: 3uR1mOzvytX
--HG--
extra : rebase_source : 40f4e7dd6aacfb4f267d2f4d217fbf84befb5ebf
This patch doesn't affect behavior -- it's just adding a new member-var &
accessor with no usages. The next patch in the series will add some usages.
MozReview-Commit-ID: NKBvKnb7Jw
--HG--
extra : rebase_source : aff89907bfef41a8fa3ff076264a2b7a72c36e27
This patch doesn't affect behavior. It simply reorders a member variable to be
near the beginning of the FlexItem class, so that the next patch in this series
can use that member-variable when initializing another member in the
constructor init list. (You're only allowed to use earlier member-vars like
this, since member-vars get initialized in order.)
MozReview-Commit-ID: 9v4Dr0Ir6i7
--HG--
extra : rebase_source : ff0ebd63c4a88017e8211a77049e79469b4e9858
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
Bogdan Tara
Boris Zbarsky
Jonathan Watt
Coroiu Cristina
Henri Sivonen
Ryan VanderMeulen
Xidorn Quan
Emilio Cobos Álvarez
Matt Woodrow
Narcis Beleuzu
shindli
Mats Palmgren
Noemi Erli
Andreea Pavel
arthur.iakab
Miko Mynttinen
Timothy Guan-tin Chien
Ryan Hunt
Cosmin Sabou
Adrian Wielgosik
Julian Seward
Daniel Holbert
Jeff Muizelaar
Gurzau Raul
Sylvestre Ledru
Andrew Osmond
David Major
Botond Ballo
Chris Peterson
Jonathan Kew
Hiroyuki Ikezoe
Ciure Andrei
Zhang Junzhi
Sebastian Hengst
Tiberius Oros
Florian Quèze
Nathan Froyd
Dorel Luca
Masayuki Nakano
Bas Schouten
Alexis Beingessner
Margareta Eliza Balazs
Jamie Nicol
Csoregi Natalia
Andrew McCreight
Jet Villegas
Cameron McCormack
Jan Henning
abhinav
ben.tian@gmail.com
Timothy Nikkel
L. David Baron
Andrea Marchesini