- Remove redundant check for `regRename` pref when deciding whether to show set default guidance notification
- Update guidance notification test helper to set `setDefaultBrowserUserChoice` to the same value as `...regRename` to make tests that include one-click being enabled more accurate.
These updates should not change the user experience.
Differential Revision: https://phabricator.services.mozilla.com/D215218
The enrollmentHelper was much more complicated than it needed to be. The
internal asynchrony that required awaiting an additional promise was fixed in
bug 1773583.
The returned cleanup function is no longer async, so unnecessary awaits have
been removed. This also applies to enrollWithFeatureConfig, as it is a wrapper
around enrollmentHelper.
Differential Revision: https://phabricator.services.mozilla.com/D212318
enrollWithRollout skipped all enrollment logic in ExperimentManager.enroll by
calling ExperimentStore.addEnrollment directly. This prevents prefs being set
by Nimbus correctly when enrolling. enrollWithFeatureConfig already supports
enrolling as a rollout, so all uses of enrollWithRollout have been replaced.
Differential Revision: https://phabricator.services.mozilla.com/D209936
enrollWithRollout skipped all enrollment logic in ExperimentManager.enroll by
calling ExperimentStore.addEnrollment directly. This prevents prefs being set
by Nimbus correctly when enrolling. enrollWithFeatureConfig already supports
enrolling as a rollout, so all uses of enrollWithRollout have been replaced.
Differential Revision: https://phabricator.services.mozilla.com/D209936
enrollWithRollout skipped all enrollment logic in ExperimentManager.enroll by
calling ExperimentStore.addEnrollment directly. This prevents prefs being set
by Nimbus correctly when enrolling. enrollWithFeatureConfig already supports
enrolling as a rollout, so all uses of enrollWithRollout have been replaced.
Differential Revision: https://phabricator.services.mozilla.com/D209936
This commit includes the changes to call into the new asynchronous code to set the browser as default, using powershell.
While here, we add more logging to this interaction to allow easier
debugging with QA.
Differential Revision: https://phabricator.services.mozilla.com/D194949
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
