The functions move to ColumnUtils will be used by ColumnSetWrapperFrame
to implement GetPrefISize() and GetMinISize().
Also, I verify locally that non-unified build is still working by
s/UNIFIED_SOURCES/SOURCES/ in layout/generic/moz.build.
Differential Revision: https://phabricator.services.mozilla.com/D29614
--HG--
extra : moz-landing-system : lando
Before this change, only elements inside the shadow root tree were scanned for the
draggable=true attribute. We now check the flattened tree instead so an element
inside a shadow root can start a drag for an element containing the shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D30365
--HG--
extra : moz-landing-system : lando
The patch in bug 1507744 was not sufficient by itself, as the line-breaker could still accumulate a single "current word" across a text-run boundary, and then a single word-break value would be applied to it. We need to flush the line-breaker when word-break changes, so that each part of the word will have break opportunities set according to the appropriate value.
Differential Revision: https://phabricator.services.mozilla.com/D30260
--HG--
extra : moz-landing-system : lando
Move ApplyOpacity(), CanApplyOpacity(), Paint() and PaintWithClip() methods to nsPaintedDisplayItem
Differential Revision: https://phabricator.services.mozilla.com/D30225
--HG--
extra : moz-landing-system : lando
ColumnSetFrame always tries to reflow column content regardless of it's
dirtiness. Making ColumnSetWrapperFrame's children dirty can have the
same effect.
Differential Revision: https://phabricator.services.mozilla.com/D29435
--HG--
extra : moz-landing-system : lando
We use `columnCount == aConfig.mBalanceColCount - 1` in other places to
determine if we are at the last column. Advancing the column count at
the end of the loop make the condition consistent.
Differential Revision: https://phabricator.services.mozilla.com/D29433
--HG--
extra : moz-landing-system : lando
Test coverage for this is provided in the web platform test
html/browsers/browsing-the-web/history-traversal/persisted-user-state-restoration/scroll-restoration-fragment-scrolling-samedoc.html.
Differential Revision: https://phabricator.services.mozilla.com/D30105
--HG--
extra : moz-landing-system : lando
ColumnSetFrame always tries to reflow column content regardless of it's
dirtiness. Making ColumnSetWrapperFrame's children dirty can have the
same effect.
Differential Revision: https://phabricator.services.mozilla.com/D29435
--HG--
extra : moz-landing-system : lando
We use `columnCount == aConfig.mBalanceColCount - 1` in other places to
determine if we are at the last column. Advancing the column count at
the end of the loop make the condition consistent.
Differential Revision: https://phabricator.services.mozilla.com/D29433
--HG--
extra : moz-landing-system : lando
The test itself is reasonable, except that it reads scroll positions
from the main thread. With APZ enabled we need to flush any pending APZ
repaints before reading these scroll positions. So changing the
waitForAllPaints to the APZ-flushing variant makes that happen, and the
test passes.
Depends on D29921
Differential Revision: https://phabricator.services.mozilla.com/D29922
--HG--
extra : moz-landing-system : lando
Unfortunately, `EventChainVisitor` does not grab the `nsPresContext` with
`RefPtr` by itself. Therefore, there is no guarantee of the lifetime without
checking the origin when its subclasses are instantiated. This patch changes
it and subclasses to `MOZ_STACK_CLASS` since only `EventDispatcher::Dispatch()`
creates them in the stack with given `nsPresContext`. Additionally, it's
already been marked as MOZ_CAN_RUN_SCRIPT_BOUNDARY`. Therefore, the
`nsPresContext` instance has already been guaranteed its lifetime by the
caller. For making this fact stronger, this patch marks their constructors
as `MOZ_CAN_RUN_SCRIPT`. Therefore, nobody can create those instances without
guaranteeing the lifetime of `nsPresContext` and `dom::Event`. Note that
it may look like that `mPresContext` of `EventChainPostVisitor` is not
guaranteed. However, `EventChainPreVisitor` which gives `nsPresContext` to it
is also a stack only class. So, it won't be deleted before
`EventChainPostVisitor` instance.
Differential Revision: https://phabricator.services.mozilla.com/D30010
--HG--
extra : moz-landing-system : lando
Like Part 2, I choose mCachedPrefISize because grid and flex container
are using it.
Differential Revision: https://phabricator.services.mozilla.com/D29748
--HG--
extra : moz-landing-system : lando
Instead of renaming it to mMinISize, I choose mCachedMinISize because
both grid and flex container frames use mCachedMinISize for similar
purpose.
Differential Revision: https://phabricator.services.mozilla.com/D29747
--HG--
extra : moz-landing-system : lando
This patch is generated by running the following script under layout/,
and then manually delete the FIXME comment in LayoutConstants.h
#!/bin/bash
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename NS_INTRINSIC_WIDTH_UNKNOWN NS_INTRINSIC_ISIZE_UNKNOWN
Differential Revision: https://phabricator.services.mozilla.com/D29746
--HG--
extra : moz-landing-system : lando
Added a test to test the empty block (didn't submit to WPT because it's not
clear to me if the outlines of the two spans should form a single rect or not).
Differential Revision: https://phabricator.services.mozilla.com/D29819
--HG--
extra : moz-landing-system : lando
We always include the combinator for pseudo-elements now (not including it was
just an optimization) in order to not match when nested pseudo-elements are
involved.
We could add a more generic check in `matches_simple_selector` like:
```
if element.is_pseudo_element() {
match *selector {
Component::PseudoElement(..) |
Component::NonTSPseudoClass(..) => {},
_ => return false,
}
}
```
But even that wouldn't be enough to make selectors like `:hover::marker` not
match on the `::before::marker` pseudo-element, plus that code is really hot.
So for now do the check on the `next_element_for_combinator` function. It's a
bit hacky but it's the best I could came up with...
While at it, simplify some checks to use is_pseudo_element() instead of
implemented_pseudo_element() directly.
Only the Rust patch as-is would make markers for ::before and ::after on list
items not show up, so we also need to switch ::marker to use ProbeMarkerStyle()
rather than ProbePseudoElementStyle(), since the marker should exist even if it
matches no rules.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando
And also this patch moves some related methods which use the inline methods
and member variables used only by them.
Differential Revision: https://phabricator.services.mozilla.com/D29201
--HG--
rename : layout/base/nsIPresShellInlines.h => layout/base/PresShellInlines.h
extra : moz-landing-system : lando
There is the following usage of nsIPresShell:
```
nsCOMPtr<nsIPresShell> presShell = do_QueryReferent(mPresShellWeak);
```
So, for changing this to:
```
RefPtr<PresShell> presShell = do_QueryReferent(mPresShellWeak);
```
PresShell should have its own IID.
Differential Revision: https://phabricator.services.mozilla.com/D29197
--HG--
extra : moz-landing-system : lando
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : moz-landing-system : lando
`nsIPresShell::ScrollAxis` can be used anywhere and it's used by some
utils actually. So, it should be in `mozilla` namespace and perhaps,
`PresShellForwards.h` is a good place to move it rather than creating
new header file.
Differential Revision: https://phabricator.services.mozilla.com/D29110
--HG--
extra : moz-landing-system : lando
Also, make the assertion shorter & more to the point. In particular,
I'm removing the note about stray whitespace, which is based on one
previous scenario that caused extra child frames; but I don't have
much confidence that potential future causes of this assertion-failure
will have that specific problem as their root cause.
Differential Revision: https://phabricator.services.mozilla.com/D28547
--HG--
extra : moz-landing-system : lando
Spec quote from https://drafts.csswg.org/css-contain/#containment-size :
"Replaced elements must be treated as having an intrinsic width and height of 0"
To achieve that, we just need to:
(a) make all of these frame classes' GetPrefISize and GetMinISize methods return 0 if they're styled with contain:size.
(b) make all of these frame classes' GetIntrinsicSize() and GetIntrinsicRatio() methods return 0,0.
In some cases, these methods are implemented in terms of common helper methods
(and sometimes member variables). For those cases, this patch adjusts the
helper methods (and variables) rather than the getters themselves.
Also: in one case (nsHTMLCanvasFrame), I needed to update its ComputeSize
method to remove a dependency on the "real" intrinsic size & ratio. I believe
the other classes' ComputeSize implementations do the right thing automatically
by sharing code & data with their intrinsic-size codepaths.
Differential Revision: https://phabricator.services.mozilla.com/D28159
--HG--
rename : testing/web-platform/tests/media/white.webm => testing/web-platform/tests/css/css-contain/support/white.webm
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
It looked a bit weird when mixed up with the other enum classes I'm about to
rename.
Depends on D28679
Differential Revision: https://phabricator.services.mozilla.com/D28680
--HG--
extra : moz-landing-system : lando
We have a better type to represent "a coord or nothing", and that's Maybe.
This code is shorter, and I think reads generally better / is less easy to
misuse.
I wrote this on top of bug 1547126 so there shouldn't be conflicts.
Differential Revision: https://phabricator.services.mozilla.com/D28921
--HG--
extra : moz-landing-system : lando
This patch shouldn't affect behavior; it's just simplifying existing code with
a new convenience constructor.
Differential Revision: https://phabricator.services.mozilla.com/D28918
--HG--
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
This patch creates new header, `mozilla/PresShellForwards.h`. It should have
all forward declarations of global class/struct in `nsIPresShell.h` and
`mozilla/PresShell.h`.
Additionally, this moves all `enum`s and `constant`s in them into the new file
with changing them to `enum class`es.
This will make other headers which require only specific types in the header
files not include them.
Differential Revision: https://phabricator.services.mozilla.com/D28605
--HG--
extra : moz-landing-system : lando
There are some minor behavior changes come with this.
1) Change the default containing block size to (NS_UNCONSTRAINEDSIZE,
NS_UNCONSTRAINEDSIZE). I think this is more reasonable than (-1, -1).
2) mContainingBlockSize is used to cache only the block size passing
though constructor, Init(), or the invalid (-1, -1). This patch makes
it cache the value computed by ComputeContainingBlockRectangle().
Note that mContainingBlockSize is used only in
nsTableWrapperFrame::InitChildReflowInput() to set the inner table
frame's containing block to be the same as the outer table frame's.
We don't change this behavior by caching more. Because even if the
inner frame use the invalid cached (-1, -1) containing block size
from the outer reflow input, it still computes the block size again
in InitConstraints(). (Inner table's cb is the same as the outer
table's per InitCBReflowInput().)
Differential Revision: https://phabricator.services.mozilla.com/D28586
--HG--
extra : moz-landing-system : lando
Fixed width and height is not a strong enough condition.
min/max-width with intrinsic size keywords makes the final size of the image
also depend on the intrinsic size. Don't optimize away reflows when the
intrinsic size changes if they're used.
Differential Revision: https://phabricator.services.mozilla.com/D28720
--HG--
extra : moz-landing-system : lando
We do want to record soft break opportunity after a frame whose content can't
be part of the existing in-flow text run, since this normally should be a text run
boundary. However, though an out-of-flow frame can't be part of the existing
in-flow text run, it also doesn't break it either. In fact, the texts after the
out-of-flow frames are able to continue the existing in-flow text run. So,
introducing a line-break-after opportunity in this case may cause an unexpected
line break for every out-of-flow frame.
In this patch, we add a condition to prevent us from recording soft break
opportunities for out-of-flow frames.
Differential Revision: https://phabricator.services.mozilla.com/D28625
--HG--
extra : moz-landing-system : lando
We do want to record soft break opportunity after a frame whose content can't
be part of the existing in-flow text run, since this normally should be a text run
boundary. However, though an out-of-flow frame can't be part of the existing
in-flow text run, it also doesn't break it either. In fact, the texts after the
out-of-flow frames are able to continue the existing in-flow text run. So,
introducing a line-break-after opportunity in this case may cause an unexpected
line break for every out-of-flow frame.
In this patch, we add a condition to prevent us from recording soft break
opportunities for out-of-flow frames.
Differential Revision: https://phabricator.services.mozilla.com/D28625
--HG--
extra : moz-landing-system : lando
This patch should not affect behavior; the new implementation is
identical to the old one, but with better sharing of code.
Also: I'm removing the code-comment saying that the intrinsic ratio
is unused, because it's not really useful and it's unclear to me that
it's strictly true. There are several cases in the function we pass it
to, nsFrame::ComputeSizeWithIntrinsicDimensions, that use the ratio
and that look reachable as long as we have 'width:auto' in CSS.
Differential Revision: https://phabricator.services.mozilla.com/D28416
--HG--
extra : moz-landing-system : lando
With webrender, current gecko does not handle SurfaceTexture.getTransformMatrix() yet. SurfaceTexture is used for video decoding and WebGL. On both usages, when getTransformMatrix() is not handled, it actually worked as bottom left origin. Then gecko need to ignore y flip. AsyncImagePipelineManager::ApplyAsyncImageForPipeline() is a good place to handle the situations, since it handles canvas and video frame rendering. Long term solution is going to be handled by Bug 1507076.
Differential Revision: https://phabricator.services.mozilla.com/D28315
--HG--
extra : moz-landing-system : lando
This patch also renames `targetRect` to `snapArea` to represent it more
accurately.
Differential Revision: https://phabricator.services.mozilla.com/D28307
--HG--
extra : moz-landing-system : lando
Now scroll-snap-type property on body element doesn't affect scroll position
so that scrollTo-scrollBy-snaps.html is needed to be modified to specify
scroll-snap-type on html.
Differential Revision: https://phabricator.services.mozilla.com/D27987
--HG--
extra : moz-landing-system : lando
The one is for the scroll snap module v1 implementation, the other is for the
old scroll snap implementation. Now both functions have the same pieces of
code to get scroll-snap-type values, but for v1 implemention in the next commit
we will use GetFrameForScrollSnap() to get the value instead.
Differential Revision: https://phabricator.services.mozilla.com/D27986
--HG--
extra : moz-landing-system : lando
In the CSS writing mode spec [1], the writing mode for the document should be
taken from body, GetFrameForDir() is the function to get the corresponding frame
for writing-mode.
A web platform test for this case will be added at the last of this commit
series. Unfortunately as of this commit, we can't introduce proper test cases
since there is another issue on scroll-snap-type which will be fixed in
subsequent commits.
[1] https://drafts.csswg.org/css-writing-modes-4/#principal-flow
Differential Revision: https://phabricator.services.mozilla.com/D27984
--HG--
extra : moz-landing-system : lando
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
After introducing column-span, the ColumnSetWrapperFrame can have more
than one ColumnSetFrame children if there's any column-span:all child.
Thus we cannot use "height:100%" to pass block size information down to
the -moz-column-content's children.
Skip column span wrapper in nsIFrame::IsBlockWrapper() so that the
percentage column-span:all works.
Before this patch, the height of column contents are set to 100% of the
multicol container, so if the previous in-flows of column content
anonymous boxes consume all the height, later in-flows's height are all
0. In this patch, we don't restrict column-content's height, so their
height are calculated based on their children's height.
column-contain-1a.html passes because it can now correctly calculate the
union of all the column content's rect to find the correct sticky
positioning.
Differential Revision: https://phabricator.services.mozilla.com/D27627
--HG--
extra : moz-landing-system : lando
Also, move GetAvailableContentBSize() to non-public section because it's
only used by nsColumnSetFrame.
Differential Revision: https://phabricator.services.mozilla.com/D28014
--HG--
extra : moz-landing-system : lando
ColumnBalanceData is reset in the beginning of ReflowChildren(), so I
make ReflowChildren() return a fresh ColumnBalanceData so that it's
easier (at least for me) to understand the data is recomputed in
every reflow iteration.
Also, FindBestBalanceBSize() uses ColumnBalanceData as an input to begin
its column balancing iteration. Make the argument pass by value so that
the caller's copy won't be modified.
Differential Revision: https://phabricator.services.mozilla.com/D28013
--HG--
extra : moz-landing-system : lando
I manually search "height" and replace it with "block-size" if the code
around it uses logical coordinates.
Differential Revision: https://phabricator.services.mozilla.com/D28012
--HG--
extra : moz-landing-system : lando
No code after FindBestBalanceBSize() is interested in
aUnboundedLastColumn and aRunWasFeasible, so they don't need to be
input/output arguments.
Differential Revision: https://phabricator.services.mozilla.com/D28009
--HG--
extra : moz-landing-system : lando
Also move to first cache-line (64-bytes) of nsDisplayItem to improve D-cache hit
when accessing mFrame, mItemFlags, etc.
Differential Revision: https://phabricator.services.mozilla.com/D26134
--HG--
extra : moz-landing-system : lando
There are conditions that the given scroll position in app units differs from
the current position in app units even if those values are the same in CSS
pixels. Setting Element.scrollTop with Element.scrollTop in a callback of
scroll event is one of such cases.
The change here looks messy, but I am totally unsure that we can clamp the
values before initializing the range for the DISABLE_SNAP case, so I'd like to
preserve the behavior there. Once we ship the new scroll snap, we can drop
the DISABLE_SNAP case there so that it could be less messy at the time.
Differential Revision: https://phabricator.services.mozilla.com/D27638
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
And tell webrender to do them itself (they have fundamental mismatches in how they
define shadow bounds).
Differential Revision: https://phabricator.services.mozilla.com/D26845
--HG--
extra : moz-landing-system : lando
Now the spec cleary says that we don't need to propagate body's
scroll-padding value to the document viewport since
https://github.com/w3c/csswg-drafts/issues/3740, so we don't need to care about
GetViewportScrollStylesOverrideElement() at all.
This change fixes the crash test case in this commit, but it's not sufficient.
In the next patch, we will fix another crash case.
Differential Revision: https://phabricator.services.mozilla.com/D27422
--HG--
extra : moz-landing-system : lando
Servo already atomizes the counter names, it makes no sense to copy the string
rather than bumping the refcount.
Differential Revision: https://phabricator.services.mozilla.com/D27061
--HG--
extra : moz-landing-system : lando
And tell webrender to do them itself (they have fundamental mismatches in how they
define shadow bounds).
Differential Revision: https://phabricator.services.mozilla.com/D26845
--HG--
extra : moz-landing-system : lando
This will force APZ to do a main-thread hit-test for the cases where the
shapes are too complex to easily send to the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D27455
--HG--
extra : moz-landing-system : lando
Also move to first cache-line (64-bytes) of nsDisplayItem to improve D-cache hit
when accessing mFrame, mItemFlags, etc.
Differential Revision: https://phabricator.services.mozilla.com/D26134
--HG--
extra : moz-landing-system : lando
So, this patch makes all caller of it safe including its arguments unless
they come from other methods.
Differential Revision: https://phabricator.services.mozilla.com/D27225
--HG--
extra : moz-landing-system : lando
This patch makes `nsViewManager::GetPresShell()` and
`nsIWidgetListener::GetPresShell()` (overridden by `nsView` and
`nsWebShellWindow::WidgetListenerDelegate`) return `mozilla::PresShell*`.
Additionally, makes `nsWebShellWindow::GetPresShell()` also return
`mozilla::PresShell()`.
Differential Revision: https://phabricator.services.mozilla.com/D26454
--HG--
extra : moz-landing-system : lando
This patch makes `nsDocShell::GetPresShell()` and
`nsDocShell::GetEldestPresShell()` return `mozilla::PresShell*` and
some non-public methods use `mozilla::PresShell*` directly.
Differential Revision: https://phabricator.services.mozilla.com/D26424
--HG--
extra : moz-landing-system : lando
This is a follow-up for Part 1. I find all the candidates by running the
following command under layout/, and manually replace them.
ag -A 1 reflow$ | ag -B 1 state
Differential Revision: https://phabricator.services.mozilla.com/D27162
--HG--
extra : moz-landing-system : lando
nsHTMLReflowState was renamed to ReflowInput in bug 1277129, so remove
the "Html" in the variable name.
Also, remove the comment "ReflowBlock will initialize it." because
ReflowInput::Init() is called in the constructor. We are not using
ReflowInput::CALLER_WILL_INIT flag here.
Differential Revision: https://phabricator.services.mozilla.com/D27024
--HG--
extra : moz-landing-system : lando
This patch extracts two additional CompositorHitTestInfo flags from the
eDispatchToContent flag; eApzAwareListeners for elements that have
APZ-aware listeners, and eInactiveScrollframe for inactive scrollframe
or unlayerized scrollthumbs. The eDispatchToContent is then renamed to
eIrregularArea to reflect the fact that it is used for irregular-shaped
areas that require main-thread hit-testing.
Additionally, it is important to note that when using the non-WebRender
codepath, all three of these flags still end up gettings squashed into
the "dispatch to content" region on the EventRegions; when APZ
reconstructs a CompositorHitTestInfo it will turn anything in this
region back into an eIrregularArea. So this is a lossy round-trip
conversion for the non-WebRender case. However it should still result in
correct behaviour because the semantics of eIrregularArea result in APZ
relying on the main-thread to do hit-testing and so any APZ-aware
listeners and inactive scrollframes are also handled by the main-thread.
Differential Revision: https://phabricator.services.mozilla.com/D26440
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
As for scrolling on the compositor we don't cull out them since we don't know
the final snapport rect at the time when we send the information about
snapping to the compositor. And we will handle it for APZ in bug 1531589.
https://drafts.csswg.org/css-scroll-snap-1/#snap-scope
Depends on D21632
Differential Revision: https://phabricator.services.mozilla.com/D21633
--HG--
extra : moz-landing-system : lando
https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-align
The main logic here is basically same as the old scroll snap implementation,
just iterating over all descendant elements in the scroll container and collect
snap positions. The differences are;
1) the snap positions are specified based on descendant elements instead of
points
2) the snap positions are able to be specified by `block` or `inline` keywords
so that we also need to care the element flow.
more test cases for this are coming in the next commit
3) the target rect is calculated by nsLayoutUtils::TransformFrameRectToAncestor
which means transform is already taken account into it (we have a bug for
the old scroll snap, it's bug 1218745)
some of web platform tests will be added in a subsequent commit
Some of test cases in overflowing-snap-areas.html that accidentally have
passed start failing with this change, all of them will be passed with
subsequent changes in these commit series.
Depends on D21627
Differential Revision: https://phabricator.services.mozilla.com/D21628
--HG--
extra : moz-landing-system : lando
From the spec [1];
Using the scroll-snap-type property on the relevant scroll container, the
author can request a particular bias for the scrollport to land on a snap
position after scrolling operations (including programmatic scrolls such
as the scrollTo() method).
The target here are functions exposed in web contents other than
Element.scrollIntoView which will be changed in the next commit.
[1] https://drafts.csswg.org/css-scroll-snap-1/#overview
Depends on D21624
Differential Revision: https://phabricator.services.mozilla.com/D21625
--HG--
extra : moz-landing-system : lando
There are some that only have one caller, and some slightly confusing naming.
Hopefully make it a bit clearer.
Differential Revision: https://phabricator.services.mozilla.com/D25457
--HG--
extra : moz-landing-system : lando
This switches nsFrameSetFrame's hacky frame construction codepath to operate on
the flattened tree, since it made me a bit more comfortable about it (all layout
should operate on is the flattened tree, though in this cause this should not
cause any web-observable behavior change, since <frameset> can't be a shadow
host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles
lazily in descendants of display: none elements, and even though this code
doesn't check on display: none _on the children_, the parent element should
never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the <area> elements referencing an
image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for
LazyComputeBehavior::Allow on the document element in order to check the
viewport styles propagation, since the root element can't have display: none
ancestors. But we run that code before actually constructing the doc element
containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now,
since we need to keep using it for the <body>, since the document element could
be display: none itself, and we propagate the overflow styles in that case
still. I filed https://github.com/w3c/csswg-drafts/issues/3779 to potentially
change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
nsFrameLoaderOwner::UpdateRemoteness will recreate the nsFrameLoader for a
piece of content. As part of this, it will unset the cached nsFrameLoader for
the content's nsSubdocumentFrame. However we need to run ShowViewer() for the
new nsFrameLoader as the frame has already been initialized. In addition,
dimensions and position on the new nsFrameLoader need to be set. Usually this
is done after a reflow, but there's no guarantee a reflow will happen after
a UpdateRemoteness operation.
Differential Revision: https://phabricator.services.mozilla.com/D25662
--HG--
extra : moz-landing-system : lando
nsIPresShell.h is widely included, so this avoids excessively long rebuilds
when MobileViewportManager.h is modified.
Differential Revision: https://phabricator.services.mozilla.com/D26245
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
That is, change all uses of StyleComplexColor to just StyleColor.
Differential Revision: https://phabricator.services.mozilla.com/D25977
--HG--
rename : layout/style/StyleComplexColor.cpp => layout/style/StyleColor.cpp
rename : layout/style/StyleComplexColor.h => layout/style/StyleColorInlines.h
extra : moz-landing-system : lando
This will enable the devtools font highlighting issue in bug 1479760 to be fixed
using ::selection, and matches webkit/blink behavior.
When we implement ::inactive-selection (bug 1475773) it will supersede this.
Differential Revision: https://phabricator.services.mozilla.com/D25396
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
This patch makes `nsFrameSelection` treat `mozilla::PresShell` directly and
rename `nsFrameSelection::GetShell()` to `nsFrameSelection::GetPresShell()
because of avoiding confusion between `PresShell` vs. `DocShell`.
Differential Revision: https://phabricator.services.mozilla.com/D25719
--HG--
extra : moz-landing-system : lando
nsUnicodeProperties.h includes into ICU, which has implicit int
truncation, so quarantine this include out of problematic headers.
Depends on D25498
Differential Revision: https://phabricator.services.mozilla.com/D25499
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
This allows us to reduce #include usage of the massive gfxFont.h header,
and keeps this specialized kind of TextRange struct local to where it's used.
Differential Revision: https://phabricator.services.mozilla.com/D22904
--HG--
extra : moz-landing-system : lando
This will enable the devtools font highlighting issue in bug 1479760 to be fixed
using ::selection, and matches webkit/blink behavior.
When we implement ::inactive-selection (bug 1475773) it will supersede this.
Differential Revision: https://phabricator.services.mozilla.com/D25396
--HG--
extra : moz-landing-system : lando
Ting-Yu Lin
Cameron McCormack
Artur Signell
Jonathan Kew
Miko Mynttinen
Alexis Beingessner
Botond Ballo
arthur.iakab
Matt Woodrow
Kartikaya Gupta
Masayuki Nakano
Emilio Cobos Álvarez
Noemi Erli
Andreea Pavel
Sylvestre Ledru
Daniel Holbert
Hiroyuki Ikezoe
Dorel Luca
Brindusan Cristian
Jeremy Chen
Cosmin Sabou
sotaro
Ryan Hunt
Srujana Peddinti
Markus Stange
Dan Glastonbury
Mats Palmgren
Bogdan Tara
Brian Grinstead
Daniel Varga
Csoregi Natalia
Mike Conley
Narcis Beleuzu
Razvan Maries
Jeff Gilbert