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