Unfortunately, `HTMLEditor::MoveOneHardLineContents()`,
`HTMLEditor::MoveChildrenWithTransaction()` and
`HTMLEditor::MoveNodeOrChildrenWithTransaction()` return strict result whether
at least one node is moved or not. Therefore, we need to scan the DOM tree
whether there is at least one content node which can be moved by them for
computing target ranges.
We cannot do same thing for ``HTMLEditor::MoveOneHardLineContents()` because
it split parent elements first and use `ContentSubtreeIterator` which lists
up topmost nodes which are completely in the range, but we need to compute
target ranges without splitting nodes at the range boundaries. Therefore,
this patch checks whether the line containing specified point has content
except invisible `<br>` element.
The others are simple. We can use same logic with them.
Finally, this adds `NS_ASSERTION()`s to check whether the computation is done
correctly at running any automated tests on debug build, and I don't see any
failure with them.
Depends on D89575
Differential Revision: https://phabricator.services.mozilla.com/D89576
When they return error, neither "handled" nor "canceled" state is referred.
So, for making the code simpler, we can make them return
`EditActionResult(NS_ERROR_*)` instead of `EditActionIgnored(NS_ERROR_*)`.
Depends on D89574
Differential Revision: https://phabricator.services.mozilla.com/D89575
The 2 of them always mark the edit action as "handled", but it's not important
when it's "canceled" or an error. Therefore, we can make the users simpler
as this patch does.
Depends on D89573
Differential Revision: https://phabricator.services.mozilla.com/D89574
Now, `AutoInclusiveAncestorBlockElementsJoiner::Run()` is wrapped by a
small block in every caller. Therefore, `AutoTrackDOMPoint` for it can
be moved into the small blocks.
Depends on D89571
Differential Revision: https://phabricator.services.mozilla.com/D89572
For making the refactoring patch simpler, `Prepare()` considers the
`EditActionResult` value of its callers instead. However, this is odd
so that it just return whether the caller should keep working with
it or not as `bool` result. Then, for the additional information, whether
the caller should consume the edit action handling or not, this patch
adds a new method, `CanJoinBlocks()`.
Depends on D89440
Differential Revision: https://phabricator.services.mozilla.com/D89571
All of these reftests end up using a minimum scale with layout/classic scrollbars. (They hit the assert from the patch in bug 1663534.)
Some of them are only written with overlay scrollbars in mind (for example overflow-hidden-region-with-negative-left-positioned-element.html which I looked at in detail).
The change that causes them to fail is the code in nsHTMLScrollFrame::TryLayout that decides if we need scrollbars. Before desktop zooming scrollbars we compared the visual viewport size and the scrolled rect size. With desktop zooming scrollbars we compare the (layout) scrollport and the scrolled rect to determine if we need regular scrollbars and then compare the visual viewport size to the (layout) scrollport to determine if we need scrollbars to scroll the visual viewport inside the scrollport. Then can get different results.
Differential Revision: https://phabricator.services.mozilla.com/D89407
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
Formerly some tests were not running at all because the wptrunner
triggered an error when loading the test page. With the changes
to the navigation in Marionette this error is no longer present,
and as such allows the tests to actually run even when they still
fail or timeout.
Differential Revision: https://phabricator.services.mozilla.com/D89921
Now that all the navigation related code runs in the parent process
there is no need anymore for handling pending commands. This was
only necessary for navigation commands which could have caused
remoteness changes and as such new instances of the framescript.
In these cases the reply cannot be sent to the client unless the
command has been finished.
Differential Revision: https://phabricator.services.mozilla.com/D89717
This is sad, but seems like the least bad option to enable desktop zooming scrollbars reasonable soon.
Depends on D89409
Differential Revision: https://phabricator.services.mozilla.com/D90181
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
Adjust is-where-parsing.html to work with both the new and old behavior,
and add a test for the new behavior.
Depends on D90049
Differential Revision: https://phabricator.services.mozilla.com/D90050
The idea here was that we keep the NDK's downloaded in this directory as a "cache", such that if the download gets interrupted, then we can resume the download from an earlier point. This logic was walked back by bug 1637379, which deletes the cache.
In the spirit of the original version of the code, remove the `os.rmdir()` that was introduced by that bug.
An alternative fix for this is to download the NDK to a temporary directory and just clean that up entirely after every call to `mach bootstrap`, but then we would be forgoing the build cache behavior, which I'm not sure makes sense at this point in time.
Differential Revision: https://phabricator.services.mozilla.com/D90125
This is a requirement anyway, and the bootstrap script will yell at you if it can't find `hg` (or `git`, if it's necessary), but we can be more specific about this requirement here so people don't waste any more time than necessary.
Differential Revision: https://phabricator.services.mozilla.com/D90172
This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Depends on D89863
Differential Revision: https://phabricator.services.mozilla.com/D89864
Instead of selecting any rectangle clips as potential shared clips
for content in a picture cache slice, only select clips that are
positioned by an ancestor spatial node of the picture cache
scroll root.
This ensures we don't incorrectly select rectangle clips on the
primitive as potential shared clips, which will be important in
the follow up patches for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D90052
Also combine the border and padding arguments for
nsContainerFrame::ComputeSizeWithIntrinsicDimensions(), too. This method
is used as a helper to implement ComputeSize() for various replaced
elements. Its callers are all within nsIFrame's derived classes'
overridden methods, so I'm not bothering to convert them in a separate
patch.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D90064
