This is used by platforms with overlay scrollbars, only in order to
reserve enough space for the chevron of the `<select>` element.
So our general min-widget-size, which is the same as for scrollbars
works.
Differential Revision: https://phabricator.services.mozilla.com/D71825
i.e. remove annotations that manually enable the property, and remove the
property_database.js check that tests for the property being enabled.
We've been shipping with the property enabled ever since Firefox 69, so we're
realistically not going to default-disable it at this point, which means these
annotations (and the property_database.js check) are just cruft.
Differential Revision: https://phabricator.services.mozilla.com/D69128
These reftests are copied from flexbox-unbreakable-child-1-*.html and
flexbox-unbreakable-child-1-*-wrap.html with "box-decoration-break:
clone" added to the flex container.
Note that flexbox-unbreakable-child-3-ref.html is redesigned. It is not
copied from flexbox-unbreakable-child-1-ref.html with
"box-decoration-break: clone" added because the bottom border doesn't
show up in sub-test 3 & 4. (bug 1564726 perhaps?)
Differential Revision: https://phabricator.services.mozilla.com/D69475
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
As described in bug 1630274, this has some unfixed cases, but it should
give good results in most real-world cases, where the magnitude of transient
async scrolling is relatively low.
Depends on D71083
Differential Revision: https://phabricator.services.mozilla.com/D71084
--HG--
extra : moz-landing-system : lando
This patch just ensures the changes in the previous patches get applied
to the WR codepath, and is sufficient to make all the remaining sticky
tests pass on Android+WR.
Differential Revision: https://phabricator.services.mozilla.com/D70911
--HG--
extra : moz-landing-system : lando
This patch removes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity
- The second optimization applies opacity directly to stacking context of nsDisplayMasksAndClipPaths with non-polygonal clip-paths
Differential Revision: https://phabricator.services.mozilla.com/D68995
--HG--
extra : moz-landing-system : lando
The WR code that computed the sticky_offset didn't properly combine the offsets
from the top- and bottom- sticky calculations if an item had both. This patch
fixes the calculation, which makes the remaining test failure (in the
configuration without any dynamic toolbar) pass.
Depends on D70679
Differential Revision: https://phabricator.services.mozilla.com/D70680
--HG--
extra : moz-landing-system : lando
The sticky info emitted by Gecko to WR wasn't quite correct in some cases
where sticky items had both top and bottom sticky ranges. This corrects
the info emitted by Gecko. This change makes a few of the failing tests
pass, but also makes one fail. That one failure was previously passing due
to two bugs canceling each other out, and is fixed up in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D70679
--HG--
extra : moz-landing-system : lando
Failures will be addressed in later bugs. Refer to the text in the reftest.list
file for a brief overview of how the tests are structured.
Depends on D70459
Differential Revision: https://phabricator.services.mozilla.com/D70460
--HG--
extra : moz-landing-system : lando
I verified that this reproduces the issue by manually un-applying the patch for bug 1469000.
Differential Revision: https://phabricator.services.mozilla.com/D70658
--HG--
extra : moz-landing-system : lando
The old code caused GetLastPaintOffset to return an offset from two paints ago if it was called before RecyclePaintedLayer, which can happen when the first item in a painted layer moves to a different layer.
Differential Revision: https://phabricator.services.mozilla.com/D70241
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
Note that the sticky-top test still fails on non-WebRender, but that's outside
the scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D69560
--HG--
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-fixed-top-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-bottom-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-top-1.html
extra : moz-landing-system : lando
This makes the existing test for this codepath start passing on geckoview-qr.
Differential Revision: https://phabricator.services.mozilla.com/D69558
--HG--
extra : moz-landing-system : lando
Note that the sticky-top test still fails on non-WebRender, but that's outside
the scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D69560
--HG--
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-fixed-top-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-bottom-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-top-1.html
extra : moz-landing-system : lando
This makes the existing test for this codepath start passing on geckoview-qr.
Differential Revision: https://phabricator.services.mozilla.com/D69558
--HG--
extra : moz-landing-system : lando
Note that the sticky-top test still fails on non-WebRender, but that's outside
the scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D69560
--HG--
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-fixed-top-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-bottom-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-top-1.html
extra : moz-landing-system : lando
This makes the existing test for this codepath start passing on geckoview-qr.
Depends on D69557
Differential Revision: https://phabricator.services.mozilla.com/D69558
--HG--
extra : moz-landing-system : lando
Back when webrender did not call FrameLayerBuilder::ChooseScale (it was called ChooseScaleAndSetTransform back then until it was factored out in bug 1415987) bug 1449640 landed which made the webrender scale choosing more closely align with FrameLayerBuilder::ChooseScale by not computing a scale of there was preserve3d or perspective involved. That patch had a bug, it looked at the parent stacking context helper to see if it had preserve 3d, but FrameLayerBuilder::ChooseScale looks at the current "stacking context".
This didn't cause a problem in the testcase from this bug until bug 1569215 landed. In the testcase in this bug we have a stacking context with a 2d transform whose parent stacking context is preserve3d. So we pass down the scale from the parent stacking context and completely ignore the scale induced by the 2d transform. Passing 1.f to ChooseScale instead of the parent scale factor "undid" this mistake, so when that was fixed we regressed this testcase.
Differential Revision: https://phabricator.services.mozilla.com/D69167
--HG--
extra : moz-landing-system : lando