Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
In order to get rid of nsFrameItems::AddChild() and use
nsFrameList::AppendFrame() instead, we need to keep table captions'
parent to be nsTableFrame when they're created (no adjust in
ConstructFramesFromItem) so that their parent remain the same as other
frames in the table when appending into the temporary aFrameItems.
We then adjust captions' parent right before we call
SetInitialChildList()/AppendFrames/InsertFrames().
Also, pass nullptr to AppendFrames() in
nsTableWrapperFrame::AppendFrames() because callers should already set
captions' parent frame properly. No need to reparent them again.
Differential Revision: https://phabricator.services.mozilla.com/D25335
--HG--
extra : moz-landing-system : lando
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
Really sorry for the size of the patch :(
Only intentional behavior change is in the uses of HasLengthAndPercentage(),
where it's easier to do the right thing. The checks that used to check for
(IsCalcUnit() && CalcHasPercentage()) are wrong since bug 957915.
Differential Revision: https://phabricator.services.mozilla.com/D19553
After this I can pass the document from the caller to ResolveSameStructsAs, and
get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to
ResolveSameStructsAs, and get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
Bug 1509717 removed Gecko's definition of StyleBorderStyle to use the Rust one.
The Rust version was ordered in a different way, and the table code relied on
the order in order to build the mapping for border conflict resolution.
Simplify this mapping now that border constants are ordered in terms of
priority, see the comment on top of `enum BorderStyle`.
Differential Revision: https://phabricator.services.mozilla.com/D16565
--HG--
extra : moz-landing-system : lando
This patch makes us handle calc with percentages when we can convert to
percentages the same way we handle plain percentages in table layout.
We still treat length + percentage as auto (this matches Blink / WebKit as
well). There's one case we differ with Blink / WebKit, which is calc(% + 0px),
which they'd treat as auto instead of a percentage.
I think this is a bug on them (or at least worth some spec clarification). I
filed https://github.com/w3c/csswg-drafts/issues/3482 for that.
In practice what that'd means for us if the WG decides that Blink / WebKit is
right in that case is that we'd need to keep track of whether the calc()
specifies lengths, and return false from ConvertsToPercent if so.
In any case, nothing that would massively change this patch, and I think enough
of an edge case that is not worth blocking on the CSSWG decision here. Though I
could be convinced otherwise of course.
Differential Revision: https://phabricator.services.mozilla.com/D15719
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
All of the removed includes are redundant (i.e. they're #included elsewhere in
the same file).
In most cases, I'm removing the second (redundant) copy of the
#include, except when that copy makes more sense (i.e. if it's in better sorted
order, or if it's paired alongside a closely-associated header while the
earlier copy is not).
Here's the script that I used to generate candidates here -- I ran this in
every subdirectory of layout, on my linux machine (warning, this writes two
files to your /tmp directory):
for FILE in *.h *.cpp; do
nonunique=$(grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | wc -l)
unique=$( grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq | wc -l)
if [[ "$unique" != "$nonunique" ]]; then
echo "$FILE: $nonunique / $unique"
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort > /tmp/nonunique.txt
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq > /tmp/unique.txt
diff /tmp/nonunique.txt /tmp/unique.txt
echo
fi
done
Depends on D13773
Differential Revision: https://phabricator.services.mozilla.com/D13774
--HG--
extra : moz-landing-system : lando
Converted NS_STYLE_BORDER_STYLE_* consts to enum class. Updated corresponding values to enum class. reduced BCCornerInfo struct values to fit StyleBorderStyle values inside struct. Added defaults to switches that do not fully cover all instances of StyleBorderStyle.
Unfortunately, accepting all BCBorderOwner enum values causes the layout/reftests/table-bordercollapse/frame_above_rules_all.html mochitest to fail. To fix the -Wbitfield-enum-conversion warnings without breaking the test, this patch explicitly masks the BCBorderOwner enum values to preserve the previous implicit truncation. I filed follow-up bug 1508921 to remove this workaround and fix the test.
This enum truncation was reported by clang's -Wbitfield-enum-conversion warnings:
layout/tables/nsTableFrame.cpp:5318:14 [-Wbitfield-enum-conversion] bit-field 'ownerElem' is not wide enough to store all enumerators of 'BCBorderOwner'
layout/tables/nsTableFrame.cpp:5358:16 [-Wbitfield-enum-conversion] bit-field 'ownerElem' is not wide enough to store all enumerators of 'BCBorderOwner'
layout/tables/nsTableFrame.cpp:5374:18 [-Wbitfield-enum-conversion] bit-field 'subElem' is not wide enough to store all enumerators of 'BCBorderOwner'
layout/tables/nsTableFrame.cpp:5385:18 [-Wbitfield-enum-conversion] bit-field 'subElem' is not wide enough to store all enumerators of 'BCBorderOwner'
Differential Revision: https://phabricator.services.mozilla.com/D12382
--HG--
extra : rebase_source : 74c1c3d49e84212ba61c0784f669cadb19f2b4cd
extra : intermediate-source : 2336858d1df479b16e096a9bb5f8eea5008ca9ea
extra : source : 4ab689fc9a368a4c6faaf71169eb72fdc9bb249d
The value of BORDER_STYLE_UNSET will change in patch part 2 when we must shrink the sentinel value from 0xFF to 0xF to fit in the new 4-bit style bit fields.
Differential Revision: https://phabricator.services.mozilla.com/D12381
--HG--
extra : rebase_source : 5d1d27335a4e6219225649c1c6dbecb6ad5b9804
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
--HG--
extra : source : 803b224d52a0940b4fb4b3b9cffc6a1fa6e5d4ee
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Currently, GetSplittableType() is called only in
nsCSSFrameConstructor::CreateContinuingFrame(). The splittable concrete frames
should inherit from nsSplittableFrame, and must explicitly create continuing
frame in CreateContinuingFrame(). Thus, no need to maintain GetSplittableType().
Differential Revision: https://phabricator.services.mozilla.com/D10798
--HG--
extra : moz-landing-system : lando
This patch isn't expected to change behavior; it's just some simplification.
Differential Revision: https://phabricator.services.mozilla.com/D6976
--HG--
extra : moz-landing-system : lando
See the discussion in https://github.com/servo/webrender/issues/1280. I think we
should do this sooner rather than later.
Need to update a couple reftests to hardcode the new colors, waiting on try for
that but should be trivial.
This makes a few more tests pass which are just marked as failure in bug 1487407,
because I implementing the border-collapsing reusing a bunch of Gecko code,
including the table 3d border stuff.
Differential Revision: https://phabricator.services.mozilla.com/D6565
The previous border-collapse beveling implementation assumed that there would
only be one beveled border per side in the whole table, which is... not true at all.
So a bunch of borders ended up clobbering other values in mBevelBorders and
never getting painted.
I'm actually somewhat scarily surprised that only this reftest seems to fail
without this patch...
Here we reuse most of the existing one-off beveling / border rendering support
in nsCSSRendering, and convert the Gecko bevels into a WebRender display list
using rects and borders. This is only remotely possible thanks to Gecko not
supporting dotted / dashed beveled borders :)
This would slightly easier and presumably also more efficient with a triangle
display item in WR instead of (ab)using the border display item to render the
bevel, but this is probably relatively edge-casey so maybe not worth it... In
any case I've left a TODO comment there, that can be a nice followup if we deem
it worth it.
Anyway, I'm _so_ sorry for the border trick, I was this (||) close to go and
rewrite our border collapsing code, but after a few tries I realized it'd take
me a whole lot of time (instead of the day that this has taken me).
Differential Revision: https://phabricator.services.mozilla.com/D4793
Bug 895096 comment 0 recommends using the name `d2a` instead of `p2t`.
Depends on D5368
Differential Revision: https://phabricator.services.mozilla.com/D5369
--HG--
extra : moz-landing-system : lando
This is needed for patch 4.
This is based both on the wording in the spec and the discussion in
https://github.com/w3c/csswg-drafts/issues/2987, and also doesn't
support them for nsMathMLContainerFrame, which is similar to inlines and
ruby.
Differential Revision: https://phabricator.services.mozilla.com/D2815
--HG--
extra : rebase_source : b7e23fb248fa34957ca2d539134e872f5a03f5a8
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
An ancient comment from 1998 assures us that GetRect is wrong if there are captions.
The painting code instead uses mVisibleRect which appears to be correct.
MozReview-Commit-ID: 6Lax4sjInJu
--HG--
extra : rebase_source : 79dd527173443fba8d0718c581852d7bfcc47a3c
This is needed only for CSS Grid since in other cases we're
only using IntrinsicISizeOffsets in the inline-axis and
the percentage basis is always indefinite for *intrinsic
sizing*. When calculating the intrinsic size of grid items
in the grid container's block axis however, we do have
a definite size for the grid area in the inline-axis and it
should be used per:
https://drafts.csswg.org/css-grid/#algo-overview
"2. Next, the track sizing algorithm resolves the sizes of
the grid rows, using the grid column sizes calculated in
the previous step."
(Percentage padding/margin for grid items is always resolved
against the grid area's inline-size nowadays.)
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 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
