- Add `preonboarding` Nimbus feature for showing a window modal over about:welcome that cannot be dismissed via ESC
- Include the ability to suppress showing the privacy notice tab on first run using a variable under the new `preonboarding` feature
- Remove legacy `showModal` related `aboutwelcome` Nimbus feature variables (these are not in use and were for [[ https://experimenter.services.mozilla.com/nimbus/window-modal-vs-tab-modal/summary | an old experiment ]])
Differential Revision: https://phabricator.services.mozilla.com/D234039
- Add `preonboarding` Nimbus feature for showing a window modal over about:welcome that cannot be dismissed via ESC
- Include the ability to suppress showing the privacy notice tab on first run using a variable under the new `preonboarding` feature
- Remove legacy `showModal` related `aboutwelcome` Nimbus feature variables (these are not in use and were for [[ https://experimenter.services.mozilla.com/nimbus/window-modal-vs-tab-modal/summary | an old experiment ]])
Differential Revision: https://phabricator.services.mozilla.com/D234039
This patch updates the logic that prevents about:welcome from showing when the Nimbus `aboutWelcome` `showModal` variable is set to true. If separate screens for the modal are provided, it can now be shown on top of the default onboarding flow in about:welcome.
A `requireAction` variable that sets the modal to be a window modal requiring action (other than pressing ESC) to dismiss is also added to the `aboutWelcome` Nimbus feature
Differential Revision: https://phabricator.services.mozilla.com/D230185
Document remaining uses of Win10 tablet-mode detection which do not fall
under other bugs.
In particular, we leave alone:
* `IsTabletDevice` in WinUtils.cpp. This falls under bug 1735765.
* Uses in WinIMEHandler.{h,cpp}. These fall under bug 1929630.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D228206
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
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
This patch doesn't include testing. This is in large part because I would like to land this quickly. Ideally before this bug hits Beta. And it is in small part because I believe that testing can be added fairly trivially to a test that will be added in Bug 1889785, right after the soft freeze is over.
Differential Revision: https://phabricator.services.mozilla.com/D212867
The thinking here being that if a previous profile exists, then the
--first-startup argument is probably be passed because the user is
reinstalling on a system that still has (or once had) the browser
already installed on it. In that case, we're going to use that
pre-existing profile, and we don't need to do the FirstStartup
things, since they're primarily for systems where a new profile
is being created after install.
Differential Revision: https://phabricator.services.mozilla.com/D199763
The thinking here being that if a previous profile exists, then the
--first-startup argument is probably be passed because the user is
reinstalling on a system that still has (or once had) the browser
already installed on it. In that case, we're going to use that
pre-existing profile, and we don't need to do the FirstStartup
things, since they're primarily for systems where a new profile
is being created after install.
Differential Revision: https://phabricator.services.mozilla.com/D199763
