windows.h isn't directly included by nsImageFrame.cpp, but it may be pulled in via unified builds.
Landing on a CLOSED TREE to fix bustage.
MozReview-Commit-ID: 7QiM57dpYAd
Right now, there's only one flag in this new class (with no usages until a
later patch). This flag suppresses a hack, which otherwise makes us
transparently reverse the child list & flex axes in some circumstances, to
prevent bottom-to-top child ordering. (We don't want that hack when we're
dealing with individual abspos children, since it only makes things more
complicated.)
MozReview-Commit-ID: HYUf0vjlfiJ
Right now, this method has only one stub impl, in nsContainerFrame; a later
patch will add a more interesting (overriding) impl in nsFlexContainerFrame.
MozReview-Commit-ID: 3U3vTTX4vdm
This patch also:
* Removes some now-unnecessary code from nsFlexContainerFrame, which was for jumping from wrapped-placeholders to their out-of-flow frames (for DOM comparisons). This code is now unnecessary because placeholders won't be wrapped anymore.
* Updates some reftests with abspos content to match the updated spec's expectations, with one marked as "fails" for the time being (until bug 1269046 implements css box alignment, which we need to render that test correctly).
MozReview-Commit-ID: 8canWfXk6Kf
This patch makes the following specific changes:
(1) Adds an early-return to both versions of the IsOrderLEQ function, to treat placeholder children as LEQ everything (including each other). This will tend to sort them to the beginning of the child list, which is unimportant but fine. More importantly, though: this means our "order"-sorting code won't reorder placeholders *with respect to each other* (since our sort algorithm is stable). So their painting order won't be affected by the "order" property, which is required by the spec.
(2) Drops some nsPlaceholderFrame::GetRealFrameFor() calls -- they're unnecessary, since any placeholder frames will have prompted us to return earlier.
One caveat to (2): this patch does leave a few "nsPlaceholderFrame::GetRealFrameFor()" calls in place, *for the moment*. These remaining calls are for handling placeholders that are wrapped, i.e. inside of anonymous flex items. These calls are still needed to avoid assertion-failures (i.e. to get a consistent ordering) at this point, but they'll be removed in a later patch in this same bug, when we stop wrapping placeholders in anonymous flex items.
MozReview-Commit-ID: 1R6NW30Kxgv
This shouldn't change our behavior right now, but it will make a difference
after bug 1269045 -- when that bug lands, we'll have nsPlaceholderFrames (which
are not flex items) in the child-frame list, which means we can't depend on its
first entry being a flex item anymore.
MozReview-Commit-ID: KRXYaK8R8bc
This removes a (very minor) optimization. The optimization was simply that we
avoided storing this nscoord value, if we could tell that we weren't ever going
to need it. Now it's becoming a bit more complicated to prove that we'll never
need it, so we might as well just store it unconditionally.
MozReview-Commit-ID: 94FFc9SO516
We might miss this while introducing writing-mode APIs to nsLineLayout in
Bug 789096.
MozReview-Commit-ID: IrW8fEXbM2s
--HG--
extra : rebase_source : c856309ae1539060e54d9c717f9cab3de3f090af
1. frame was mis-renamed to mFrame in Bug 1277129.
2. frameWM should've been removed in Bug 1094914.
MozReview-Commit-ID: qMv6L2vbrV
--HG--
extra : rebase_source : e6dcfef4cd53ab7cb0920d56074623204001b83a
1. Rename these functions to agree with Mozilla coding style.
2. Use singular naming instead of plural naming since each of these functions
returns an iterator pointing to a singular line.
3. Rename line() and rline() to BeginLineFrom() and RBeginLineFrom(), which
shall improve the readability.
MozReview-Commit-ID: txZjVnv9Yb
--HG--
extra : rebase_source : b4dae99ab7bf751bd9974616f8f8e6dfe6248fc2
This makes background-image, mask-image and border-image settable
from Servo.
Since imgRequestProxy resolution in nsStyleImages can now happen later than
at computed value setting time, and that resolution can fail,
nsStyleImage::GetImageData() might now return null. So all of the users of
nsStyleImage now null check its result.
MozReview-Commit-ID: FMRUrC3SfOs
This patch adds a pref to control whether we dispatch the selection
events for changes in the contents of input and textarea text controls.
The spec for this feature hasn't been written yet, and we need to exclude
this part of the selection API from the part we want to ship.
If, within a single refresh driver tick, the scroll position is updated by JS
explicitly, and then subsequently also updated by a frame reconstruction, the
scroll origin from the former (nsGkAtoms::other) can get clobbered by the latter
(to nsGkAtoms::restore). The restore scroll origin is "weaker" in that it can
be ignored by the APZ code in some circumstances. This is undesirable because
it means the JS scroll update also gets ignored. This patch ensures that when
setting the scroll origin we don't do this clobbering of stronger origins with
weaker origins.
MozReview-Commit-ID: DA4EHp1Debu
--HG--
extra : rebase_source : 99fd1f91698a605792b2a622450f1ff31bc89101
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
--HG--
extra : rebase_source : 835a64e0f9cdaa375f8e57f55ffe5b011525cbeb
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
--HG--
extra : rebase_source : c600a80b96df3c937f2a56a5e0ed1825750234e0
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
MozReview-Commit-ID: AG1Y0IgoB3U
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
Note about no-stacking-context-(opacity|transform)-removing-animation-in-delay.html
Before this patch we don't create any stacking context for animations overridden
by !important rules, but after this patch we do create a stacking context for
such animations. As a result, in the test case we did paint a stacking context
in the first rAF callback and then in the second rAF callback we did clear the
painted stacking context. Unfortunately sometimes the second rAF callback was
called prior to clear the stacking context on the compositor because of
compositor delay. To avoid this situation, we have to wait for MozAfterPaint
instead of rAF callback.
MozReview-Commit-ID: AG1Y0IgoB3U
Since we're converting LineReflowStatus to an enum class, the "default:" branch
of LineReflowStatusToString() could be removed as well. In this way, we can add
protection at compile time (warning) instead of runtime (assertion).
MozReview-Commit-ID: 8Ul0eCxqSTR
--HG--
extra : rebase_source : 81cc36bf1ae566d7114466661b7d0db6d63e364f
This is a pre-patch that uses LineReflowStatusToString() function instead of
LineReflowStatusNames array to support debugging. With this patch, we could
easily regain debugging support from LineReflowStatusToString() while converting
LineReflowStatus to an enum class.
MozReview-Commit-ID: K2AzZ2zI69p
--HG--
extra : rebase_source : bfbb1221ffb59cd4c27c3fb147a3a3b64e86cf68
Change the logic that moves the main summary to the front from operating
on generated frames in DetailsFrame::SetInitialChildList() to operating
on frame construction item list in AddFrameConstructionItemsInternal()
so that it will be correct when cooperating with ::first-line.
The root cause of the bug reported is because when specifying
::first-line on details element, the first frame of summary element,
which is generated due to ib-split, will be wrapped in nsFirstLineFrame.
The original code fails to find the summary frame in the wrapper frame
and triggers assertion because of the second ib-split summary frame. To
fix that, we need to descend into the child list of wrapper frames when
checking the main summary.
Add original test case as a crashtest as well as reftests to clearly
reproduce the issue.
Note that in the reftest, the blue color in ::first-line is applied
incorrectly to the second line in the summary due to bug 520605.
MozReview-Commit-ID: Bv4Vcvxp6pY
KeyframeEffectReadOnly::HasAnimationOfProperty() calls GetAnimationOfProperty()
which checks mWinsInCascade flag and the mWinsInCascade flag is set to true
only if the effect is in-effect.
That means nsLayoutUtils::HasCurrentAnimationOfProperty() actually represents
that a given frame has at least one animation which is current and *in-effect*
(i.e. active).
MozReview-Commit-ID: 93rMMmzrBMi
--HG--
extra : rebase_source : c48167d874aa243ab070d0aa64876307748e3493
(Normally, the style-context parent will *be* the flex container's style
context, so this patch won't change behavior at all. But if a flex container
has a "display:table" child, then there's an extra style context in the
inheritance chain (due to how style inheritance works for nsTableWrapperFrame).
And we don't want that extra style context to mess up the ability of a flex
container's "align-items" property to actually align the flex items.)
MozReview-Commit-ID: GFyxhEwM68S
--HG--
extra : rebase_source : 4be8ac901e10de20747ed44b889d234646d4b2fd
'auto' tracks now also gets an item's min/max-content contribution
(in 2.2/2.3) when sizing under a min/max-content constraint.
(Previously, 'auto' only got the min-size contribution under 2.1)
https://drafts.csswg.org/css-grid/#algo-content
Now it returns the min/max-content contribution for intrinsic sizing.
Otherwise, i.e. during Reflow, return the min-size contribution.
(Previously, it always returned the min-size contribution.)
https://drafts.csswg.org/css-grid/#algo-content
DETAILS ON THE CLEANUP:
* In nsFrameTraversal.cpp:
- Whitespace fix.
- Remove a useless nullptr assignment.
- Use "=" to initialize a nsCOMPtr, per coding style guideline ("initialize variables with nsFoo aFoo = bFoo and not nsFoo aFoo(bFoo)").
* In nsPresShell.cpp:
- Wrap a longish assignment to 2 lines (since next patch will make the first line longer, which would push the whole thing over 80 characters if it weren't wrapped).
- Add braces around "if" body.
* In nsTextFrame.cpp:
- Remove a useless nullptr assignment.
- Move the "metrics->GetThebesFontGroup()" call slightly earlier, so it happens *before* we've implicitly transferred ownership the object pointed to by "metrics".
- Add a code-comment.
MozReview-Commit-ID: LG6vgOmM9MK
--HG--
extra : rebase_source : 7754d4edefb09ae7992275b9dcb7e84371955d9c
Phil Ringnalda
Daniel Holbert
Carsten "Tomcat" Book
Kan-Ru Chen
Adam Velebil
Jeremy Chen
Mantaroh Yoshinaga
Mats Palmgren
Ryan VanderMeulen
Xidorn Quan
Cameron McCormack
Markus Stange
Jorg K
Brad Werth
Botond Ballo
Ehsan Akhgari
L. David Baron
Michael Layzell
Julian Descottes
Kartikaya Gupta
Wes Kocher
cku
Sebastian Hengst
Hiroyuki Ikezoe
Jonathan Kew
Sumit Tiwari
Ting-Yu Lin
Jessica Jong
Alex Henrie
David Keeler
Joel Maher