Make all UA widgets also NAC.
Keep the UA widget flag but break at anonymous subtree boundaries, so
that only nodes inside the UA widget directly (and not NAC from those)
get the flag.
This is important because two callers depend on this difference:
* The style system, since we still want to match content rules from
stylesheets in the UA widget. We also match user rules, which is a
bit sketchy, but that was the previous behavior, will file a
follow-up for that.
* The reflector code, since we want the scope for UA widgets to not
include the NAC nodes inside that UA widget. nsINode::IsInUAWidget
got it wrong.
After this patch, ChromeOnlyAccess is equivalent to
IsInNativeAnonymousSubtree, so we should probably unify the naming.
That's left for a follow-up patch because I don't have a strong
preference.
Differential Revision: https://phabricator.services.mozilla.com/D174310
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
I didn't revert some tweaks for tests (e.g. allowing small fractional scroll
position differences) since we will end up allowing the differences until
we fixed all rounding/snapping scroll related metrics issue, bug 1774315 for
example.
Differential Revision: https://phabricator.services.mozilla.com/D170465
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Now that we've removed nsXULScrollFrame, ScrollFrameHelper can be
subsumed under nsHTMLScrollFrame.
I want to do this before making scrollbars non-XUL.
Renaming to mozilla::ScrollFrame is left for a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D173063
We are doing the following things here:
1. Rename ScrollTimelineSet to ProgressTimelineScheduler because this
class is used to schedule animations with progress timelines, including
scroll timelines and view timelines.
2. Drop the element property usage and let ElementAnimationData store
ProgressTimelineScheduler.
3. We avoid using the generated content in ScrollTimeline::Scroller.
Instead, we use a pair of Element and PseudoStyleType to represent
ScrollTimeline::Scroller.
We hit the assertion because the generatd content may change and so we
shouldn't use it as the ScrollTimeline::Scroller.
Differential Revision: https://phabricator.services.mozilla.com/D172610
The underlying issue here is an invalidation bug with XUL layout. When a
popup opens, we try to lay it out at full size, then post a reflow
callback to constrain it.
There's an intermediate step there where the popup might remain at full
size, and the constraining operates directly on mRect, which isn't quite
sound and doesn't update the scrollport of descendants.
Make nsMenuPopupFrame inherit from nsBlockFrame instead, doing
potentially two layout passes when constrained.
This fixes the issue at hand, and removes XUL layout from menu popups,
so it's a win-win.
To make reasoning about it a bit easier, factor out a bunch of the XUL
positioning code to be const. The mutation of mRect etc which was going
on otherwise was pretty hard to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D170368
I didn't revert some tweaks for tests (e.g. allowing small fractional scroll
position differences) since we will end up allowing the differences until
we fixed all rounding/snapping scroll related metrics issue, bug 1774315 for
example.
Differential Revision: https://phabricator.services.mozilla.com/D170465
I didn't revert some tweaks for tests (e.g. allowing small fractional scroll
position differences) since we will end up allowing the differences until
we fixed all rounding/snapping scroll related metrics issue, bug 1774315 for
example.
Differential Revision: https://phabricator.services.mozilla.com/D170465
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
It only has an effect on macOS, and it's only used for
scrollbars/resizers/trees. We already hard-coded <browser>
to behave as never so do the same consistently, see bug 1519905.
This reduces noise when inspecting scrollbars (and it's simpler).
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D171011
It only has an effect on macOS, and it's only used for
scrollbars/resizers/trees. We already hard-coded <browser>
to behave as never so do the same consistently, see bug 1519905.
This reduces noise when inspecting scrollbars (and it's simpler).
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D171011
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
This removes the capability of having differently-sized vertical and
horizontal scrollbars (which is only potentially used in windows, and in
practice almost-never used). For that case, we choose the larger of
vertical/horizontal scrollbar sizes.
This is in order to be able to realistically expose the scrollbar size
to CSS, see blocked bug.
We make RecomputeScrollbarParams the central place where each scrollbar
style decides its sizes, and make GetDPIRatioForScrollbarPart handle the
cocoa special-case of scaling to 1 or 2, but nothing else.
Differential Revision: https://phabricator.services.mozilla.com/D168080
The way the code was set up before this patch ends up causing minimum
scrollbar sizes to be 0x0 for thin (non-overlay) scrollbars.
This is rather problematic, since it means that we would always try to
place the scrollbar even if it doesn't fit (think of an element with
height: 0).
This causes a lot of extra reflow, which with very complex layouts is
even worse, because the extra scrollframe reflows cause us to miss the
flex caches, causing O(n^2) performance.
Add assertions to make sure we never end up with a zero minimum
scrollbar size, and change the size computation to match for both
thin and thick scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D166756
The way the code was set up before this patch ends up causing minimum
scrollbar sizes to be 0x0 for thin (non-overlay) scrollbars.
This is rather problematic, since it means that we would always try to
place the scrollbar even if it doesn't fit (think of an element with
height: 0).
This causes a lot of extra reflow, which with very complex layouts is
even worse, because the extra scrollframe reflows cause us to miss the
flex caches, causing O(n^2) performance.
Add assertions to make sure we never end up with a zero minimum
scrollbar size, and change the size computation to match for both
thin and thick scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D166756
The spec is still using `Scroll-linked`, so we exclude the change of WPT tests.
I believe WPT will get updates once the spec doc is renamed.
Differential Revision: https://phabricator.services.mozilla.com/D165914
APZ cannot currently scroll in directions which are overflow:hidden
(it does not know the full scroll range bounds in those directions).
Therefore, main-thread scrolling in these directions should not be
handed off to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D161351
Use the original start position of main thread smooth scrolls to determine
if the scroll position changed on scroll complete, and fire a scrollend
event if it did.
Differential Revision: https://phabricator.services.mozilla.com/D163550
The Element caller only cares about avoiding a flush and can use the
observable parent layout stuff.
The scrollframe one clearly wants the cross-process version according to
the comment.
Differential Revision: https://phabricator.services.mozilla.com/D162477
