nsIScrollableFrame::IsScrollingActive basically means "has this scroll frame been scrolled recently or is this the root scroll frame". Neither of which is relevant when we are async scrolling a scrollframe on the compositor.
What determines if we can scroll a scroll frame async is ScrollFrameHelper::mWillBuildScrollableLayer, aka nsIScrollableFrame::IsMaybeAsynchronouslyScrolled.
The code in nsDisplayStickyPosition::GetStickyScrollContainer already mostly neuters nsDisplayStickyPosition is this isn't the case, this just takes it one step further.
This also removes one more user of nsIScrollableFrame::IsScrollingActive, there are only a handful left.
Differential Revision: https://phabricator.services.mozilla.com/D126427
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
We store this new bit in nsIFrame instead of in ReflowInput to record a
change to padding (inspired by the mHasBSizeChange bit). That is because
we may construct a ReflowInput more than one time before reflowing the
frame. The first construction of ReflowInput (in
SizeComputationInput::InitOffsets) will update
nsIFrame::UsedPaddingProperty() using the latest style data, so
we *cannot* determine the padding change in any of the subsequent
construction of ReflowInput.
dynamic-change-inline-size-001.html is the scenario fixed by
bug 1307853. We've already passed this test without this patch.
dynamic-change-inline-size-002.html is equivalent to 001.html except
it's written with "box-sizing:content".
dynamic-change-inline-size-003.html is adapted from testcase 2 in bug
1729122 comment 4. Both tests pass after this patch.
Differential Revision: https://phabricator.services.mozilla.com/D126422
I'm not aware of any reason we shouldn't do this, as it is interoperable
with other browsers, and it causes compat issues from sites that forget
to use the prefixed version.
Note this removes some #[parse(aliases)]. These only affect devtools
autocomplete behavior, and we avoid autocompleting -moz-prefixed
keywords when possible, so even though it's a slight behavior change,
it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D126718
We only need the actual iterator once, to get the line number; subsequently, we can use
the new CanProvideLineIterator method to check if we've found a block frame without
paying the cost of actually initializing it.
This eliminates the last remaining caller of nsIFrame::GetLineNumber, so that method
(which is prone to inefficient usage) can be removed altogether.
Differential Revision: https://phabricator.services.mozilla.com/D126532
This means nsBlockFrame::GetLineIterator is also infallible, so callers that know
they're dealing with an nsBlockFrame (not an arbitrary nsIFrame) don't need to
check for null.
Differential Revision: https://phabricator.services.mozilla.com/D126470
Previously, to check whether two frames were on the same line, you had to call nsIFrame::GetLineNumber on both of them.
If the lines were in a different containing block, this wastefully created line iterators.
With this new method, you can get the containing blocks for both frames and only create a single line iterator if the blocks are the same.
To achieve this, nsIFrame::CanProvideLineIterator was also added and is used by GetContainingBlockForLine.
Accessibility will use this new functionality in its new text boundary implementation.
Differential Revision: https://phabricator.services.mozilla.com/D126433
This frame property's type is small enough to fit directly in the property
table's 64-byte slot; so, this patch makes us store the data directly there
(rather than allocating it externally and storing a pointer in the table).
This patch shouldn't impact behavior at all.
Differential Revision: https://phabricator.services.mozilla.com/D126031
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125738
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Depends on D125610
Differential Revision: https://phabricator.services.mozilla.com/D125611
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
GetOffsetToCrossDoc takes a valid non null pointer of nsIFrame, so it will not
walk up the frame tree across process boundaries.
If the call site needed the offset up to a frame in a different process, which
means the function call used for obtaining the nsIFrame needs to be audited such
as bug 1727229, which is for auditing GetReferenceFrame call sites
(GetOffsetToCrossDoc is often used with GetReferenceFrame, something like
`GetOffsetToCrossDoc(GetReferenceFrame())`.
FWIW, I did skim all GetOffsetToCrossDoc call sites [1], all look okay to me,
they are in auto scrolling, event handling, display list building, in the parent
process (i.e. XUL), etc. etc. Those features have been addressed in Fission.
[1] https://searchfox.org/mozilla-central/search?q=nsIFrame%3A%3AGetOffsetToCrossDoc&path=&case=true®exp=false
Differential Revision: https://phabricator.services.mozilla.com/D123553
IsVisibleConsideringAncestors has a PresShell::IsUnderHiddenEmbedderElement which
is representing ancestor's visibility state in different process (but only for
contents processes). so it doesn't need to walk up the frame tree across process
boundaries.
Differential Revision: https://phabricator.services.mozilla.com/D123556
Collapsing selection with middle click is compatible behavior with Chrome.
However, some Firefox users don't like this behavior, and we have not done it
before. Therefore, this patch adds a hidden pref to prevent the new Chrome
compatible behavior.
Keeping compatible behavior is important and middle click is mainly used for
autoscroll. Therefore, if auto scroll is disabled, we should ignore the new
pref for better compatibility.
Unfortunately, we collapse selection before `AutoScrollChild` handles
`mousedown` event with the listener in the system group (
`nsIFrame::HandleEvent()` is called before that). Therefore, we cannot prevent
the selection change from `AutoScrollChild` only when it starts scroll.
For solving this issue, we need a lot of big changes. Therefore, for now,
this patch just checks whether the pref is enabled or not.
And also the new pref is ignored when middle click paste is enabled because
it may be followed by "paste" event even when user clicks non-editable nodes.
Then, if web apps handle "paste" event, the new selection range may be
important. Therefore, we should ignore the new pref in this case.
Differential Revision: https://phabricator.services.mozilla.com/D122931
