Bug 1682686 added the tests which need
layout.css.grid-item-baxis-measurement.enabled to be set to `true` independent
of the release channel.
Differential Revision: https://phabricator.services.mozilla.com/D139410
The code at the end of ComputeFinalBSize() does not handle
"box-decoration-break:clone" and the cases where the block frame's reflow status
can change from incomplete to complete. This patch is an attempt to fix all the
possible scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D138967
ComputeFinalBSize() gets most of its input parameters from BlockReflowInput's
members. Passing BlockReflowInput into it directly so that it can access more
precomputed data in BlockReflowInput such as `ContentBEnd()`.
This is a preparation for the next part that is going to rewrite a large portion
of ComputeFinalBSize().
Differential Revision: https://phabricator.services.mozilla.com/D138966
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
We already call MaybeQueueCacheUpdateForStyleChanges from DidSetComputedStyle for reconstructed frames.
However, at that point, nsIContent::GetPrimaryFrame (and thus LocalAccessible::GetFrame) returns null, which means we're unable to check for style changes.
Instead, we now handle style changes for reconstructed frames in PruneOrInsertSubtree, at which point the frame is definitely available.
Differential Revision: https://phabricator.services.mozilla.com/D138627
If a block container has box-decoration-break:clone, its block-end border and
padding (BP) are *usually* drawn at the block-end edge of the current
column/page. Thus, when computing the available block-size for its children, we
should subtract its block-end border BP from it.
When I claim the block-end BP are *usually* drawn at the block-end edge of the
column/page, the exception is when a block container with a definite block-size
runs out of its block-size in a column/page. In this case, the block-end BP is
drawn at the block-end edge of its content-box. This patch wires the effective
content-box block-size computed in nsBlockFrame::Reflow() into
BlockReflowInput's constructor, and we do not subtract its block-end border BP
from the `mContentArea.BSize(wm)` when this case happens.
`BlockReflowInput::ContentBSize()` is the correct available block-size to reflow
the children, precomputed in BlockReflowInput's constructor. See
https://searchfox.org/mozilla-central/rev/c12a59323ee46b29b90c9917a3a7a70ea714ffec/layout/generic/BlockReflowInput.cpp#118-126
The remove hunk was a hack, working only for ColumnSetWrapper with
`box-decoration-break:clone`. It's no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D138367
If the visual viewport offset is not set on the presshell then calling GetVisualViewportOffset returns (0, 0). This then causes us to introduce an incorrect offset between the layout scroll offset and the visual viewport offset that didn't exist before.
Logically we want to treat an unset visual viewport offset as the layout scroll offset.
Other possible fixes:
-make PresShell::GetVisualViewportOffset return the layout scroll offset if a visual viewport offset is not set
-make this if conditional on a visual viewport offset already being set
-the combination of the two above
All of these fail some tests on try server. I haven't investigated why. If we want to go with any of those potential fixes in the future then this patch is a step on the way there
Differential Revision: https://phabricator.services.mozilla.com/D137873
This patch ensures that we only update the external image resource for
WebGPU when there has been an actual change for the resource. In order
to guarantee this, we wait for the present to complete, and only then
issue the update. WebRenderBridgeChild::SendResourceUpdates will also
trigger a frame generation if any resources were changed, which means we
don't need to trigger a paint on the frame itself anymore.
Note that we still have a race condition when we write into the
MemoryTextureHost while in PresentCallback, and the renderer thread may
be accessing the pixel data to upload to the GPU.
Differential Revision: https://phabricator.services.mozilla.com/D138349
ScrollFrameHelper::GetVisualViewportOffset will return a pending vv offset if there is one. So if there is a pending vv offset this line will instantly turn it into the current vv offset. This is not how the pending vv offset is supposed to work. It should get sent over to apz, apz can then decide to accept or reject it based on whether it knows about user scrolling that overrides it.
I saw this while reading code for something else, so I don't know of anything specific this fixes.
Depends on D137720
Differential Revision: https://phabricator.services.mozilla.com/D137721
Currently, we pass all the five fields in FlexLayoutResult separately into
ReflowChildren(), but we really should just pass FlexLayoutResult instead.
Differential Revision: https://phabricator.services.mozilla.com/D138100
We've got the tentative cross size before calling DoFlexLayout() in Reflow(), so
we can just use that value in DoFlexLayout and a few other methods.
Also, add "ContentBox" to naming of the main size argument ComputeMainSize().
Differential Revision: https://phabricator.services.mozilla.com/D137365
I found in/out parameters confusing when reasoning the data flow. Aggregating
DoFlexLayout's output data in a struct also reduces DoFlexLayout's number of
arguments.
Differential Revision: https://phabricator.services.mozilla.com/D137364
The `struts` array is used only within DoFlexLayout, so we should move it into
`if (!GetPrevInFlow()) { ... }` branch.
Also, move `nsTArray<StrutInfo>&` argument on DoFlexLayout() to the second to
last place so that the output arguments are grouped together after applying Part
4.
Differential Revision: https://phabricator.services.mozilla.com/D137363
Move the assertion for unconstrained isize to the beginning of Reflow() because
we check it in all cases -- in GetMainSizeFromReflowInput when a flex container
is row-oriented, or in the old code computing gap size and ComputeCrossSize()
when a flex container is column-oriented.
Differential Revision: https://phabricator.services.mozilla.com/D137361
This adds a round trip from double -> float -> double because
CSSRect is float but it should be ok because most users of gfxRect (RectDouble)
should be using Rect instead anyways.
Differential Revision: https://phabricator.services.mozilla.com/D137811
There's no need to create a visual viewport offset here, only if one already exists do we want to clamp it.
I noticed this while reading code for something else, so I'm not sure if it actually fixes anything.
Differential Revision: https://phabricator.services.mozilla.com/D137720
This scaling factor is to account for ComputePagesPerSheetAndPageSizeTransform,
but that is not used when printing headers/footers, which resulted in the
reversed scale clipping the header/footer.
Differential Revision: https://phabricator.services.mozilla.com/D136830
We weren't doing it. I want to see if it helps with some flickering
intermittents with the patch of bug 1718220.
Not sure how to reliably test this.
Differential Revision: https://phabricator.services.mozilla.com/D137794
This scaling factor is to account for ComputePagesPerSheetAndPageSizeTransform,
but that is not used when printing headers/footers, which resulted in the
reversed scale clipping the header/footer.
Differential Revision: https://phabricator.services.mozilla.com/D136830
The reason why the global ScrollGeneration::sCounter doesn't work for the APZ
case is the APZ sampler thread is per our top level browser window, so if
there are multiple browser windows at the same time, the sCounter will be muted
from different sampler threads.
Differential Revision: https://phabricator.services.mozilla.com/D133439
This was added in bug 1201330 but with WR isn't really needed anymore and the code causes the expiration timer to fire until the scroll frame becomes inactive (the most common scroll frames stay active, ie root scroll frames).
Differential Revision: https://phabricator.services.mozilla.com/D136806
In general, we don't need to store used border and padding in a derived frame
class, nsIFrame::GetLogicalUsedBorderAndPadding() already provides the data.
While auditing the consumer of `mBorderPadding`, I realize that
nsHTMLCanvasFrame's fragmentation never works because
nsCSSFrameConstructor::CreateContinuingFrame() never creates its continuation,
and nsHTMLCanvasFrame::Reflow() never returns an incomplete reflow status to its
parent.
This patch removes the code that pretended to handle fragmentation to avoid any
confusion. Luckily, with `layout.display-list.improve-fragmentation` enabled by
default, we can still print <canvas> without data loss.
Differential Revision: https://phabricator.services.mozilla.com/D136649
The old code operates in the CSS pixel coordinate, so we should use the type
system to express that. With this patch, nsImageControlFrame, nsImageFrame, and
nsImageMap now have no usage of nsIntPoint.
Differential Revision: https://phabricator.services.mozilla.com/D136647
Depends on D136163
I have a feeling this isn't exactly the right way to pass this info, since the old WR code must have known about the perspective node without using my new flag.
Differential Revision: https://phabricator.services.mozilla.com/D136180
I added this check in bug 1725569 because I said it matched other browsers. I'm not sure what testing I did there, or I made a mistake or what but the behaviour is not consistent between browsers.
For top level documents on initial load Safari sends a resize event, Chrome does not. Firefox sends a resize event.
For iframes Chrome and Safari send a resize event. Firefox usually sends a resize event.
Given the inconsistent behaviour here it seems better to err on the side of sending resize events because sites depend on it and might not work without it.
In the testcase from the bug I am able to reproduce about 20% of the time, and the problem is the first reflow check. So I'm removing that and I think it will fix the problem the user is seeing (which sounds to be more consistent).
Differential Revision: https://phabricator.services.mozilla.com/D135698
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
nsPageSequenceFrame does a thing where it grows its desired size to fit the
AvailableISize and ComputedBSize (under the assumption that those are the
actual dimensions of our scrollport, which it wants to make maximal use of).
This behavior causes trouble when it's reflowed under the privileged
'sizeToContent' JS API. That API makes us reflow with nscoord_MAX as the
viewport's ComputedBSize(), and this nscoord_MAX value gets passed down to be
the nsPageSequenceFrame's ComputedBSize as well. When we reach the code in
question, we dutifully grow the desired size to that bogus huge value, which is
clearly wrong.
This patch addresses this issue by simply declining to grow the desired size in
the scenario where ComputedBSize() is unconstrained. This leaves us with
reasonable values for our desired size (which are actually based on the
content, which makes it the right thing to do for the purpose of a
SizeToContent() call).
Differential Revision: https://phabricator.services.mozilla.com/D135762
This patch fixed the following:
1. Make the helper support the vertical writing modes since its callers
GetMinISize() and GetPrefISize() are fully aware of the vertical writing modes.
`overflow-scroll-intrinsic-001.html` verifies this scenario. This also fixed a
testcase with "writing-mode: vertical-lr" in flexbox's
cross-axis-scrollbar.html.
2. Treat scrollbar's intrinsic size "zero" if we have "scrollbar-width: none"
since no scrollbar is showing at all.
`overflow-auto-scrollbar-gutter-intrinsic-003.html` verifies this scenario.
3. Return the scrollbar size if we have "scrollbar-gutter: stable", or twice the
size if we have "scrollbar-gutter: stable both-edges".
`overflow-auto-scrollbar-gutter-intrinsic-{001,002}.html` verifies this
scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135182
Part of how invalidation works with WebRender is that we assume frames
with a WebRenderUserData object attached to them are in view. This means
for images that we must ensure we create an empty
WebRenderImageProviderData object even when we have no provider or
surface for display. This will allow us to invalidate properly when we
get the FRAME_COMPLETE notification from imagelib indicating that the
redecode has completed.
Differential Revision: https://phabricator.services.mozilla.com/D135077
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
The assertion here was added during the iterator refactoring in bug 1732349,
but is actually bogus. The old code would have returned via the MOZ_TRY_VAR
that wrapped the call to blockFrame->GetLineNumber(); that's replaced by
iter->FindLineContaining(), so we should now check for an error there and
similarly just return to the caller, not assert.
Differential Revision: https://phabricator.services.mozilla.com/D134950
We introduced this comment at the very beginning of the flexbox implementation.
Since then, WritingModes.h has obtained the utilities dealing with logical axis,
and CSSAlignUtils.h has supported CSS alignment for both flexbox and grid. All
the helper functions remaining in nsFlexContainerFrame.cpp are related to
flexbox, so I feel it's time we retire this comment.
NPOTB DONTBUILD because this patch changes only comments.
Differential Revision: https://phabricator.services.mozilla.com/D134652
In Flexbox spec 4.1, Example 3 [1]:
... since the absolutely-positioned box is considered to be
"fixed-size", a value of stretch is treated the same as flex-start.
Also, per Alignment 3 spec [2]:
The default fallback alignment for 'stretch' is 'flex-start'.
Thus, when computing the alignment for flexbox's abspos children in
CSSAlignmentForAbsPosChild(), we convert 'stretch' to 'flex-start', and let the
subsequent logic convert 'flex-start' to either 'start' or 'end', because
nsAbsoluteContainingBlock don't know how to deal with the flex-relative axis.
This patch makes us behave the same as Google Chrome on the modified testcases.
[1] https://drafts.csswg.org/css-flexbox/#abspos-items
[2] https://drafts.csswg.org/css-align/#valdef-align-content-stretch
Differential Revision: https://phabricator.services.mozilla.com/D134543
We now support scrollbar-gutter property. So for example, assume the scroll
container has "scrollbar-gutter:stable". When toggling the visibility of
inline-end scrollbar, we can skip the reflow for the scroll inner frame because
the available inline-size for it cannot change.
This patch teaches TryLayout() to consider the sizes of scrollbar gutter rather
than the (assumed) visibility of scrollbars when deciding the need to call
ReflowScrolledFrame().
Also, TryLayout() doesn't need to report an inconsistent layout unless
the (showHScrollbar, showVScrollbar) pair changes the sizes of scrollbar
gutters.
Differential Revision: https://phabricator.services.mozilla.com/D134373
Bug 1550869 made all the non-editable images return a `FrameTarget` with
`userFrameEdge=true`. When the user moves the mouse pointer to select an image
from its left edge, the mouse pointer needs to reach the right edge of the image
in order to complete the selection. This makes it difficult to select an image
at the end of a line.
This patch restores the behavior to select a non-draggable & non-editable image
to it was before bug 1550869. That is, we recognize the image selection when the
mouse pointer moves passed the middle point of the image
width (`OffsetsForSingleFrame`). Both blink and webkit have the same behavior,
but no spec text dictates this behavior, so I mark the wpt test as "tentative".
Differential Revision: https://phabricator.services.mozilla.com/D133960
Here are the ideas of the implementation.
1) When creating ScrollReflowInput, we compute and store the size of the
scrollbar-gutter in `mScrollbarGutterSizes.
2) Provide a ScrollReflowInput::ScrollbarGutter() API that returns the space
occupied by scrollbar gutters or scrollbars, and use it in ReflowScrolledFrame()
and TryLayout().
-----
For test changes:
- The existing scrollbar-gutter changes all assume classic scrollbars that can
create scrollbar gutters, so they won't pass on Android which uses overlay
scrollbars.
- Add scrollbar-gutter-002.html to test when the scrollbar and gutter
are both shown. The reference of this uses padding to simulate
scrollbar-gutter, so it's OK if the platform uses overlay scrollbars.
The next patch will add more variants.
- scrollbar-gutter-dynamic-001.html was never run. Fixed it by adding
`<link rel="match">`.
Differential Revision: https://phabricator.services.mozilla.com/D132664
Here are the ideas of the implementation.
1) When creating ScrollReflowInput, we compute and store the size of the
scrollbar-gutter in `mScrollbarGutterSizes.
2) Provide a ScrollReflowInput::ScrollbarGutter() API that returns the space
occupied by scrollbar gutters or scrollbars, and use it in ReflowScrolledFrame()
and TryLayout().
-----
For test changes:
- The existing scrollbar-gutter changes all assume classic scrollbars that can
create scrollbar gutters, so they won't pass on Android which uses overlay
scrollbars.
- Add scrollbar-gutter-002.html to test when the scrollbar and gutter
are both shown. The reference of this uses padding to simulate
scrollbar-gutter, so it's OK if the platform uses overlay scrollbars.
The next patch will add more variants.
- scrollbar-gutter-dynamic-001.html was never run. Fixed it by adding
`<link rel="match">`.
Differential Revision: https://phabricator.services.mozilla.com/D132664
Currently, mResizerBox's rect (variable `r`) partially depends on the result
of mScrollCornerBox's rect.
This patch makes mScrollCornerBox and mResizerBox compute their own rects (in
variable `r`) in separate if-statements because we can show resizer without
showing scroll corner (due to no scrollbar).
Differential Revision: https://phabricator.services.mozilla.com/D133694
HasResizer() is equivalent to mResizerBox and is used only within
ScrollFrameHelper, so no need to expose it. Also, remove some unreachable
if-branches.
Differential Revision: https://phabricator.services.mozilla.com/D133693
Revise vRect & hRect computation because the scrollbar gutter can be at both
inline start and inline end sides. For example, we can no longer use
`aInsideBorderArea.width - mScrollPort.width` to get the actual width of the
vertical scrollbar. We want to compute them in different ways.
Differential Revision: https://phabricator.services.mozilla.com/D133692
Compute the actual vertical & horizontal scrollbars' rects (vRect & hRect) only
when we decide to show the scrollbars. The rationale is that after introducing
scrollbar-gutter in bug 1715112, `mScrollPort` is no longer equal to
`aInsideBorderArea` even if we don't show scrollbars, and we want scrollbar
rects remaining empty to avoid showing them.
Simplify `hasVisualOnlyScrollbarsOnBothDirections` and move it closer to its
first usage.
Differential Revision: https://phabricator.services.mozilla.com/D133691
Currently, we use IsPhysicalLTR() to query which is the start side of the
physical left <-> right axis. However, for vertical row-oriented flex
containers, physical left <-> right axis is its cross axis. We really should
query IsBidiLTR() instead because its main axis is parallel to line-left <->
line-right axis (i.e. inline axis).
flexbox-justify-content-wmvert-003.html is adapted from
flexbox-justify-content-wmvert-002.html.
Differential Revision: https://phabricator.services.mozilla.com/D133168
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
For reducing the legacy behavior emulator of `nsContentUtils::ComparePoints`
and make it simpler, this patch makes it take `int64_t` as the offset.
Additionally, it's named "ComparePoints_AllowNegativeOffsets`.
Differential Revision: https://phabricator.services.mozilla.com/D132549
This patch fixes only the cases if the result of `ComputeIndexOf_Deprecated()`
is used as unsigned integer with implicit or explicit cast.
Differential Revision: https://phabricator.services.mozilla.com/D131336
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
They are defined as "unsigned long" by the standards. So we should use
`uint32_t` rather than `int32_t` with the methods. However, layout code
uses `int32_t` a lot for representing the offset. Therefore, this patch
adds `*_FixOffset1` etc for the cases which cannot fix easily in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D131110
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
The basic part of the infrastructure of scroll-linked animations. This is
designed based on scroll-linked animation generated by CSS. We will
implement the timing computation and hook the ScrollTimeline to the CSS
animations in the following patches.
All the tests are in the patch that hooks ScrollTimeline to CSS Animation.
Differential Revision: https://phabricator.services.mozilla.com/D129100
This patch is inspired by `ScrollFrameHelper::GetActualScrollbarSizes()` that
uses a nsMargin to represent the space occupied by scrollbar.
In bug 1715112, TryLayout is going to consider the space occupied by the
scrollbar gutter. Hence the variable name with gutter in it just to avoid change
the variable name again.
Differential Revision: https://phabricator.services.mozilla.com/D132663
The static AddRemoveScrollbar() helper is meant to adjust the scroll port and
test whether the scrollbar fits, but its interface is obscure. By expanding the
helper in-place, the code should now become easy to follow, and we can also
remove the wordaround that sets the bool:1 bitfield.
Differential Revision: https://phabricator.services.mozilla.com/D132759
Previously with ImageContainers, we would put the new preferred surface
into the ImageContainer. When we check if we should invalidate, it would
have a different image key, and hence invalidate the image frame and
schedule a paint.
With ImageProviders, it returns the same key in this case, because the
ImageProvider represents a particular surface. As such, we need to
actually track when we get a substituted ImageProvider, and invalidate
the image frame more aggressively to ensure we get the preferred size.
Differential Revision: https://phabricator.services.mozilla.com/D132583
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Technically, `aContentArea` is not 100% wrong; its the content area of the outer
scroll frame, which contains the content area of the inner scrolled frame, the
padding, and the scrollbars. However, it should really be named
`aInsideBorderArea` as the caller names it. Otherwise, it is easy to cause
confusion with the content area of the inner scrolled frame.
Also, rename `aOldScrollArea` as well so that we use the term "scroll port"
consistently.
Differential Revision: https://phabricator.services.mozilla.com/D132445
Scrollbar's min and pref sizes won't change during reflow, so we can cache them
in ScrollReflowInput to save some repetitive computation in multiple
ReflowScrolledFrame() and TryLayout() calls.
This is also a preparation for Bug 1715112 because we can use the pref sizes to
compute the scrollbar-gutter size in ScrollReflowInput.
Differential Revision: https://phabricator.services.mozilla.com/D132443
It should be sufficient to call `SetScrollbarMediatorContent` once in
ScrollReflowInput's constructor, which is created in the beginning of
nsHTMLScrollFrame::Reflow(), instead of calling it repeatedly in multiple
TryLayout() calls.
Differential Revision: https://phabricator.services.mozilla.com/D132442
We've had some APIs passing ScrollReflowInput by reference while some others
using pointer. Let's unify them by using reference everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D132441
They shouldn't be scattered in nsHTMLScrollFrame::Reflow(). Also, reorder these
assignment operations according to the member variables' appearance order in
ScrollReflowInput.
I also moved the constructor out of the class definition because it becomes a
large method, and I'm going to add `private:` section after the methods section
in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D132440
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
Applying it to SVG-transformed frames is wrong, and causes us to
rasterize rather massive SVGs. This is consistent with the other CSS
3d transforms code, and our rendering of the test-case matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D132040
Given the compat reports in bug 1484928, I don't think it's worth
keeping the current behavior.
Our behavior should match other browsers now. Rather than making
content: url() work everywhere even for otherwise-replaced elements,
just special-case this since that's what other browsers seem to do.
Differential Revision: https://phabricator.services.mozilla.com/D131797
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
Miko Mynttinen
Sebastian Hengst
Norisz Fay
Ting-Yu Lin
Sean Feng
Andrew Osmond
Iulian Moraru
Markus Stange
James Teh
smolnar
Timothy Nikkel
Morgan Reschenberg
Emilio Cobos Álvarez
Jeff Muizelaar
Emily McDonough
Csoregi Natalia
Hiroyuki Ikezoe
Paul Zuehlcke
Nicklas Boman
Jonathan Kew
Alexandru Michis
Noemi Erli
Dzmitry Malyshau
Marian-Vasile Laza
Daniel Holbert
Neia Finch
Mike Hommey
Kagami Sascha Rosylight
Cristian Tuns
Ryan VanderMeulen
Nika Layzell
Masayuki Nakano
Boris Chiou
Dan Minor
Butkovits Atila
Greg Tatum
Chris Peterson
Andi-Bogdan Postelnicu