This is important because if the apz.allow_zooming pref is enabled (and
eventually even without that pref), VisualViewportOnly-type MVMs do set
the visual viewport size based on the display size and zoom, and so need
to be updated when those change.
It's also important to keep the mMobileViewportSize updated and in sync
with the display size, because it may get used via ComputeIntrinsicResolution
when fullscreening.
Differential Revision: https://phabricator.services.mozilla.com/D79594
It does not make sense to ask for layout coordinates relative to
a chrome document. If the chrome document has a zoomed (RCD)
descendant in the same process, this means we do not apply the
visual-to-layout transform when later entering the RCD.
Depends on D79588
Differential Revision: https://phabricator.services.mozilla.com/D79589
This is important because if the apz.allow_zooming pref is enabled (and
eventually even without that pref), VisualViewportOnly-type MVMs do set
the visual viewport size based on the display size and zoom, and so need
to be updated when those change.
Differential Revision: https://phabricator.services.mozilla.com/D79594
Allowing the MVM to control the reflow means that the requested reflow size
is ignored, and instead the existing CSS/layout viewport is used. This is
undesirable for calls to SizeToContent(), where the intent is to do a reflow
to figure out the smallest amount of space the content fits in.
In general though unless we are using mobile viewport sizing we shouldn't be
needing the MVM to drive reflows.
Differential Revision: https://phabricator.services.mozilla.com/D79225
The MVM is needed for both handling of meta-viewport tags and APZ zooming.
However, the set of functionality needed in the two modes are not the same.
This patch adds a mechanism to create an MVM with a flag that lets it know
which mode it is operating in. Eventually we may want to split this into two
or more classes but for now this seems like a reasonable way forward.
The flag is currently set on the MVM on creation based on whether or not the
meta-viewport support is needed. There's no code that meaningfully *uses* the
flag yet, so this patch should have no functional change. The bulk of the
patch is ensuring that we appropriately destroy and re-create the MVM if the
flag required changes.
Differential Revision: https://phabricator.services.mozilla.com/D79224
This patch is a fairly mechanical conversion. The old `nullptr` gets converted
to ScrollOrigin::NotSpecified, and all the other possible values get corresponding
values in the new ScrollOrigin enum. A few switch statements are introduced to
clean up big if statements, but other than that, additional cleanups will happen
in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D78438
This adjusts the position at which the drag images appear when doing drag
actions, so that they appear where you would expect when APZ zoom is applied.
There doesn't seem to be a good way to test this, but I did a bunch of manual
testing, with all the possible expansions of this sentence:
Dragging {a small image,a large image,some text} in {an iframe,the root
content document}, with {,no }zooming applied.
In all cases, the drag image/text should appear such that the part under the
cursor is the same as what was under the cursor on the original rendering of
the page.
Differential Revision: https://phabricator.services.mozilla.com/D77436
When rasterizing the drag image, we pick up the resolution from ancestor
presShells and ensure that the drag image is rasterized at that resolution,
with appropriate limits for memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D77435
Make it show the contents of style sheets (as it used to before Stylo)
and make it work in --disable-debug --enable-layout-debugger builds.
Differential Revision: https://phabricator.services.mozilla.com/D76640
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
Even in comm-central and BlueGriffon, `nsISelectionController::*ForDelete()`
are not used. Therefore, we can remove them safely.
Differential Revision: https://phabricator.services.mozilla.com/D72296
This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
Users have much better, easier alternatives, like
DOMWindowUtils.{loadSheetUsingURIString,removeSheet}, which we use to
replace the only caller that exists in mozilla-central (the editor
element, which loads EditorOverride.css).
This allows to clean up the style system and editor. There are other
callers in comm-central, but it seems they can switch to DOMWindowUtils
trivially, as the DOMWindowUtils APIs also use the system principal and
thus they can load any URL.
I'll make sure to give them some time with the migration and/or help
out of course.
Differential Revision: https://phabricator.services.mozilla.com/D71263
Note that we intentionally don't move the SetDisplaySelection stuff to the
runnables. It would probably be safe enough, but it's not required and it makes
reasoning about this code harder.
Differential Revision: https://phabricator.services.mozilla.com/D70183
