This is not confirmed to be the start of the crash but the crashes are at
startup and this could happen if the check came before a window was
registered.
Differential Revision: https://phabricator.services.mozilla.com/D284338
We only need to grab its AppWindow for that to happen. Save some useless
QI while at it.
I'm pretty sure bug 2002986 would also help here but this seems worth
doing regardless.
Differential Revision: https://phabricator.services.mozilla.com/D274419
Also turned off using the Windows App SDK in mingw since that seems to
be the pattern we follow for other advanced Windows features.
Also fixex win64-st-autotest build, and fixes another mingw bustage
in TestFile.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D267643
On opt-talos-xperf, the Windows App SDK fails
calling DCompositionCreateDevice3() with ERROR_ACCESS_DENIED,
and the code assumes it is going to succeed so it proceeds to crash
deferencing null.
We haven't seen this crash anywhere else, and so I suspect this has
something to do with the way Firefox is being run there. So add a pref
to turn off using the Windows App SDK for just this test.
If this turns out to cause crashes in other situations, we should figure
out what the situation is and try to fix it.
Differential Revision: https://phabricator.services.mozilla.com/D267040
This essentially reverts bug 1934040, as that attempted to deal with
the problem of the wrong titlebar height with Mica on by not setting the
WS_SYSMENU style. However, this caused problems like this bug, where
taskbar windows couldn't be right-clicked on.
Now we accomplish the same thing by calling into the Windows App SDK to
set ExtendsContentIntoTitleBar and PreferredHeightOption appropriately.
This is done in WindowsUIUtils::SetIsTitlebarCollapsed(); the rest of this
change is almost entirely the revert of bug 1934040.
Differential Revision: https://phabricator.services.mozilla.com/D263604
This reverts commit 032488ff11.
Revert "Bug 1947324 part 2 - make Windows Firefox builds depend on the Windows App SDK r=glandium"
This reverts commit 1ebdc110f2.
Revert "Bug 1947324 part 1 - "build" Windows App SDK on toolchain tasks r=glandium"
This reverts commit 37b6a1f956.
This essentially reverts bug 1934040, as that attempted to deal with
the problem of the wrong titlebar height with Mica on by not setting the
WS_SYSMENU style. However, this caused problems like this bug, where
taskbar windows couldn't be right-clicked on.
Now we accomplish the same thing by calling into the Windows App SDK to
set ExtendsContentIntoTitleBar and PreferredHeightOption appropriately.
This is done in WindowsUIUtils::SetIsTitlebarCollapsed(); the rest of this
change is almost entirely the revert of bug 1934040.
Differential Revision: https://phabricator.services.mozilla.com/D263604
GetMainWidget can return null. We don't return an error in that event, since
callers are not expecting this to throw a JS exception and clients wouldn't do
anything in that case anyway.
Differential Revision: https://phabricator.services.mozilla.com/D249002
The registry key in question is known to be unhelpfully present on some
non-tablet-capable devices. Given this, it's never helpful except when
the `SM_CONVERTIBLESLATEMODE` test would already have told us whether
the device is tablet-capable.
Remove the check entirely, except when logging.
Differential Revision: https://phabricator.services.mozilla.com/D229955
Check for Windows 11 tablet mode when setting the UI density. (In
particular, have the UI-density object listen for the signal change,
rather than filtering it through `TabletModeUpdater`.)
This includes a change to the semantics of "tablet-mode-change": it now
signals Win11 tablet mode as distinct from Win10 tablet mode.
Differential Revision: https://phabricator.services.mozilla.com/D224245
Win11's tablet mode is different from Win10's tablet mode in ways both
subtle and gross. Avoid unifying them implicitly, and make it clear that
they should not be unified _explicitly_ without testing.
Unfortunately, Windows 11's API for checking whether the device is in
tablet mode is broken -- it requires one to know whether the device is a
tablet to interpret the return value, but there is no documented API
providing that information. We use a heuristic partly borrowed from
Chromium and partly based on independent investigation.
As all of the code using WindowsUIUtils effectively only checked for
Win10's tablet mode, this commit technically has no functional
changes.
Differential Revision: https://phabricator.services.mozilla.com/D224244
Check for Windows 11 tablet mode when setting the UI density. (In
particular, have the UI-density object listen for the signal change,
rather than filtering it through `TabletModeUpdater`.)
This includes a change to the semantics of "tablet-mode-change": it now
signals Win11 tablet mode as distinct from Win10 tablet mode.
Differential Revision: https://phabricator.services.mozilla.com/D224245
Win11's tablet mode is different from Win10's tablet mode in ways both
subtle and gross. Avoid unifying them implicitly, and make it clear that
they should not be unified _explicitly_ without testing.
Unfortunately, Windows 11's API for checking whether the device is in
tablet mode is broken -- it requires one to know whether the device is a
tablet to interpret the return value, but there is no documented API
providing that information. We use a heuristic partly borrowed from
Chromium and partly based on independent investigation.
As all of the code using WindowsUIUtils effectively only checked for
Win10's tablet mode, this commit technically has no functional
changes.
Differential Revision: https://phabricator.services.mozilla.com/D224244
If there aren't any browser windows, we're either very early in startup
or shutting down. In these cases, it's probably fine to not know if
tablet mode is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D219945
Implemented the prefers-reduced-transparency media query for all
platforms.
Windows and Mac have specific settings which are used, others (Android
and Linux/GTK) have it enabled if prefers-reduced-motion is also enabled
as there is no dedicated setting to check.
Locked behind new pref `layout.css.prefers-reduced-transparency.enabled`,
off by default always for now.
Also added new WPT tests (none previously).
Demo video: https://goose.icu/firefox_prt.mp4
Test page: https://goose.icu/prefers-reduced-transparency
Differential Revision: https://phabricator.services.mozilla.com/D172424
This basically pref-gates some of the accent-color changes that landed before
the soft-freeze to match current release behavior, at least for now.
In the future we might want to reconsider turning these on, but at the very
least we should figure out a good story for the grey-ish accent colors, see the
comments in the pref definitions.
The only tricky bit is the use-theme-accent pref handling. I made it specific
to the non-native-theme again so that AccentColor and NNT kept behaving
consistently, but AccentColor in the browser chrome used the real accent color.
Differential Revision: https://phabricator.services.mozilla.com/D150339
This matches UWP apps like Settings on Windows 11, and what we do for other
desktop platforms too.
The system colors match the ones from Win32 otherwise, but using UIUtils we can
access the accent color pallete from UWP apps.
Add a pref just to be safe in any case.
Differential Revision: https://phabricator.services.mozilla.com/D149905
dom/system/PathUtils.cpp(77,10): error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return false;
^~~~~
ipc/chromium/src/chrome/common/ipc_channel_win.cc(479,10): error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return true;
^~~~
mozglue/misc/PreXULSkeletonUI.cpp(1263,10): error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
mozglue/tests/TestPEExportSection.cpp(348,12): error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
security/manager/ssl/OSReauthenticator.cpp(428,10): error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return NS_OK;
^~~~~
toolkit/components/maintenanceservice/maintenanceservice.cpp(214,10): error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
widget/windows/WindowsUIUtils.cpp(383,10): error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return false;
^~~~~
Differential Revision: https://phabricator.services.mozilla.com/D144661
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
Sylvestre Ledru