These values start out false in the other two ways display lists can be build:
- Without retained display lists, a new nsDisplayList object is created which starts out with these values being false.
- When partial update succeeds (or at least gets far enough to run PreProcessDisplayList), RestoreState() is called on the root display list which sets these values to false.
But when partial update fails, we have an old nsDisplayList object and we were not clearing those values.
Differential Revision: https://phabricator.services.mozilla.com/D55866
On Chrome, visual viewport resize event is fired repeatedly during dynamic
toolbar transitions and visual viewport height obtained by the VisualViewport
API is also changed, but in terms of layout the height value is never used
until the dynamic toolbar height reaches to zero or is changed from zero.
The height used at the time is the height for vh units when the toolbar height
reaches to zero and the ICB height when the toolbar height is changed from zero.
To do so, we need to have another visual viewport size in parallel to the
original one and use them depending on situations.
Differential Revision: https://phabricator.services.mozilla.com/D52338
This facilitates disabling APZ "live", such as when moving a tab from an APZ
window into a non-APZ window.
Depends on D51468
Differential Revision: https://phabricator.services.mozilla.com/D51469
Though there is another call site of UpdateCompositionBoundsForRCDRSF in
nsLayoutUtils::CalculateRootCompositionSize, it's not clear to me whether it is
necessary or not since we early return from the function in the case where
|aIsRootContentDocRootScrollFrame| argument is true. We will audit it later
in bug 1562505.
Differential Revision: https://phabricator.services.mozilla.com/D53117
Note that this FrameMetrics.mLayoutViewport doesn't represent exact size of
the layout viewport on the main thread, it means the maximum layout viewport
in future on the compositor thread once after the dynamic toolbar is completely
hidden. During the dynamic toolbar transition we don't update any information
on the main thread, which means it's possible that the visual viewport on the
compositor gets bigger than the layout viewport at the time when we send it
to the compositor thread, we have to avoid the situation.
Depends on D50419
Differential Revision: https://phabricator.services.mozilla.com/D50420
Now
* nsPresContext::mVisibleArea is excluding the toolbar max height so that
ICB is now static regardless of the dynamic toolbar transition
* nsPresContext::mSizeForViewportUnits is introduced to resolve viewport units
which is including the toolbar max height
That means that with the dynamic toolbar max height;
mVisibleArea < mSizeForViewportUnits
See https://github.com/bokand/URLBarSizing for more detail backgrounds of this
change.
Depends on D50417
Differential Revision: https://phabricator.services.mozilla.com/D50418
So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
In common cases where the caret is in a position:static frame subtree,
the caret's position (relative to canvas frame's custom content
container) should not be changed during scrolling.
However, when the caret is in a position:fixed or "stuck"
position:sticky frame subtree, the caret's position will change during
scrolling. We need to disable APZ to avoid jumpy carets.
Differential Revision: https://phabricator.services.mozilla.com/D51351
Changes here:
- Adding a "dom::" prefix in GeckoMVMContext.cpp (could've also added
a "using" decl, but I'm just adding a one-off prefix to match "dom::Document"
usage elsewhere in this file).
- Giving nsLayoutUtils an include for ViewportFrame.h since it uses that type.
- Giving nsPresArena.cpp an include for nsDisplayList.h to provide the
DisplayListArenaObjectId enum type.
Depends on D50163
Differential Revision: https://phabricator.services.mozilla.com/D50164
We need to distinguish between the out-of-process iframe is totally invisible and
the given nsIFrame is not in out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D46553
We need to distinguish between the out-of-process iframe is totally invisible and
the given nsIFrame is not in out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D46553
1. Add `generics::motion::OffsetPath`, and use specified `Angle` and
computed `Angle` to define specified `OffsetPath` and computed `OffsetPath`.
2. Add `ray` function into `OffsetPath`.
We also tweak the degree from 150deg to 135deg in wpt (e.g.
offset-path-ray-001.html and others) to avoid floating point precision issues.
For example:
```
// offset-path: ray(150deg ...);
// offset-distance: 20px;
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320509 0.000000 1.000000}
}
// rotate(60deg) translate(20px)
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320507 0.000000 1.000000}
}
```
Their translate parts, 17.320509 vs 17.320507, are almost the same (only
tiny difference), which may cause the reftest failed.
Differential Revision: https://phabricator.services.mozilla.com/D42721
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Converts layout.css.outline-style-auto.enabled to a static pref and removes nsLayoutUtils::isOutlineStyleAutoEnabled().
Differential Revision: https://phabricator.services.mozilla.com/D41861
Converts layout.idle_period.required_quiescent_frames and layout.idle_period.time_limit to static prefs. These are the last prefs in nsLayoutUtils::initialize(), but since the function still calls nsComputedDOMStyle::RegisterPrefChangeCallbacks() the commit retains it.
Differential Revision: https://phabricator.services.mozilla.com/D41856
Converts nglayout.debug.invalidation to a static pref. Retains the old getter function from the old static bool, because it makes an additional comparison.
Differential Revision: https://phabricator.services.mozilla.com/D41845
Converts zoom.maxPercent and zoom.minPercent to static prefs, which creates a new "zoom" category on StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D41835
