This patch adds a new checkbox to the print UI for two-sided printing.
The checkbox is only visible if the currently selected printer supports
two-sided printing.
Notable Changes:
- Add new section and checkbox for two-sided printing.
- Add new getter to settings proxy for supportsDuplex.
- Add new setter/getter to settings proxy for printDuplex.
- Add new test for no duplex with PDF printer.
- Add new test for toggle duplex in portrait orientation.
- Add new test for toggle duplex in landscape orientation.
- Add new test for toggle orientation with duplex checked.
- Correctly set duple mode in GTK print settings.
Depends on D94026
Differential Revision: https://phabricator.services.mozilla.com/D93621
This patch adds a new checkbox to the print UI for two-sided printing.
The checkbox is only visible if the currently selected printer supports
two-sided printing.
Notable Changes:
- Add new section and checkbox for two-sided printing.
- Add new getter to settings proxy for supportsDuplex.
- Add new setter/getter to settings proxy for printDuplex.
- Add new test for no duplex with PDF printer.
- Add new test for toggle duplex in portrait orientation.
- Add new test for toggle duplex in landscape orientation.
- Add new test for toggle orientation with duplex checked.
- Correctly set duple mode in GTK print settings.
Depends on D94026
Differential Revision: https://phabricator.services.mozilla.com/D93621
This change has a couple of tests but they are for scrollable/non-scrollable
contents, they are not for non-scrollable contents but covered by the dynamic
toolbar cases, e.g. 100vh body element. Those cases will be introduced in the
subsequent change.
Differential Revision: https://phabricator.services.mozilla.com/D93915
Since we no longer are using the PaperList or CreateDefaultSettings methods on
nsPrinterBase, and we can remove them from nsPrinterBase.
This should dramatically improve latency when the remote printer is not
available, or when the print server is slower. In the best-case scenario it may
increase the latency to displaying the print preview somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D94482
This also changes the frontend to use this interface.
This will be a bit less efficient in the general case, as it will serialize the
PaperList and DefaultSettings fetches. But most of the large delays seem to
occur when the print server is slow to respond, and ultimately using a single
live connection for both these requests when possible (particularly with CUPS)
should improve the total latency when the printer or print server is not
available, or is very slow.
Differential Revision: https://phabricator.services.mozilla.com/D93688
This implements the following three things:
- use the frame callback timestamp. While there are few guarantees about
its behaviour, it still seems to make sense to use it assuming: a) the compositor
uses monotonic system time (we do a simple sanity check) b) the compositor is
more likely to run at high priority, thus making the offset from the actual
vsync less jittery c) the timestamp is closer to the actual vsync event,
making it more fitting for how we use it internally
- implement a very simplistic estimate of the refresh interval.
Since bug 1653737 WR takes an estimated next output time to optimize
for. Until now this was hardcoded to 16.6ms from the last `Now()`. Now
we adjust the value on each interval slightly, making it much more
precise on non-60Hz refresh rates (this certainly can get improved more)
- Shuffle around mutex looking a bit, making sure we don't hold it
while calling `NotifyVsync()`. That should make it less likely to run
into deadlock conditions.
Depends on D95515
Differential Revision: https://phabricator.services.mozilla.com/D93169
Wayland protocol does not include a mechanism how to inform compositor about deleted frame callbacks.
We delete a callback only locally on client side and it remains active at server (compositor) side.
When large amount of callbacks is accumulated at server Firefox is closed due to OOM
so we need to keep frame callback on local side untill is fired and don't create a new one.
Differential Revision: https://phabricator.services.mozilla.com/D95678
What's implemented in this patch doesn't match the spec to 100%, but it comes
pretty close. This patch is cutting two corners: We're only using one shadow
instead of two, and we're using a smaller blur radius (2 instead of 2 and 4).
Both adjustments are done to improve performance; blurring is a computationally
expensive operation, so we should minimize its cost.
As the shadow color, I'm using a transparent black instead of a transparent
gray, because this makes it easier to do the blurring on an A8 surface rather
than on a full RGBA surface, given the current Moz2D API.
Differential Revision: https://phabricator.services.mozilla.com/D95090
The Mac theme will need this to check for RTL, and for whether the scrollbar has
the hover attribute, and for whether the scrollbar is on a dark background.
It looks like the philosophy of the virtual DrawScrollbar* methods was to supply
narrow pieces of information, instead of the frame itself. So this patch undoes
that separation of concerns.
In theory, we could grab the three pieces of state in
nsNativeBasicTheme::DrawWidgetBackground, but then we'd do a bunch of
computations (especially the "dark background" check) unnecessarily on platforms
that don't need them.
Differential Revision: https://phabricator.services.mozilla.com/D95077
This causes the generated scroll events to be turned into PanGestureInput events
instead of ScrollWheelInput events. This exercises different codepaths that are
more representative of real-world behaviour on mac laptops. This patch also
allows a pref to flip the behaviour back to the old behaviour of triggering
ScrollWheelInputs, since in some cases we may want to test that behaviour
explicitly.
Depends on D95320
Differential Revision: https://phabricator.services.mozilla.com/D95321
Apparently objective-C doesn't do a great job when you give a vararg function
that takes int32_t arguments double values. I guess tests that use macOS
synthesized wheel inputs were basically only working by accident.
Differential Revision: https://phabricator.services.mozilla.com/D95320
Most of this patch is a dance to avoid size flickering of the skeleton UI
window. We change all Resize/Move/SetSizeMode calls from before the first
nsWindow::Show call. Normally those have no effect, since the window isn't
shown yet, and if the window is not maximized, they typically match the
sizes we've gotten out of the registry anyway. However, if we are maximized,
then they produce a lot of visual noise. We can however achieve the desired
effect by just calling SetWindowPlacement.
Similarly, we switch the window styles of the skeleton UI window to match those
of the toplevel Windows window, and adjust the client rect from our window proc
in a way that matches the adjustments in nsWindow in the WM_NCCALCSIZE handler.
We do this because otherwise we get a flicker as soon as we change the styles
and nonclient margins as the fake chrome pops up and then back down.
Lastly we also change the extended window styles so that they match. We
historically added WS_EX_TOOLWINDOW here to hide the toolbar entry, because it
would otherwise switch out to a new toolbar entry when we changed the window
styles. However since our new styles match, we no longer need to do this. It
was also causing the maximized window to paint over the Windows taskbar.
Differential Revision: https://phabricator.services.mozilla.com/D93534
Most of this patch is a dance to avoid size flickering of the skeleton UI
window. We change all Resize/Move/SetSizeMode calls from before the first
nsWindow::Show call. Normally those have no effect, since the window isn't
shown yet, and if the window is not maximized, they typically match the
sizes we've gotten out of the registry anyway. However, if we are maximized,
then they produce a lot of visual noise. We can however achieve the desired
effect by just calling SetWindowPlacement.
Similarly, we switch the window styles of the skeleton UI window to match those
of the toplevel Windows window, and adjust the client rect from our window proc
in a way that matches the adjustments in nsWindow in the WM_NCCALCSIZE handler.
We do this because otherwise we get a flicker as soon as we change the styles
and nonclient margins as the fake chrome pops up and then back down.
Lastly we also change the extended window styles so that they match. We
historically added WS_EX_TOOLWINDOW here to hide the toolbar entry, because it
would otherwise switch out to a new toolbar entry when we changed the window
styles. However since our new styles match, we no longer need to do this. It
was also causing the maximized window to paint over the Windows taskbar.
Differential Revision: https://phabricator.services.mozilla.com/D93534
We should be able to use CTFontCreateCopyWithAttributes for non-system fonts
because we don't need to worry about them changing. This avoids the leaks
caused by going through a CGFont.
Differential Revision: https://phabricator.services.mozilla.com/D94772
- Make WaylandAllocateShmMemory() fallible.
- Implement WaylandReAllocateShmMemory() to re-allocate Shm pool.
- Remove WaylandShmPool::Resize() and use WaylandShmPool::Create() only.
- Implement and use WaylandShmPool::Release().
- Make WindowSurfaceWayland::CreateWaylandBuffer() as fallible.
Differential Revision: https://phabricator.services.mozilla.com/D94735
We do it in nsDeviceContextSpecG since that's what actually consumes the
settings. On GTK the options need to be prefixed by cups- for some
reason in order to work, so factor out a macro listing the options and
do the NSString / cups- prefixing in the platform specific places.
Differential Revision: https://phabricator.services.mozilla.com/D94479
This makes the disabled state look good because the track pieces are no longer
visible behind the partially-transparent disabled thumb.
Differential Revision: https://phabricator.services.mozilla.com/D94701
This feels a bit nicer but the difference isn't visible to the user.
But it demonstrates how we can fix progress bars.
Differential Revision: https://phabricator.services.mozilla.com/D94699
This removes some duplication and replaces it with a bool aHorizontal parameter.
It also splits out scroll corner drawing into its own method.
And it consistently passes down the DPI ratio into all methods.
Drive-by fixes:
- The border of horizontal scrollbars in the default theme now scales with the
DPI ratio.
- The border is device-pixel aligned by insetting the stroked rectangle by
half the stroke width.
This patch also changes the scroll corner drawing in the default theme to no
longer draw a border on the left. We can revert that if needed
Differential Revision: https://phabricator.services.mozilla.com/D94662
Erik Nordin
Razvan Maries
Nika Layzell
Sylvestre Ledru
Hiroyuki Ikezoe
Emily McDonough
Markus Stange
Neil Deakin
Robert Mader
stransky
tobar2018
Bob Owen
Emilio Cobos Álvarez
Kartikaya Gupta
Nicolas Silva
Doug Thayer
Andrew Osmond
Butkovits Atila
Kagami Sascha Rosylight
Jeff Muizelaar
Mike Conley
Aaron Klotz
Mihai Alexandru Michis