This is only done by the Return-to-AMO flow, which is not supported in MSIX anyways.
Also, disable the RTAMO test for MSIX builds while we're here.
Differential Revision: https://phabricator.services.mozilla.com/D164666
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
This is only done by the Return-to-AMO flow, which is not supported in MSIX anyways.
Also, disable the RTAMO test for MSIX builds while we're here.
Differential Revision: https://phabricator.services.mozilla.com/D164666
This commit uses a "pull" approach, where the experiment details are
fished at presentation-time and the content `tag` updated.
A few notes:
- With this approach, the update function is pushed down to the leaf
node (the toast notification presentation layer). It would be nice to
do this at the experiment layer, but that layer doesn't resolve the
presentation layer at this time, so it would perhaps violate the
abstraction to lift the work higher.
- No effort has been made to mark `tag` as invalid in the messaging
experiment schemas. At this time, there's no provision for fields
accepted at the presentation layer (`ToastNotification.schema.json`)
but not at the experiment layer aggregating
presentations (`BackgroundTaskMessagingExperiment.schema.json`,
`MessagingExperiment.schema.json`). It's likely possible to arrange
this but not worth the effort at this time.
- The actual tag displayed is not captured in the message as it flows
through ASRouter. This is not likely to pose a problem.
- The actual tag displayed might be `optin-...`, potentially
complicating data analysis. Since it's essentially impossible for
regular users to opt-in to _background task_ messages, that's not a
pressing concern.
Differential Revision: https://phabricator.services.mozilla.com/D164508
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
This patch accomplishes a couple different things in one go.
about:welcome has a feature to allow switching screens by history
navigation. But the screen transitions don't play in that case. There
was also an issue (see bug 1804098) where rounding inconsistencies could
cause 1px gaps to appear in the animated progress bar, because of the
use of transform. By converting the progress bar into a single element
and just modulating its width, we can stop using transform and also
enable transitions for history navigation. Technically, this also allows
us to advance by more than 1 screen without messing up the animations,
though this is not currently used. Incidentally, it simplifies the CSS.
Differential Revision: https://phabricator.services.mozilla.com/D164310
Modify the enzyme assertions in unit tests so they can fail when
regressed. Update the same tests since now they would fail otherwise.
One of them also required fixing a bug in MSLocalized.jsx.
Differential Revision: https://phabricator.services.mozilla.com/D164403
This patch accomplishes a couple different things in one go.
about:welcome has a feature to allow switching screens by history
navigation. But the screen transitions don't play in that case. There
was also an issue (see bug 1804098) where rounding inconsistencies could
cause 1px gaps to appear in the animated progress bar, because of the
use of transform. By converting the progress bar into a single element
and just modulating its width, we can stop using transform and also
enable transitions for history navigation. Technically, this also allows
us to advance by more than 1 screen without messing up the animations,
though this is not currently used. Incidentally, it simplifies the CSS.
Differential Revision: https://phabricator.services.mozilla.com/D164310
Add a 1s grace period after waking from sleep in which notifications
from the idle service will be ignored. Break out the idle trigger tests
because we've reached the max statements per function limit.
Differential Revision: https://phabricator.services.mozilla.com/D163303
Add the autoplay permission to about:welcome through the default
permissions file. If we add onboarding videos to other messaging
surfaces (like the multistage spotlight for existing user onboarding),
it won't be necessary to add permissions since autoplay is only blocked
in content. This also incidentally reduces the severity of bug 1799935.
The error still happens, breaking the video controls. But since the
video autoplays, the bug is only noticeable if you try to interact with
the video controls. Otherwise, the video will just play on its own and
advance to the next screen when it's finished.
Differential Revision: https://phabricator.services.mozilla.com/D162162
To debug the idle trigger's interaction with OS sleep state, it's
helpful to know whether sleep/wake notifications were sent. This allows
most of the idle trigger activity to be logged to the console, if the
pref `messaging-system.log` is set to `debug`. The new logging will also
be used to debug the behavior reported in bug 1801301.
Differential Revision: https://phabricator.services.mozilla.com/D163010
