D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
I did this instead of just (ab)using the fact that every list item has at least
one counter-increment node because:
* I don't have the bullet frame around by the time we initially compute the
counter increment, which means that I'd need to grow nsBlockFrame / add a
frame property for the list item ordinal, which I think would be unfortunate.
* It feels more consistent with the way regular CSS counters work and with the
way we want ::marker to eventually work.
Differential Revision: https://phabricator.services.mozilla.com/D31990
We always include the combinator for pseudo-elements now (not including it was
just an optimization) in order to not match when nested pseudo-elements are
involved.
We could add a more generic check in `matches_simple_selector` like:
```
if element.is_pseudo_element() {
match *selector {
Component::PseudoElement(..) |
Component::NonTSPseudoClass(..) => {},
_ => return false,
}
}
```
But even that wouldn't be enough to make selectors like `:hover::marker` not
match on the `::before::marker` pseudo-element, plus that code is really hot.
So for now do the check on the `next_element_for_combinator` function. It's a
bit hacky but it's the best I could came up with...
While at it, simplify some checks to use is_pseudo_element() instead of
implemented_pseudo_element() directly.
Only the Rust patch as-is would make markers for ::before and ::after on list
items not show up, so we also need to switch ::marker to use ProbeMarkerStyle()
rather than ProbePseudoElementStyle(), since the marker should exist even if it
matches no rules.
Differential Revision: https://phabricator.services.mozilla.com/D27529
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
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
This patch makes accessible module use `mozilla::PresShell` directly rather
than via `nsIPresShell`. Additionally, renames `DocAccessible::PresShell()`
to `DocAccessible::PresShellPtr()` for avoiding conflict with using
`PresShell` in it and its sub classes.
Differential Revision: https://phabricator.services.mozilla.com/D26663
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
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
This patch is a mechanical replacement without any reparent, i.e.
passing nullptr as parent into nsFrameList::AppendFrame().
Differential Revision: https://phabricator.services.mozilla.com/D25337
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
We need to pull outerFrame one level up to the outer scope because it's
needed when calling FinishBuildingColumns().
The patch is very similar to implementing column-span:all for <fieldset>
in bug 1535200.
Differential Revision: https://phabricator.services.mozilla.com/D24396
After supporting column-span, the top-level container for multicol
layout is no longer the ColumnSetFrame, so remove the "SET" suffix from
FCDATA_ALLOW_GRID_FLEX_COLUMNSET bit to make it sound more general.
Also, update the document and add an assertion.
Differential Revision: https://phabricator.services.mozilla.com/D24394
Per spec, "Note: Column boxes do not become the containing block for
elements with position: fixed or position: absolute. The containing
block is the multicol container, it being the principal box."
https://drafts.csswg.org/css-multicol-1/#the-multi-column-model
contentFrame and contentFrameTop are different only if fieldset has
multicol layout. In that case, contentFrameTop is nsColumnSetFrame (or
ColumnSetWrapperFrame after applying Part 2 with
layout.css.column-span.enabled=true).
Differential Revision: https://phabricator.services.mozilla.com/D23617
The test case triggers MOZ_ASSERT(!IsFramePartOfIBSplit(aParentFrame))
in MaybeRecreateForColumnSpan() because WipeContainingBlock() returns
early when the FrameConstructionItemList is empty. Thus, it doesn't wipe
the aParentFrame even if it's part of an IB split.
An empty FrameConstructionItemList constructs no frames. Therefore,
MaybeRecreateForColumnSpan() doesn't need to do anything if aFrameList is empty
since an empty frame list cannot contain any column-span.
Differential Revision: https://phabricator.services.mozilla.com/D23820
The assertion can be reproduced locally by running
"./mach test dom/canvas/test/chrome/test_drawWindow_widget_layers.html"
with layout.accessiblecaret.enabled=true.
When AccessibleCaret is enabled, caret elements will be inserted into
nsCanvasFrame::mCustomContentContainer, thus it recursively invokes
ConstructFramesFromItemList() to construct frames for carets before it had a
chance to construct popup group.
I feel it's too strict to assume that ConstructFramesFromItemList() cannot be
invoke recursively whenever there's a popup group item. I move the assertion to
the end of ConstructDocElementFrame() to ensure the popup group is processed by
then.
Differential Revision: https://phabricator.services.mozilla.com/D10298
