A popup attached to a modal parent window doesn't get mouse events
from Gtk as they'are directed to the modal parent. This is usually solved
by pointer grab which that doesn't work on Wayland in our current
setup as it performs show and grab in one step.
We emulate it by setting popup as modal too but then patent
window doesn't get mouse events outside of popup (Bug 1899299).
we need to listen
Surprisingly attaching events handler to mShell fixes it
and we're getting events from both parent and popup windows.
Differential Revision: https://phabricator.services.mozilla.com/D221290
This:
* Works around the WebRender issue from bug 1916599.
* Might be a bit simpler to reason about (the sidebar special-cases to
keep the buttons at the right edge are a bit unfortunate but...).
* Avoids the squishiness that Markus and Sam were discussing in
#gfx-firefox).
There's still some flickering on the <browser> element, but I have a
good idea of how to fix it (basically, we're triggering resizes from
layout, but for remote iframes we really don't want to do that, because
it can cause raciness / flickering as observed).
Differential Revision: https://phabricator.services.mozilla.com/D221351
This looks simpler, a lot smoother on my machine, and shouldn't cause
content resizes. It also doesn't set custom properties on the root which
causes an expensive restyle, specially on big documents (like with many
tabs open).
Maybe eventually we can use view transitions for this, seems like a good
use-case.
We need to move the background to `#sidebar-main` rather than the
wrapper because during the shrinking animation the wrapper is small and
the `#sidebar-main` element would be transparent, which we don't want.
Differential Revision: https://phabricator.services.mozilla.com/D220846
Before this patch, `TelemetryReportChannel(timedChannel, true)` was only called within `nsLoadGroup::TelemetryReport()` when all requests were completed in the load group.
However, `SetDefaultLoadRequest(nullptr)` could be called before this, resulting in `mDefaultLoadRequest` being set to null and causing page load metrics to sometimes not be reported.
To fix this, this patch moves `TelemetryReportChannel(timedChannel, true)` to the point where `mDefaultLoadRequest` is completed.
Differential Revision: https://phabricator.services.mozilla.com/D221597
Changed the scrolling action to the "Open links in apps" option.
The UI test successfully:
- Passed 100x on Firebase API 30
- Passed 100x on Firebase API 34
Differential Revision: https://phabricator.services.mozilla.com/D221791
We were previously running dbus twice: once as part of the X session scripts,
with all the gnome things, and a separate one for our tests and a gnome-keyring
daemon that test-linux.sh runs. By launching dbus before the X session
scripts, they can all share the same bus and firefox in tests can talk to the
other services listening on that bus.
Differential Revision: https://phabricator.services.mozilla.com/D221068
The inactive-property-helper can sometimes be called for properties inside rules
that match pseudo-elements, even though the node being passed is not the pseudo-
element itself.
This happens because the Rules view has a feature whereby selecting, say, a <div>
will show its rules, but also any pseudo-element rules that may be applied that
result in the creation of a pseudo-element inside of it.
So if you have div::before { content: "" } in CSS, then selecting that div will
also show this rule in the Rules view.
This patch adds a check for this case, and when it happens, walks the DOM to
find the right pseudo-element, and then gets its style.
Differential Revision: https://phabricator.services.mozilla.com/D65720
Granted the fine location permission required for the UI test to work properly on API 34.
The UI test successfully:
- Passed 100x on Firebase API 30
- Passed 100x on Firebase API 34
Differential Revision: https://phabricator.services.mozilla.com/D221784
While investigating, I've changed the max API limit to 32 (The snackbar is not displayed for devices running on Android <= 12)
Differential Revision: https://phabricator.services.mozilla.com/D221787
Changing what gets marked after incremental marking validation has computed the
non-incremental marking result can result in failures. The patch disallows this.
Differential Revision: https://phabricator.services.mozilla.com/D221772
Had to remove the scrolling action because the settings menu is not scrollable on the mediumPhone device due to it's larger screen.
The UI test successfully:
- Passed 100x on Firebase API 30
- Passed 100x on Firebase API 34
Differential Revision: https://phabricator.services.mozilla.com/D221799
Had to change the phone app's package name, because of this, it will only run on API 34 from now on.
Successfully passed 100x on Firebase. ✅
Differential Revision: https://phabricator.services.mozilla.com/D221793
Made a related to scrolling on the home screen to the pocket section.
The UI test successfully:
- Passed 100x on Firebase API 30
- Passed 100x on Firebase API 34
Differential Revision: https://phabricator.services.mozilla.com/D221785
The `AwesomeBarFeature` has an `OnEditListener` that always returned
the callback for `onCancelEditing` as true. This resulted in the
`Toolbar` updating it's internal state from `State.EDIT` to
`State.DISPLAY` when no change had happened.
This patch uses the existing state variable to respond to the
callback which mimics the correct behaviour of the AwesomeBar.
Differential Revision: https://phabricator.services.mozilla.com/D221416
Our FxaAccountManager has not have good cached state that lets us
make safe calls to `checkAuthorizationStatus` when an account is in
an unverified/account deleted state. Today, it is safer to wait
until we hear back from `onAuthenticated` first before we check for
auth status.
The visual result to users is that they will see a delay in the
account updates until the network round-trip is complete which is
not great, but better than putting them in more broken states today
as we have begun a cron task this year to delete unverified accounts.
Differential Revision: https://phabricator.services.mozilla.com/D221881
The original Chromium listener code has a few infelicities in its API.
* The current session ID is always available, so the `Nothing()` branch
is impossible. Remove the `Maybe` from the interface.
* If session-change messages for other sessions are received, discard
them early rather than propagating them.
* Use the whole DWORD value supplied by `GUID_SESSION_DISPLAY_STATUS`,
rather than just the first byte. (This has no effect here, since
`MONITOR_DISPLAY_STATE` is an enum with very few values, but might if
someone blindly copies this code with minimal adjustments to be used
with another `PBT_POWERSETTINGCHANGE` value.)
Differential Revision: https://phabricator.services.mozilla.com/D220749
`WinEventHub` was largely taken from Chromium, where its dynamic
connection/disconnection features are presumably more used. We don't
have any need for that, and anyway if we ever do it'll be easy to add
it alongside the static functionality or even migrate the latter over.
Hardwire the relevant message-processing and invocation directly into
the hidden window's WNDPROC, rather than providing a registration
system. Following the discoveries made in bug 1571516, also remove the
additional failure-mode checks added in bug 1852801, reverting to a
crash (which can be unified with 1571516 when it shows up).
This has, as fallout, a minor functional change to the occlusion
tracker: the subfeature prefs mentioned above are now checked at
message-receipt time, rather than at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D220639
Ryan VanderMeulen
Martin Stransky
Daniel Minor
ffxbld
Dimi
Emilio Cobos Álvarez
iorgamgabriel
Butkovits Atila
Ashley Hale
Kershaw Chang
AndiAJ
Dão Gottwald
Julien Cristau
Nicolas Chevobbe
rahulsainani
Tarek Ziadé
Jan Varga
Mark Banner
Jon Coppeard
Mozilla Releng Treescript
mcarare
Sanchaai
Mugurell
Andreas Farre
Jonathan Almeida
Aristide Tossou
Ray Kraesig
Noemi Erli