Also separate the alignment of the position and size to allow moving the displayport in much larger increments without increasing the displayport size which regresses tscrollx and generally increases webrender's CPU load.
Differential Revision: https://phabricator.services.mozilla.com/D77870
This is a short-term step to ensure all tests pass with the mvm pref
turned on. It disables the visual viewport setting codepath for visual-only
MVM instances, unless the APZ zooming pref is also set (because other APZ
zooming code relies on this).
Differential Revision: https://phabricator.services.mozilla.com/D79229
If there's no meta-viewport handling, the MVM shouldn't need to do reflows
because it shouldn't be changing the layout viewport. Also there should be
no need for the MVM to adjust the resolution on the presShell since the
user will be driving those changes via user input. The MVM now just updates
the visual viewport sizing in response to changes.
It may turn out that some these conditions need to be tweaked later, but for
now this seems like a reasonable starting point.
Differential Revision: https://phabricator.services.mozilla.com/D79226
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
The first page's content viewer is only saved in the bfcache when the second
page is painted. This can happen after the load event is fired, and in that
scenario, attempting to go back to the first page will reload it rather than
restore it from the bfcache. So for the test to work properly it needs to
wait until the second page is actually painted before it attempts go back.
Differential Revision: https://phabricator.services.mozilla.com/D79347
Those methods have two sources to check after call: the return value and the pointer. This can be confusing as a caller may think they should check both when they don't need to. Since the two always behaves together (a valid pointer + NS_OK, or nullptr + NS_ERROR_FAILURE), this replaces the return value with the pointer.
Differential Revision: https://phabricator.services.mozilla.com/D79196
The current notification enumerates all windows and calls
SysColorChanged on them.
The current implementation of SysColorChanged is not quite sound, as it
really needs most if not all of what ThemeChanged does: SVGs can use
system colors, so we need to also invalidate the image cache for
example.
It's also not clear it deals correctly with propagating system color
changes to other documents.
In some cases we were even firing both theme changes and system color
changes at the same time. Unify this code paths.
Differential Revision: https://phabricator.services.mozilla.com/D76487
This patch was largely automated. It was generated by manually
editing .eslintrc.js and then running mach eslint layout --fix.
Additionally, this includes manual changes to test_bug533845.xhtml
and test_bug467442.xhtml that were necessary to appease eslint.
Differential Revision: https://phabricator.services.mozilla.com/D78615
One note about this solution: it includes the apz callback transform for the root scroll frame of the root content document, but no other apz callback transform that might be on an ancestor of the select element.
Differential Revision: https://phabricator.services.mozilla.com/D78026
And use the duplicated one at the places where we need the expanded size for
interactions with the dynamic toolbar on the compositor. The new function will
be modified in the next commit.
Note that the only one remaining call site of ExpandHeightForViewportUnits is
for window.inner{Width,Height}. For window.inner{Width,Height} we don't yet
return the layout viewport (which might be expanded by the minimum-scale), it's
going to be fixed in bug 1598487 [1], but it's not ready to fix because there
also need fixes in comm-central (see dependencies in the bug). So for now, we
should keep the current behavior for window.inner{Width,Height}.
Also note that it's not yet clear whether we will eventually replace the last
call site of ExpandHeightForViewportUnits with ExpandHeightForDynamicToolbar
since the value corresponding to the dynamic toolbar might _NOT_ be affected by
the minimum-scale in some cases. See bug 1641166 for details.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1598487
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1641166
Differential Revision: https://phabricator.services.mozilla.com/D78440
This uses "None" instead of "NotSpecified" as the value for
mLastSmoothScrollOrigin when there is no smooth scroll in progress.
Depends on D78439
Differential Revision: https://phabricator.services.mozilla.com/D78469
This adds a new scroll origin, None, which is used as the initial value for
mLastScrollOrigin. Unlike Other, this scroll origin can be clobbered by any
other scroll origin, including notably Relative. This means that on a
brand-new scrollframe, if the first scroll call comes in with an origin of
Relative, it will be preserved as a relative scroll instead of getting
converted to a non-relative scroll.
This in turn fixes a latent bug in the code that was exposed by the
test_relative_update.html APZ mochitest when run with apz.allow_zooming=true.
Note also that we should never be passing eNone to functions like ScrollToImpl;
for those scenarios we continue using Unknown if we don't have a more specific
scroll origin to use. In other words, None is a sort of sentinel value to be
used for class fields, and is not to be used for actual scrollto-type calls.
Differential Revision: https://phabricator.services.mozilla.com/D78439
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
nsRefreshDriver's NotifyVsync method had some slightly convoluted logic: Based on the thread it is called from, it would guess whether it is called from a vsync source, in which case it would schedule itself onto the main thread, or from the self-scheduled task, in which case it would perform work.
This just splits the two: NotifyVsync only takes care of VsyncSource, and schedules a task that calls the tick logic. This also allows Wayland to run the VsyncSource off the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D77044
The probes collect counts for:
- print preview open, and exit without print
- print dialog opened from print preview, and cancelled
- print dialog opened without print preview, and cancelled
- silent prints
- print target
- PDF file
- XPS file
- other (probably print to physical printer, but we can never be sure)
There is some overlap with the existing PRINT_* probes, but I think we should
keep those in place temporarily until we confirm that the new probes produce
numbers that are consistent with the old probes.
This patch only adds 'print target' probes for Windows and macOS.
I use nsDeviceContextSpec*::Init() to collect the 'print target' telemetry
because the way we initialize settings from prefs (and the way macOS works in
particular) make it difficult to reliably determine the target type earlier in
the print process for all possible entry points into the printing code.
Differential Revision: https://phabricator.services.mozilla.com/D78033
If we called PaintFrame for drawWindow or something other than painting to the widget the visual scroll update won't make it to the compositor, so don't clear it.
This doesn't fix anything specifically, just noticed it while reading code.
Differential Revision: https://phabricator.services.mozilla.com/D76781
This is to prevent the assertion at the beginning of
DrainExcessOverflowContainersList().
The invariant is described in the comment revised in this patch. That
is, "only one overflow containers list exists for a given frame: either
its own OverflowContainersProperty or its prev-in-flow's
ExcessOverflowContainersProperty, not both."
Differential Revision: https://phabricator.services.mozilla.com/D77328
This is to prevent the assertion at the beginning of
DrainExcessOverflowContainersList().
The invariant is described in the comment revised in this patch. That
is, "only one overflow containers list exists for a given frame: either
its own OverflowContainersProperty or its prev-in-flow's
ExcessOverflowContainersProperty, not both."
Differential Revision: https://phabricator.services.mozilla.com/D77328
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
The viewport units size doesn't match the aspect ratio of the screen size in
some cases.
For example, in the case of the reftest in this commit, the meta viewport is
"width=1600, height=device-height" and the screen size during reftest is
"800x1000". Thus the viewport units size will be "1600x1000". In such cases
with the old way ExpandHeightForViewportUnits shrinks the given size
"1600x1800" to "1600x1000" with 100px dynamic toolbar max height (and the
MOZ_ASSERT in the function happens on debug builds).
Differential Revision: https://phabricator.services.mozilla.com/D77176
- Implement the nsPrinterEnumeratorX
- Enable the contract @mozilla.org/gfx/printerenumerator;1 for macOS
- Add test for default printer name.
- Remove restrictions preventing some tests from running on macOS
Differential Revision: https://phabricator.services.mozilla.com/D76356
