After bug 1768278 and bug 1767815 there's no more uses of the cliprounded value
in the tree (also it causes artifacts on HiDPI screens so we probably don't
want new usages).
The "sheet" value is unused, and the other values other than "default" and
"none" are only derived from "default", so they don't need to be exposed in the
style system.
Differential Revision: https://phabricator.services.mozilla.com/D145821
Lately nsIPrintSession was only used to pass around RemotePrintJobChild objects.
Now that we pass those objects explicitly where needed (part 1), this class
serves no purpose.
Another reason to want to get rid of this class is that having it as a member
of nsIPrintSettings made no sense and was confusing.
Differential Revision: https://phabricator.services.mozilla.com/D146381
Given how nsIPrintSettings is passed around, stored and copied all over the
place, it's very hard to reason about where and when a RemotePrintJobChild is
needed or valid. This patch avoids all that by explicitly passing a
RemotePrintJobChild when it's needed.
Another reason to make this change is because RemotePrintJobChild really does
not belong on nsIPrintSettings. That interface is supposed to represent a
collection of settings for laying out the document that is to be printed.
Differential Revision: https://phabricator.services.mozilla.com/D146380
Add a Geoclue (version 2) geolocation provider.
This way Firefox can make use of multiple location sources present in the
system, from GNSS provided by a cellular modem or the current network to
location based on visible WiFi networks and 3G tower data, all while
sharing them with other applications.
This is a pure D-Bus-based implementation using a proper state machine, it
does not require any additional dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D145838
Although not needed right now (checkerboarding backgrounds get
a slice anyway due to being a different scroll root), this will
be important for the upcoming work to make backdrop filter
roots implicit. This allows WR to know when slicing up a content
slice if the prim is relevant to the backdrop root.
Differential Revision: https://phabricator.services.mozilla.com/D146145
Add a Geoclue (version 2) geolocation provider.
This way Firefox can make use of multiple location sources present in the
system, from GNSS provided by a cellular modem or the current network to
location based on visible WiFi networks and 3G tower data, all while
sharing them with other applications.
This is a pure D-Bus-based implementation using a proper state machine, it
does not require any additional dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D145838
This occurs since newer GBoard's behaviour seems to be changed.
When `GeckoEditable` receives text change from Gecko, it is possible to remove
composing state if composition is started from first character.
If Gecko's text change by IME, we shouldn't reset text state in `onTextChange`.
`mCausedOnlyByComposition` means that this change is by IME.
Differential Revision: https://phabricator.services.mozilla.com/D146159
There may be added pixels to VA-API decoded surface to keep 16px alignment.
Store the aligned size internaly as widthAligned/heightAligned and use that to create EGLImage only.
Depends on D146084
Differential Revision: https://phabricator.services.mozilla.com/D146085
nsIPrintSettings is supposed to be a collection of settings passed to the
platform code to determine how the document prints. The
isPrintSelectionRBEnabled member doesn't belong here since it is a flag that
is passed to the OS native print settings dialog to tell it whether to
display a "Print selection only" radio button.
Depends on D146232
Differential Revision: https://phabricator.services.mozilla.com/D146251
This per-printer "print_resolution" about:config pref (which ends up in
nsPrintSettings 'mResolution' member-var) is never exposed in UI, and it's
almost entirely unused. For the usages that do exist (usages of
nsPrintSettings::mResolution), we potentially do the wrong thing when the value
comes from an about:config pref, as described in this bug. These usages scale
the printed output *as if we're printing to a printer with the given
resolution*, though of course we have no guarantee of this being the printer's
actual resolution, when this value comes from about:config prefs.
After this patch, nsPrintSettings will simply use the value that we actually
get from the printer, instead of this potentially-bogus value from
about:config. This will avoid the scaling issues described in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D146261
nsIPrintSettings is supposed to be a collection of settings passed to the
platform code to determine how the document prints. The
isPrintSelectionRBEnabled member doesn't belong here since it is a flag that
is passed to the OS native print settings dialog to tell it whether to
display a "Print selection only" radio button.
Differential Revision: https://phabricator.services.mozilla.com/D146251
nsIPrintingPromptService comes from an era when the platform print code would
open the print settings dialog, which defaulted to the OS native dialogs.
Its purpose was to allow that dialog to be overridden by embedders to provide
their own interface for the user to select print settings. Nowadays the
platform print code does not open the dialogs. Instead apps like Firefox are
responsible for getting the print settings to pass to the platform code, and
the platform code provides a way to open the OS native print dialog if they
want to use that (nsIPrintDialogService). So nsIPrintingPromptService no longer
has any purpose, and just adds indirection and needless complexity.
Differential Revision: https://phabricator.services.mozilla.com/D146232
In bug 1762424 we introduced a compositing path using SurfaceControl
to work around an issue on Android 12 where the app would freeze when
attempting to recover from a GPU process crash. However, this caused
bug 1767128. Until we have a proper solution to that, we should
disable the SurfaceControl functionality.
This means on Android 12 the browser will be once again be unable to
recover from a GPU process crash. However, as part of bug 1762424 we
made it so the parent process crashes in this situation rather than
freezing, meaning Android 12 users will be no worse off than having
the GPU process disabled.
Differential Revision: https://phabricator.services.mozilla.com/D146114
Our scrollbar drawing code had various RTL checks for the writing mode.
These checks were busted since bug 1554571 (where the writing-mode of
the scrollbar frames and so on is reset). However, they also wouldn't be
correct (we allow to customize scrollbar position via pref).
Instead, look at the scrollable frame to really know if the scrollbar is
on the right or not. Compute that once in Theme.cpp and pass it around
light we were doing for the "is horizontal" bit.
Differential Revision: https://phabricator.services.mozilla.com/D145865
It tries to query selection with last focused widget. However, if no widget
has gotten focused yet, it causes the warning.
I think that in such case, it should try it with owner widget which is typically
managed by same `PresShell` in these days.
Differential Revision: https://phabricator.services.mozilla.com/D145396
Since bug 1757928 we don't vary the value. If a user were to change this value then the opacity of the swipe to nav ui element would not be in sync with the decision to navigate or not. So remove it so things can't break. The pref widget.swipe.whole-page-pixel-size should be used instead now to control sensitivity.
Differential Revision: https://phabricator.services.mozilla.com/D145828
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
The Album Artist field when talking about musical metadata is the
artist under which a particular release is classified under. Artist is
the people that are on a specific track, including thing like featurings, etc.
Here we only want to set Artist (the most generic item). Album Artist
overrides artist, and has nothing to do with the album name.
Windows doesn't have an API or a location in the UI to display the album
name.
Differential Revision: https://phabricator.services.mozilla.com/D145339
The wl_buffer can be still not resized to double size when the Renderer thread changes
the wl_surface buffer scale to 2 which leads to crash.
Differential Revision: https://phabricator.services.mozilla.com/D145541
The patch for bug 1762875 stops us from calling SwipeTracker::StartAnimation if we are performing a navigation (but still call it if we aren't performing a navigation). This also has the effect of not calling SwipeTracker::SwipeFinished since it is triggered from StartAnimation. This means we don't null out nsBaseWidget::mSwipeTracker from the mWidget.SwipeFinished() call. This means that when the next pan that we want to track as a swipe then when we call nsBaseWidget::TrackScrollEventAsSwipe it will find the existing mSwipeTracker and call mSwipeTracker->CancelSwipe(), which sends a MozSwipeGestureEnd event. It would be okay if we didn't send the MozSwipeGestureEnd event in the case of a succesful navigation, the MozSwipeGesture event can serve the same purpose, but to send a MozSwipeGestureEnd when the _next_ swipe gesture is started does not seem like a good idea.
I noticed this while writing the test for bug 1762875.
To fix it just call SwipeFinished immediately when we get a successful swipe navigation. There are two side effects to consider: nulling out mSwipeTracker on the widget, and sending the MozSwipeGestureEnd event.
Nulling out mSwipeTracker on the widget seems fine, it's only there to track ongoing swipes. Since the current swipe is finished we don't need it anymore. However it brought up an issue where existing tests in widget/tests/browser/browser_test_swipe_gesture.js started failing. A test would finished immediately after a successful swipe navigation, remove the tab, and move on to the next test before the fade out animation could run. If the fade out animation had finished it would have called removeBoxes and removed the dom elements for the visual swipe arrows. So they stick around instead. Removing the tab seems to have disconnected these elements from the DOM. The structure above the swipe elements goes up to the hbox created here https://searchfox.org/mozilla-central/rev/dd404f43c7198b1076fe5d7e05b1e6b1a03bdfeb/browser/base/content/tabbrowser.js#2182 I don't know the tabbrowser code but I'm guessing that gets removed on removing a tab. So in order to fix this we always remove and re-create the boxes when we start a new animation. It should be safe to always do this and remove the isAnimationRunning early exit because we don't call startAnimation when we get a MozSwipeGestureStart event, so we should always want to start fresh when we get that event.
Sending the MozSwipeGestureEnd event means we need to be a bit more careful in stopAnimation. We don't want to do anything in stopAnimation if we are already stopping animation because the fade out will handle it, so we add a early return so that another stopAnimation call (which can come from a MozSwipeGestureEnd) won't cut off the animation prematurely.
Differential Revision: https://phabricator.services.mozilla.com/D145545
There are two completely separately mechanisms that fade the UI element, one drives the fade out if a navigation was successful, one drives the animation if navigation did not happen.
If navigation is successful the animation is handled by browser/base/content/browser-gestureSupport.js. If navigation is not succesful the animation is handled by widget/SwipeTracker.cpp. I'm not sure why it was done that way.
If navigation is unsuccessful the opacity gets updated the same way as during the gesture: by sending eSwipeGestureUpdate events and putting the opacity amount on the event.
If navigation is successfull we send the eSwipeGesture event. This causes us to call gHistorySwipeAnimation.stopAnimation() at https://searchfox.org/mozilla-central/rev/26a1b0fce12e6dd495a954c542bb1e7bd6e0d548/browser/base/content/browser-gestureSupport.js#449 which https://searchfox.org/mozilla-central/rev/26a1b0fce12e6dd495a954c542bb1e7bd6e0d548/browser/base/content/browser-gestureSupport.js#706 sets this._isStoppingAnimation = true and sets a transition on the element and then sets the opacity to 0. The _isStoppingAnimation part makes us ignore anymore incoming swipe gesture updates that SwipeTracker.cpp is sending, and then after the transition is finished is removes the boxes so isAnimationRunning() returns false which blocks the swipe gesture updates from having any effect after the transition.
However, when the SwipeTracker.cpp animation finishes it sends a eSwipeGestureEnd which browser-gestureSupport.js does not ignore. So don't start the SwipeTracker animation in the case where we don't need it.
Differential Revision: https://phabricator.services.mozilla.com/D142820
stransky
criss
sotaro
Emilio Cobos Álvarez
Andrew McCreight
David Parks
Butkovits Atila
Edgar Chen
Jonathan Watt
Maciej S. Szmigiero
Glenn Watson
Makoto Kato
Andrew Osmond
Iulian Moraru
Daniel Holbert
Cristian Tuns
Jamie Nicol
Bas Schouten
Paul Adenot
Narcis Beleuzu
Molly Howell
Jan Horak
Masayuki Nakano
Timothy Nikkel
Cosmin Sabou
Neil Deakin
Noemi Erli