Depends on D136163
I have a feeling this isn't exactly the right way to pass this info, since the old WR code must have known about the perspective node without using my new flag.
Differential Revision: https://phabricator.services.mozilla.com/D136180
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
The assertion here was added during the iterator refactoring in bug 1732349,
but is actually bogus. The old code would have returned via the MOZ_TRY_VAR
that wrapped the call to blockFrame->GetLineNumber(); that's replaced by
iter->FindLineContaining(), so we should now check for an error there and
similarly just return to the caller, not assert.
Differential Revision: https://phabricator.services.mozilla.com/D134950
Bug 1550869 made all the non-editable images return a `FrameTarget` with
`userFrameEdge=true`. When the user moves the mouse pointer to select an image
from its left edge, the mouse pointer needs to reach the right edge of the image
in order to complete the selection. This makes it difficult to select an image
at the end of a line.
This patch restores the behavior to select a non-draggable & non-editable image
to it was before bug 1550869. That is, we recognize the image selection when the
mouse pointer moves passed the middle point of the image
width (`OffsetsForSingleFrame`). Both blink and webkit have the same behavior,
but no spec text dictates this behavior, so I mark the wpt test as "tentative".
Differential Revision: https://phabricator.services.mozilla.com/D133960
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
Applying it to SVG-transformed frames is wrong, and causes us to
rasterize rather massive SVGs. This is consistent with the other CSS
3d transforms code, and our rendering of the test-case matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D132040
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
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
