The GPU process is destroyed in `ShutdownPhase::XPCOMShutdown` thus we shall not try to create it if we are in or beyond that phase.
Actually we might want to consider to block the creation even earlier if it does not exist, maybe from `ShutdownPhase::AppShutdown`, but this patch wants to just repair the crashes.
Differential Revision: https://phabricator.services.mozilla.com/D143349
I tested client all the way back to Ubuntu 18 LTS and seems to work
fine, any reason not to try this?
This fixes some weird overdrawing on the window corners on GNOME+X11.
Differential Revision: https://phabricator.services.mozilla.com/D139556
This was added because ElementaryOS themes have bright selected
backgrounds and dark text (for light themes), but we use the accent
colors for some places where that is not appropriate and a darker color
is, like checkbox backgrounds or form control borders.
Bug 1741293 split the selected item text / background colors from the
accent colors, so now we can use the real selected item colors and only
do this on the accent color. I wanted to split this out from bug 1741293
to minimize behavior changes in there.
Also while at it, blend opaque foreground with the appropriate
background on EnsureColorPairIsOpaque.
Differential Revision: https://phabricator.services.mozilla.com/D143255
Newer Intel drivers break our assumptions about the bottom four digits
being the build id and we end up blocking newer drivers with build ids
like 11404. This reverts the change in bug 1295902 which changed this
blocklist rule to only look at the build number. I think bug 1295902 was
just trying to be more correct and I don't know that it actually blocks
important crashes. Decoding now mostly happens in the GPU process
so the impact of these crashes is reduced from what it originally was.
The information on how to interpret Intel driver version is from:
https://www.intel.ca/content/www/ca/en/support/articles/000005654/graphics.html
The proper fix is to have Intel specific driver version parsing.
Differential Revision: https://phabricator.services.mozilla.com/D143248
Cleans up the interface to AudioSession and brings in line with COM best practices. Uses background threads that are implicitly MTA and asserts proper thread behavior. This also removes AudioSession's Co[Un]Initialize static analysis violations.
Differential Revision: https://phabricator.services.mozilla.com/D140741
It's possible that moz_container_wayland_frame_callback_handler() is called after unmap event if we draw to parent surface so don't assert there.
Differential Revision: https://phabricator.services.mozilla.com/D143167
For example, the SDK class android.media.MediaDrm$KeyStatus will now
be defined as MediaDrm::KeyStatus rather than just KeyStatus.
Not only does this avoid polluting the top-level namespace, but it
also avoids a bug where invalid type names were generated if the
nested class contains a method with a parameter or return of the outer
class' type.
Differential Revision: https://phabricator.services.mozilla.com/D143043
GTK3 doesn't have accent colors per se so we reuse the "selected item"
colors.
However, GTK4 does, and dark and light accent colors in libadwaita are
the same, so special-case Adwaita to copy the colors from the light
theme.
Differential Revision: https://phabricator.services.mozilla.com/D143064
It's designed for caching content information of focused editor. However, at
sending focus notification to the main process, the editor may have already
been blurred but `IMEContentObserver` may have not known it yet. In this edge
case, only query selection succeeds since IMEContentObserver still has a cache,
but query the others failed because of root content node check of
`IMEContentObserver::HandleQueryContentEvent`. If a content process meets this
case, it should not send focus notification and stop storing the content since
IME shouldn't get focus nor query non-editable content.
On the other hand, the reported testcase reproduces this with a fuzzing API
called **in** the content process. Therefore, I have no idea how to reproduce
it without the API. That's the reason why this patch does not contain new tests.
Differential Revision: https://phabricator.services.mozilla.com/D141821
Bug 1753146 doubled the success threshold for Windows only, but browser/base/content/browser-gestureSupport.js at https://searchfox.org/mozilla-central/rev/26a1b0fce12e6dd495a954c542bb1e7bd6e0d548/browser/base/content/browser-gestureSupport.js#739 multiplies the values present in swipe events by 4 to determine opacity; so it it assuming the value 0.25 is the success threshold.
This patch first reverts bug 1753146 and then fixes it in a different way, so that the success threshold still has the same value and hence we don't need to modify browser-gestureSupport.js (so that all the code depending on this is in one one). We double the kWholePagePixelSize on Windows (and turn it into a pref) so that we don't regress bug 1753146. This is equivalent because the numeric value computed in SwipeTracker::ComputeSwipeSuccess will be the same, since the values mGestureAmount and mCurrentVelocity all have a division by kWholePagePixelSize when they are computed in SwipeTracker::ProcessEvent. There is one difference though: the velocity twitch tolerance comparison in SwipeTracker::ComputeSwipeSuccess will be slightly different. I think that's okay though.
Differential Revision: https://phabricator.services.mozilla.com/D140185
Otherwise we can return without the widget even seeing the event. This is how other test functions are implemented.
We need this to make the test in bug 1757928 pass.
Differential Revision: https://phabricator.services.mozilla.com/D142943
When not using move-to-rect we're not making decisions on positioning,
and thus layout should already be aware of the correct bounds. There
should be no need to propagate the extra changes.
This would've fixed the issue as well (for non-flipped popups, that is),
but the previous patch is still a requirement for flipped popups.
Differential Revision: https://phabricator.services.mozilla.com/D142680
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
On Android version 12, it appears as if the EGL context does not
correctly get detached from a Surface when its process dies. This
means that subsequent attempts to create an EGL context fail, meaning
we cannot render anything.
This results in a completely unusable browser following a GPU process
crash, which is worse than the alternative of a parent process crash.
Block the GPU process on Android 12 and above until we have found a
workaround.
Differential Revision: https://phabricator.services.mozilla.com/D142452
This is a follow-up for bug1760464, we observed more crashes from devices which we didn't added to the block list before.
Therefore, we decided to block all Haswell GPUs for VP8 HW decoding (Intel supports that sine Broadwell) and a certain version of Intel driver.
Differential Revision: https://phabricator.services.mozilla.com/D142360
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
When using Android with physical keyboard, IME's candidate window is sometimes
misplaced. Some IME/keyboards require insertion marker location to set IME's
candidate window position.
So we should set it from caret rectangle.
Differential Revision: https://phabricator.services.mozilla.com/D141931
Also add better docs as to why we're doing what we're doing.
Also, avoid calling LoadCursor for built-in cursors over and over in chrome
pages.
Differential Revision: https://phabricator.services.mozilla.com/D142067
Use mMoveToRectPopupRect popup constrains in nsMenuPopupFrame::SetPopupPosition only and make it pernament.
In such setup works as screen size constraints.
Don't call SetPopupPosition from move-to-rect callback and let layout code to handle that.
Remove MoveToRectPopupRectClear() as it's not needed, we keep mMoveToRectPopupRect
in nsMenuPopupFrame as well as we keep screen sizes there.
Differential Revision: https://phabricator.services.mozilla.com/D141602
Due to move-to-rect limitations (https://gitlab.gnome.org/GNOME/gtk/-/issues/1986) we try to avoid it when it's possible.
- Use plain popup resize/movement when popup is places inside of application toplevel window.
- Hide moved/scaled popup window only when move-to-rect is used.
- Clear mMoveToRectPopupRect before any move/resize and use Wayland compositor to place/size the window.
Differential Revision: https://phabricator.services.mozilla.com/D141601
Use mMoveToRectPopupRect popup constrains in nsMenuPopupFrame::SetPopupPosition only and make it pernament.
In such setup works as screen size constraints.
Don't call SetPopupPosition from move-to-rect callback and let layout code to handle that.
Remove MoveToRectPopupRectClear() as it's not needed, we keep mMoveToRectPopupRect
in nsMenuPopupFrame as well as we keep screen sizes there.
Differential Revision: https://phabricator.services.mozilla.com/D141602
Due to move-to-rect limitations (https://gitlab.gnome.org/GNOME/gtk/-/issues/1986) we try to avoid it when it's possible.
- Use plain popup resize/movement when popup is places inside of application toplevel window.
- Hide moved/scaled popup window only when move-to-rect is used.
- Clear mMoveToRectPopupRect before any move/resize and use Wayland compositor to place/size the window.
Differential Revision: https://phabricator.services.mozilla.com/D141601
This matches Chrome behavior. Our video-dynamic-range media query also relies
on this value being greater than 24 in order to report "high" level support.
Differential Revision: https://phabricator.services.mozilla.com/D141306
This matches Chrome behavior. Our video-dynamic-range media query also relies
on this value being greater than 24 in order to report "high" level support.
Differential Revision: https://phabricator.services.mozilla.com/D141306
Bug 1724120 apparently regressed this, which is a bit surprising because
the redundant ::SetCursor() call is already there. The real fix is the
one above, however I think this change is still worth it. Make cursor
updates avoid redundant ::SetCursor() calls the same way other widget
back-ends do (always except for mUpdateCursor, which is set on scale
changes and so on).
Differential Revision: https://phabricator.services.mozilla.com/D141864
Chrome code should be able to rely on CSS pixel * devicePixelRatio =
device pixel.
Chrome code that cares about the override should use
BrowsingContext.overrideDPPX. We were exposing the no-override value in
WindowUtils but that's unneeded now.
Differential Revision: https://phabricator.services.mozilla.com/D141323
This matches Chrome behavior. Our video-dynamic-range media query also relies
on this value being greater than 24 in order to report "high" level support.
Differential Revision: https://phabricator.services.mozilla.com/D141306
In bug 1756700 we delayed initializing the compositor on android. A
consequence of this is that when
LayerViewSupport::SetDefaultClearColor() gets called
mUiCompositorControllerChild is still null, meaning we skip setting
the compositor's clear color. As a result, dark-mode fenix users have
once again started seeing white flashes while waiting for the page to
load.
Additionally, when the compositor is re-initialized (following a
fallback to software rendering, or a GPU process restart) we do not
set the clear color for the new compositor, which again can lead to
white flashes.
To fix both of these issues, this patch makes us cache the color value
passed to LayerViewSupport::SetDefaultClearColor(). Then whenever
LayerViewSupport::NotifyCompositorCreated() is called, we call
UiCompositorControllerChild::SetDefaultClearColor() to ensure the new
compositor uses the correct clear color.
Differential Revision: https://phabricator.services.mozilla.com/D141730
We don't need mMoveToRectPopupRectCleared field any more - we always calculate popup placement when a change comes from layout.
Differential Revision: https://phabricator.services.mozilla.com/D141429
Take popup resize shortcut only when popup is placed inside parent window (check popup origin) and it's not moved by layout.
Fix gdk_window_get_width/gdk_window_get_height mismatch.
Differential Revision: https://phabricator.services.mozilla.com/D141428
Rename PreferredPopupRect* methods/attributes to MoveToRectPopupRect* ones as it holds info about coordinates received from move-to-rect popup placement done by Wayland compositor.
Differential Revision: https://phabricator.services.mozilla.com/D141425
In bug 1756700 we delayed initializing the compositor on android. A
consequence of this is that when
LayerViewSupport::SetDefaultClearColor() gets called
mUiCompositorControllerChild is still null, meaning we skip setting
the compositor's clear color. As a result, dark-mode fenix users have
once again started seeing white flashes while waiting for the page to
load.
Additionally, when the compositor is re-initialized (following a
fallback to software rendering, or a GPU process restart) we do not
set the clear color for the new compositor, which again can lead to
white flashes.
To fix both of these issues, this patch makes us cache the color value
passed to LayerViewSupport::SetDefaultClearColor(). Then whenever
LayerViewSupport::NotifyCompositorCreated() is called, we call
UiCompositorControllerChild::SetDefaultClearColor() to ensure the new
compositor uses the correct clear color.
Differential Revision: https://phabricator.services.mozilla.com/D141730
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
When a popup is only resized (and not moved), we need original move-to-rect setup from layout from previous popup placement to replicate move-to-rect call with updated size.
We can't get complete popup setup from layout for resize only event. It's because we use nsMenuPopupFrame::MoveTo() to place popup from move-to-rect callback (which happened before the resize event) and such direct popup move temporary change popup anchor type to point as we place popup to specified location from move-to-rect callback.
Differential Revision: https://phabricator.services.mozilla.com/D141424
`IMEContentObserver` observes the text node change which contains the current
composition string. Therefore, it can let `TextComposition` know where is
updated by web apps and adjust offset and length in the text node.
Differential Revision: https://phabricator.services.mozilla.com/D141193
This will be used to avoid problematic includes from WorkerPrivate.h,
and it matches the behavior of RefPtr<> and WeakPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D140658
This allows themes to override our light / dark theme heuristics if they
choose to, so that we don't have to complicate the heuristics too much.
This is specially useful for themes with images, where the image might
be "light", but still have enough contrast with light text. A good
example is the theme mentioned in bug 1749837 comment 0.
The semantics are:
* color_scheme: If set, overrides the general "toolbar theme" (so
window and context menu appearance and so on), otherwise we fall back
to heuristics.
* content_color_scheme: If set, overrides the color scheme for the
content area. Otherwise we fall back to color_scheme if present, or
heuristics otherwise.
One thing that I didn't include was a sort of "system" option, which
might be useful to say "this theme is neutral, and works both for light
and dark themes". Let me know if you think that's a must-have, otherwise
I think it's probably worth deferring to a follow-up if it's needed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D136354
This will be used to avoid problematic includes from WorkerPrivate.h,
and it matches the behavior of RefPtr<> and WeakPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D140658
The presenting issue is that each background task's audio session is
user-visible via various Windows UIs that display "volume controls" or
"volume mixers"; this avoids that.
Differential Revision: https://phabricator.services.mozilla.com/D141101
Jens Stutte
Emilio Cobos Álvarez
Jeff Muizelaar
Shazib Summar
sotaro
stransky
Jamie Nicol
Masayuki Nakano
Stephen A Pohl
Timothy Nikkel
Alexandre Lissy
Bryce Seager van Dyk
Jonathan Watt
Marian-Vasile Laza
Cristian Tuns
alwu
Iulian Moraru
Makoto Kato
Gian-Carlo Pascutto
Max Vollmer
Norisz Fay
Brad Werth
criss
Butkovits Atila
Andrew Osmond
smolnar
Randell Jesup
Ben Hearsum
Nick Alexander
Noemi Erli