The removed reftsts test basically the opposite, and are sufficiently
covered by the WPTs that we start passing, so just remove them.
Differential Revision: https://phabricator.services.mozilla.com/D204797
Put all the "is this block a BFC" logic in nsBlockFrame.cpp.
The CLIP_PAGINATED_OVERFLOW flag is also redundant, it can just be "has
non-propagated overflow styles" check in ShouldApplyOverflowClipping(),
and frees another bit.
Shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D203590
In order to create less WebRenderLayerScrollData currently we use a deferred transform item
https://searchfox.org/mozilla-central/rev/593c49fa812ceb4be45fcea7c9e90d15f59edb70/gfx/layers/wr/StackingContextHelper.h#82
We don't need a WebRenderLayerScrollData for every transform because a lot of transforms don't contain any ASRs, so the created WebRenderLayerScrollData would be useless.
However this optimization can lead to us creating a lot more WebRenderLayerScrollData later if the transform does contain ASRs. For example, if there is a transform, and then inside that is a ASR, and inside the ASR is a lot of small transforms, we end up having to create a WebRenderLayerScrollData for every little transform which don't contain any ASRs. This is doing the opposite of what the optimization intended.
WebRenderLayerScrollData creation happens during the CreateWebRenderCommands phase, so the display list build phase is complete, and we can tell cheaply if a transform contains any ASRs during display list building. So we just record that and use that to inform our decision about when to defer the transform item or not.
This optimization drastically reduces the total number of WebRenderLayerScrollData that we create during a full run of speedometer3 (summing the number created each paint over every paint). In my testing it went from 12-13k to 2-3k. Mostly subtests fell into two buckets: a single digit number of WebRenderLayerScrollData to begin with and this patch didn't change that, and 100 WebRenderLayerScrollData down to single digits after this patch. So the savings are concentrated in a few subtests that hit the described behaviour above.
I compared a profile before and after this patch of 10 runs of speedometer3, this patch saved 100 samples/ms serializing WebRenderLayerScrollData, which was what I expected based on how long serialization took before the patch combined with how many WebRenderLayerScrollData we were avoiding. The whole run took about 100,000 samples/ms, so this should hopefully be good for about 0.1% improvment. There is also potential savings in other areas outside of serialization step but that was a little harder to measure.
Differential Revision: https://phabricator.services.mozilla.com/D197446
This comes from the initial content-visibility: auto implementation, and
more crucially before we fixed the timing issues from bug 1807253.
After bug 1807253 we shouldn't get to actually render something without
its initial visibility determined, so this special case can go away.
Differential Revision: https://phabricator.services.mozilla.com/D202723
Even if `<details>` does not have a `<summary>`, it creates a closed shadow DOM
as a UA widget to show the triangle icon and the default summary. Chrome allows
to move select the default summary with this API, but in that case, Chrome sets
`Selection.focusNode` and `Selection.anchorNode` to `undefined`. Therefore,
anyway, moving selection into the default summary is not useful for web apps.
Therefore, I think that we can just avoid to move selection into any native
anonymous subtree for keeping the things simple.
Differential Revision: https://phabricator.services.mozilla.com/D202696
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
We have a pref, `dom.event.contextmenu.shift_suppresses_event`, which is
default to make `Shift` + right click forcibly open the context menu without
dispatching `contextmenu` event to the web.
When user wants to use this feature, they may (or must) assume that it works
as a right click (without `Shift`) except whether it overrides `contextmenu`
event listener of the web app. Therefore, `Selection` should be collapsed
at the click point instead of expanding to the click point.
Unfortunately, we need to consider it at `mousedown`, not `mouseup` nor
`contextmenu`. Therefore, `Shift` state may mismatch with the actual state at
`mouseup` and `mousedown`/`poinerdown` listeners of web apps may assume it will
expand selection, but I think that we cannot solve these issues.
Differential Revision: https://phabricator.services.mozilla.com/D201054
`nsIFrame::GetCursor()` can never return `Nothing()` after bug 1687239, which
removes `nsPluginFrame`. Therefore `mLastFrameConsumedSetCursor` in
`EventStateManager` can never be true.
Differential Revision: https://phabricator.services.mozilla.com/D200890
This is kind of a wallpaper, but I think it's sound, read below.
The reason this is asserting is that MathML in particular has some odd
frame re-parenting going on (see
nsCSSFrameConstructor::FlushAccumulatedBlock).
That means that our assert in DepthOrderedFrameList is not really
holding depending on when you add or remove the frame from the list.
However this is not a problem in practice, at least for container
queries, because anonymous frames that can wrap mathML cannot be
containers themselves.
I need to figure out what to do with that assert, but given it's useful
for the other users of DepthOrderedFrameList, I think we should take
this for now.
Differential Revision: https://phabricator.services.mozilla.com/D200634
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
The padding changes causes some sizes in the child to not exactly be
nscoord_MAX when overflowing, but a slightly smaller value, not hitting
the width == nscoord_MAX || height == nscoord_MAX condition in
FinishStoreOverflow().
The other one is similar, where an nscoord_MAX value gets to bidi
reordering, where it didn't before. It doesn't seem problematic /
anything that wouldn't otherwise happen with a regular block with
padding.
Tweak while at it some of the overflow areas assertions, mostly
to make it simpler, but also because I'm not super-positive about
the compiler being able to optimize it away entirely on opt builds.
Depends on D197978
Differential Revision: https://phabricator.services.mozilla.com/D199241
In bug 1845241, we aligned the behavior of `Selection` at right click to the
other browsers. That may prevent potential web compat issues, but some users
may want to take it back the traditional behavior.
The patch adds a pref to do it only when caret is in an editable element and
when right click occurs in focused editable element. The reason of limiting
only in editable nodes is, collapsed range in non-editable content is not
visible for users unless enabling the caret browsing mode. Therefore, if we
apply the traditional behavior to non-editable content, we'd have bug reports
with this pref and waste time for investigation in some web apps. However,
in editable content, caret shows users and that helps us to understand what
happened in the reporter's environment. Therefore, I think that this pref is
reasonable for some users.
Differential Revision: https://phabricator.services.mozilla.com/D199203
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Right now, we reconstruct frames in response to a change in the CSS
`contain` property or `content-visibility`. This patch tries to optimize
this a bit:
1. Updates involving style containment change continue to force a
reconstruction, due to the need to handle counters/quotes.
2. Updates involving paint/layout containment change only force a
reconstruction if it's needed to handle absolutely/fixed
positioned descendants or floats (for this one, see also bug 1874826).
3. Other containment changes will only force a reflow and repaint.
Per the CSS contain spec, layout, style and paint containments are
enabled for `content-visibility: hidden` and `content-visibility: auto`.
As a consequence, changing `content-visibility` between `hidden` and
`auto` values no longer requires reconstruction. Changing between these
values and `visible` may need a reconstruction although authors may
generally avoid that in practice by forcing `style` containment.
Differential Revision: https://phabricator.services.mozilla.com/D197043
`Selection.modify` with `"line"` calls `nsIFrame::PeekOffsetForLine` (which
is also used to move caret). To compute the destination,
`nsIFrame::PeekOffsetForLine` is used, but it may return a native anonymous
node because its helper function, `GetSelectionClosestFrame`, does not check
the boundary. On the other hand, it's used by pointing device event handlers
too. In this case, it needs to return a native anonymous node. Therefore,
the helper method requires additional flag to consider whether it can return
native anonymous node.
Differential Revision: https://phabricator.services.mozilla.com/D198358
After D198523, NS_BLOCK_FLOAT_MGR and NS_BLOCK_MARGIN_ROOT are always
set simultaneously when initiating a frame, so we can merge them into a
single NS_BLOCK_STATIC_BFC flag. The freed bit is used to define a new
NS_BLOCK_DYNAMIC_BFC flag that has the same effect and is now used for
frames with paint/layout containment so that in D197043 they can be
updated later without having to reconstruct the frame tree. Finally
NS_BLOCK_BFC_STATE_BITS is the bitwise union of these BFC flags.
The following changes are made and cause no behavior changes:
- Instead of testing whether NS_BLOCK_FLOAT_MGR or NS_BLOCK_MARGIN_ROOT
is set, or whether all of the bits from
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS are set, we test whether any
of the NS_BLOCK_BFC_STATE_BITS is set.
- Instead of adding NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS when
constructing a frame, we add NS_BLOCK_STATIC_BFC. The exception is
for frame with paint/layout containment, for which we set
NS_BLOCK_DYNAMIC_BFC instead.
Differential Revision: https://phabricator.services.mozilla.com/D198530
These flags are generally always set simultaneously via
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS. This commit changes the three
remaining places where only NS_BLOCK_FLOAT_MGR is set:
1. nsFileControlFrame, used by <input type="file">
2. nsComboboxControlFrame used by <select>
3. nsSelectsAreaFrame, used by <select multiple>
(1) and (2) create their own child frames that can't be styled by
authors. (3) wraps its children into a -moz-scrolled-content which
already prevents them from taking collapsing margins with their parent.
So it is safe to add NS_BLOCK_MARGIN_ROOT here.
Differential Revision: https://phabricator.services.mozilla.com/D198523
SetNextContinuation() and SetPrevContinuation() are almost always called
together when setting up a continuation link, but the callers don't call them in
particular order. We should unify them as one method so that it's more
ergonomics and robust, especially when we do more complex work such as caching
continuations. Same reason for SetNextInFlow() and SetPrevInFlow().
We choose to merge the SetPrevContinuation() code into SetNextContinuation() for
the symmetry of SetNextSibling(). (Yes, we don't have SetPrevSibling().)
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D197966
The methods are in `nsCaret`, `nsFrameSelection` and `dom::Selection`. That
makes harder to read, and they are called each other, so, they are reused for
different purpose. Therefore, it must be better to move them into a new class.
Then, the name differences may become more unclear. If you think so, feel free
to request renaming some methods of them.
Differential Revision: https://phabricator.services.mozilla.com/D197288
Nobody shares an instance of `nsFrameIterator`. Therefore, we can make it
non-refcountable. Additionally, `nsVisualIterator` is not required because
it overrides only 4 methods which are really simple. So, once we merge it
into `nsFrameIterator`, we can allocate it in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D197144
The class is used only for creating `nsFrameIterator`, but it's unnecessary
so that we can get rid of it and its interface.
Differential Revision: https://phabricator.services.mozilla.com/D197143
It's inherited only by `nsFrameIterator`, and `nsFrameIterator` can be declared
in a header file. So, the interface is not required and removing it can avoid
virtual calls.
Differential Revision: https://phabricator.services.mozilla.com/D197142
Nobody shares an instance of `nsFrameIterator`. Therefore, we can make it
non-refcountable. Additionally, `nsVisualIterator` is not required because
it overrides only 4 methods which are really simple. So, once we merge it
into `nsFrameIterator`, we can allocate it in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D197144
The class is used only for creating `nsFrameIterator`, but it's unnecessary
so that we can get rid of it and its interface.
Differential Revision: https://phabricator.services.mozilla.com/D197143
It's inherited only by `nsFrameIterator`, and `nsFrameIterator` can be declared
in a header file. So, the interface is not required and removing it can avoid
virtual calls.
Differential Revision: https://phabricator.services.mozilla.com/D197142
It's one of the hot and more complex functions during painting, and it depends only on frame type + style info, so it's a perfect candidate for caching.
Differential Revision: https://phabricator.services.mozilla.com/D196200
This is tested via the inert tests, effectively, but I can add more
explicit tests.
Remove rules that would otherwise change behavior (the other rules in
the tree apply to XUL elements and serve a purpose).
Differential Revision: https://phabricator.services.mozilla.com/D195645
