Since bug 1650183, the value returned by this function is not
necessarily the composition size of the RCD-RSF, but may be
a smaller size suitable for bounding the composited size of
scroll frames in a given process.
Differential Revision: https://phabricator.services.mozilla.com/D104463
This was just a silly typo; I got the order of the ternary expression's options
backwards.
The mistake wasn't obvious from testing, because this function isn't always
invoked. In particular, it's not invoked if I print "https://example.org" in a
fresh profile, but it *is* invoked if I print "about:support" or other
browser-internal pages.
Differential Revision: https://phabricator.services.mozilla.com/D104354
These changes make nsDisplayCompositorHitTestInfo inherit directly from nsDisplayItem, which should shrink it slightly. This also simplifies the logic: hit testing information is now available at nsDisplayItem level as opposed to nsPaintedDisplayItem.
Differential Revision: https://phabricator.services.mozilla.com/D103773
These changes make nsDisplayCompositorHitTestInfo inherit directly from nsDisplayItem, which should shrink it slightly. This also simplifies the logic: hit testing information is now available at nsDisplayItem level as opposed to nsPaintedDisplayItem.
Differential Revision: https://phabricator.services.mozilla.com/D103773
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
Also, make sure that BFCachePreventionObserver does not fire events for
elements that are part of an anonymous native tree.
Differential Revision: https://phabricator.services.mozilla.com/D103812
We keep mMedium in nsPresContext rather than just looking it up in the
browsing context because that's used quite more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D103782
Asynchronous font loading occurs during scroll position tests, it resets
scroll positions to 0. So, this causes intermittent failures in such tests.
Disabling the async font loading under `layout/base/tests` may not be proper
solution because some layout tests may work perfectly even if global reflow
may occur.
Therefore, this patch moves 2 tests which check scroll position to under
`dom/events/test` and disabling the async font loading since the global reflow
shouldn't be related to the tests under `dom/events`.
Differential Revision: https://phabricator.services.mozilla.com/D103013
Some mochitests use `nsISelectionController` instead of synthesizing key since
`Home`, `End`, `PageUp` and `PageDown` didn't work as native key event.
Differential Revision: https://phabricator.services.mozilla.com/D102879
Otherwise on Android, we always use the toolbar height set by applications even
if the pref was set (Note that GeckoView Test Runner doesn't have the dynamic
toolbar thus the height is always 0).
Differential Revision: https://phabricator.services.mozilla.com/D103611
The Windows code was going into effect even if non-native-theme was
enabled, so right now nnt does something different in windows from other
platforms.
I think we should make it match Windows, which also matches Chromium on
non-Windows platforms too.
Differential Revision: https://phabricator.services.mozilla.com/D103633
Without this the non-native theme fails the last assertion of the test.
I couldn't reproduce locally but the word that it's supposed to be
selected is very close to being out of the iframe viewport on my
machine, so it'd make sense if the new non-native theme, which has a bit
more padding, causes the word to move a bit further down.
I've confirmed this fixes the issue.
Differential Revision: https://phabricator.services.mozilla.com/D103317
There's no reason we should need an scrollbar box to query the size of a
scrollbar. I plan to use this in the following patch to make the size of a
resizer not vary depending on whether the container has scrollbars or not,
which is what ultimately causes the reftest failure.
Differential Revision: https://phabricator.services.mozilla.com/D103302
Because DecideScrollableLayer uses the existence of a displayport in it's decision.
In practice though we only paint from process root documents and the root scroll frame will have a displayport (almost?) always. So it's a small correctness improvement that is likely to have little effect.
Differential Revision: https://phabricator.services.mozilla.com/D102588
This patch makes the following changes:
1. Don't call ReflowInput::CalculateBlockSideMargins() for nsTableFrame
so that setting nsTableFrame's computed margins to zero in
SizeComputationInput::InitOffsets() remains true. Also, add an assertion
in nsTableFrame::Reflow() to ensure that.
2. Remove useless nsTableFrameWrapper::GetChildMargin() because the
method is used to get nsTableFrame's margins, which are now all zero.
Also, the old code that subtracts the block-axis margin from available
block-size doesn't really make sense.
3. Pass all-zero innerMargins to nsTableWrapperFrame::SetDesiredSize(),
and use table wrapper's content-box inline-size as the final desired
border-box inline-size rather than reconstructing it from caption and
inner table's inline-size & margin like the old code.
This inline-size already takes inner table's intrinsic size and
caption's inline-size into consideration in
nsTableWrapperFrame::ComputeAutoSize(), and is the final inline-size we
want to use.
In the next part, we are going to simplify all nsTableWrapperFrame's
methods that take inner frame's margin.
Differential Revision: https://phabricator.services.mozilla.com/D103065
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
In the unit-tests, flushing is not done. This was prevented implicitly
by nulling `mPresShell`. This change makes that explicit by stubbing
`MaybeFlushLayout`.
Note that `IsTerminated`, which is called in the same context is already
virtual, so I expect this to not have a noticeable performance-impact.
Depends on D102607
Differential Revision: https://phabricator.services.mozilla.com/D102608
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
DisplayPortMargins objects are only meant to be created when setting
display port margins, not when querying them, because the object's
constructor records the visual and layout scroll offsets at the time
of construction to use for adjusting the margins to be layout-relative.
Differential Revision: https://phabricator.services.mozilla.com/D102075
Touches that land on a descendant of a clickable element should
not get retargeted to other nearby elements because the descendant
itself can react to those touch events.
Differential Revision: https://phabricator.services.mozilla.com/D102827
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
EventStateManager::PostHandleEvent would do the same thing, but need to handle
the cases that PresShell is destroyed and frame is destroyed in
pointerup/pointercancel event listener.
The former case would be handled in D102403. For the latter case, we allow
EventStateManager::PostHandleEvent to handle pointerup/pointercancel event while
frame is no longer available in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D102404
Encapsulates flushing-related functionality.
Please see part 25) for further simplifcation of `LayoutFlusher`.
Depends on D102413
Differential Revision: https://phabricator.services.mozilla.com/D102414
ComputeISizeValue() takes aspect-ratio into account. Also, add a
ComputeSizeFlag which skips aspect-ratio in ComputeISizeValue(), so
internal table boxes can use this flag to skip aspect-ratio.
Differential Revision: https://phabricator.services.mozilla.com/D99290
OneShotPostRefreshObserver works as the caller registers it, and
let it deletes itself via the DidRefresh method. The issue is that
DidRefresh is not guaranteed to run, and it'll leak PresShell
if it doesn't run.
This patch allows nsPresContext to store and release the last
registered OneShotPostRefreshObserver, and converted the existing
usage of OneShotPostRefreshObserver to use that. So instead of asking
OneShotPostRefreshObserver to delete itself, we now ask nsPresContext
to release it.
Differential Revision: https://phabricator.services.mozilla.com/D99939
