Note that both keywords are disabled in the CSS parser for now, behind
these about:config prefs:
layout.css.stretch-size-keyword.enabled
layout.css.webkit-fill-available.enabled
Prior to this patch, we handled both keywords as pure aliases for
'-moz-available' (which has the correct 'stretch' behavior in the inline axis
but which just behaves like the initial value in the block axis).
This patch changes that so that 'stretch' and '-webkit-fill-available' will now
actually do the right thing in the block axis (if they're enabled at all, via
their aforementioned about:config prefs).
The relevant spec text here is:
https://drafts.csswg.org/css-sizing-4/#valdef-width-stretchhttps://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing
Differential Revision: https://phabricator.services.mozilla.com/D217688
The frame destroy will tear down all the properties, no need to search for one specific property and maybe remove it before that.
This shows up in profiles.
Differential Revision: https://phabricator.services.mozilla.com/D231531
This is a chrome only css property (so it could still be used in a UA sheet that is applied to a content document) that was created solely to tabs/xul decks in a fashion that is more like the rest of css/html. And it still only has that single use in our tree. A UA sheet applying this property to content it doesn't control doesn't seem like it could be very useful.
Even those these checks are simple they are relatively costly because we check them on every frame and when we are traversing the frame tree (for display list building or setting a displayport) we are often memory bound, so pulling in another bit of otherwise cold memory for a rare style struct makes us wait for loading more memory and pushes more useful stuff out of caches. The parent process check remains very quick as verified by profiling.
Differential Revision: https://phabricator.services.mozilla.com/D231648
The only thing that useFixedPosition controls is whether we create a nsDisplayFixedPosition item. The only things that nsDisplayFixedPosition does different are things that only affect painting to the window (CreateWebRenderCommands, UpdateScrollData, ShouldGetFixedAnimationId).
I don't think this causes any behaviour difference, but we only need a nsDisplayFixedPosition item if we are painting to the window.
Differential Revision: https://phabricator.services.mozilla.com/D230243
This patch doesn't change behavior[1]; it's just a refactor.
[1] Minor caveat: the "availBased" variables in this patch are now floored-to-0
whereas previously they were not. In cases where these variables weren't
getting seprately-clamped, this is a bit of a behavior-change, but it's a step
towards correctness to floor this size-measurement to be nonnegative.
Differential Revision: https://phabricator.services.mozilla.com/D230228
This is just a variable rename to help avoid ambiguity when we add support for
the 'stretch' size keyword. This has no functional change.
Differential Revision: https://phabricator.services.mozilla.com/D230227
`nsFrameSelection::NormalSelection()` returns a `Selection&`, which eliminates the need for nullptr check at call sites.
This simplifies the code in some places and removes unnecessarily indented blocks.
Differential Revision: https://phabricator.services.mozilla.com/D230583
No change in behavior, just makes it clearer when we're working with used values
where the inline-* logical values have been resolved.
Differential Revision: https://phabricator.services.mozilla.com/D230029
And don't resolve them prematurely; the computed value should remain
logical, and only be mapped to physical sides at use time.
Differential Revision: https://phabricator.services.mozilla.com/D229998
No change in behavior, just makes it clearer when we're working with used values
where the inline-* logical values have been resolved.
Differential Revision: https://phabricator.services.mozilla.com/D230029
And don't resolve them prematurely; the computed value should remain
logical, and only be mapped to physical sides at use time.
Differential Revision: https://phabricator.services.mozilla.com/D229998
Added Gecko reftests because I don't know what the best place to put
them in WPT is, and caret rendering is kind of undefined, but...
Differential Revision: https://phabricator.services.mozilla.com/D229926
Added Gecko reftests because I don't know what the best place to put
them in WPT is, and caret rendering is kind of undefined, but...
Differential Revision: https://phabricator.services.mozilla.com/D229926
Added Gecko reftests because I don't know what the best place to put
them in WPT is, and caret rendering is kind of undefined, but...
Differential Revision: https://phabricator.services.mozilla.com/D229926
We were relying on editable text frames not being empty. We fixed that
on the previous patches but this caused editor d&d to break.
For now this preserves the selection behavior. In the future we should
look into removing the IsEmpty() condition or so, probably, or make it
more subtle.
Differential Revision: https://phabricator.services.mozilla.com/D229996
nsCSSPropertyIDSet::IsSubsetOf shows up as a significant chunk of painting. Turns out we can avoid that cost if MayHaveTransformAnimation is false, but its a little awkward because it's a bit seperated, so I included some asserts to make sure things stay in sync.
Differential Revision: https://phabricator.services.mozilla.com/D229284
In a lot of cases we go from frame/content, look up the id, then GetVisualToLayoutTransform looks up the content from the id. This is a waste. We should just pass in a content, and the one case that starts with an ViewID can look up the content to pass in since we were going to look up the content anyways.
The hashtable lookup of the content/id is showing up as biggest chunk the work in the event handling display list build that we do to handle synth mouse move events during sp3. And synth mouse moves have been identified as something we do that stands out as extra work.
Differential Revision: https://phabricator.services.mozilla.com/D228653
