Move ApplyOpacity(), CanApplyOpacity(), Paint() and PaintWithClip() methods to nsPaintedDisplayItem
Differential Revision: https://phabricator.services.mozilla.com/D30225
--HG--
extra : moz-landing-system : lando
They do nothing, if they get parsed, they end up doing the same as text-align:
start, which is the same that we'd get out of GetLogicalAlign if the attribute
wasn't parsed in the first place.
We don't use this attribute for anything else like attribute mapping, so this
should be an idempotent patch.
Differential Revision: https://phabricator.services.mozilla.com/D29360
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--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
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
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
When generating display lists for WebRender, we were not caching the
draw result via nsDisplayItemGenericImageGeometry::UpdateDrawResult (or
similar) after completing CreateWebRenderCommands. This is important
because reftests use this to force sync decoding for images; it may be a
reason for image-related intermittent failures on *-qr builds.
Additionally, we may have been requesting fallback in cases where fallback
could not do anything more than WebRender could. For example, if we can't
get an image container yet, there is no point in requesting fallback
because it might just be we haven't started decoding yet. We should just
return the actual draw result in such cases.
All classes deriving from nsIFrame that did not have any subclasses themselves
(at the time of writing this patch) have been marked with `final`.
Some other Layout classes have also been made final, but this was opportunistic
while working on nsIFrame subclasses, and is definitely not exhaustive, further
patches welcome; refer to bug 1332680.
Advantages of marking a class final include:
- Allowing the compiler to devirtualize some method calls (i.e., calling
virtual functions directly instead of going through the vtable),
- Indicating that the class is not currently subclassed,
- Preventing subclassing without being aware that this would remove the
finalization benefits of the parent class.
`final` does not signify that these classes should *never* be subclassed, this
is left for developers to decide.
Differential Revision: https://phabricator.services.mozilla.com/D5020
--HG--
extra : moz-landing-system : lando
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
Falls back if a legend is present, as this is blocked on upstream
webrender exposing ClipMode.
MozReview-Commit-ID: At8kX4vQn3X
--HG--
extra : rebase_source : 310352d6d9a82f748250fa0c45f4e2f53859e6ea
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
--HG--
extra : rebase_source : e1fe6a775ad97e16a6d7cc224634ff962ccb0fbf
