Merely checking for having a displayport isn't enough, because the paint to
tell APZ about the new scroll frame could still be pending.
Differential Revision: https://phabricator.services.mozilla.com/D56662
--HG--
extra : moz-landing-system : lando
foo ? true : false
or:
foo ? false : true
Have always a nicer way to be written.
Differential Revision: https://phabricator.services.mozilla.com/D56842
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Update the comments, name, and fields to show it is agnostic of isize/bsize.
Differential Revision: https://phabricator.services.mozilla.com/D51739
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
I'd like to add some new data type for motion path, so it'd be great to
put all of them in an independent file.
Differential Revision: https://phabricator.services.mozilla.com/D50008
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
We could put this change itself behind a pref too, if we considered that worth
it. But probably not so.
Differential Revision: https://phabricator.services.mozilla.com/D48010
--HG--
extra : moz-landing-system : lando
It will generate a warning and is useless as explained in the code comment.
Differential Revision: https://phabricator.services.mozilla.com/D46626
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : source : fc785139655e3d22d681f1419bd4c80f93460f0e
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Converts layout.css.outline-style-auto.enabled to a static pref and removes nsLayoutUtils::isOutlineStyleAutoEnabled().
Differential Revision: https://phabricator.services.mozilla.com/D41861
--HG--
extra : moz-landing-system : lando