The fxms schema job has been updated with a script that writes out the test
corpus for the test. This means we no longer need to keep these JSON files in
tree, since the test will automatically generate them.
Differential Revision: https://phabricator.services.mozilla.com/D151985
The following propertie have been refactored out into the top-level message
schema so that they don't have to be repeated in each template's schema:
- `frequency`
- `groups`
- `id`
- `priority`
A definition for the `trigger` property has been added to the common schemas as
`MessageTrigger` so that messages that require triggering can reference this
definition.
Each template schema now requires only its template (as a const value or enum)
and its content, as well as any additional top-level properties that are
message specific (e.g., `order` for `WhatsNewMessage`).
`id`, `content`, and `template` properties are required for all messages.
Individual template schemas do not need to mark `content` and `template` as
required since they are required by the top-level schema. Messages that
require triggering or targeting must define those properties.
Differential Revision: https://phabricator.services.mozilla.com/D150705
Several kinds of FxMS messages support a common pattern of taking either a
string or an object containing a string ID, allowing for both raw strings and
translated string IDs to be used in messages. This patch refactors that pattern
out into a common definition (localizedText and localizableText) in a common
schema which other schemas can then reference.
Our schema bundling script has been updated to bundle these definitions from
the common schema as top-level definitions (and subsequently rewrite the
references from FxMSCOmmon.schema.json to the generated schema) because Nimbus
and Experimenter only support a single schema file per feature.
To ensure compatability with Experimenter, all our in-tree messages have been
extracted into a test corpus that is validated with the Experimenter JSON
Schema validator. A future patch in this series will clean this up so we don't
need to have separate copies of messages in the tree.
We are now also validating all messages from the CFRMessageProvider with our
in-tree JSON Schema validator that Nimbus uses. The OnboardingMessageProvider
and PanelTestProvider tests have also been updated so that all three are using
the same testing infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D150704
To be used in about:privatebrowsing Pin Private Window promo message. BLOCK_MESSAGE will be used in a multi action call after user clicks 'Pin To taskbar'. This will help in hiding Pin promo message on current and preloaded tabs
Differential Revision: https://phabricator.services.mozilla.com/D151888
The Nimbus Features corresponding to FxMS messaging surfaces are actually
intended to map to FxMS message groups, which can accept *any* FxMS message.
The features have been updated with schemas that accept any FxMS message.
As part of this, all FxMS schemas have been updated with an `$id` so that they
can be bundled into feature schemas and have their internal `$ref`s work.
(Otherwise, a `$ref` would be relative to the top-level schema instead of the
sub-schema).
Schemas for individual message types are no longer exposed as resource:// URIs,
except in tests, as indivual schemas are no longer required at runtime.
Additionally, each FxMS schema has had its `template` field become required and
requires a constant value for that schema (e.g., Spotlight requires a template
value of "spotlight").
A test has been added to ensure that if any of the messaging surfaces schemas
change that the feature schemas are also updated. The feature schemas can be
regenerated via:
```
cd ./browser/components/newtab/content-src/asrouter/schemas
../../../../../../mach make-schemas.py
```
Differential Revision: https://phabricator.services.mozilla.com/D147332
These schemas are only used in Fx Desktop. As such, there is a change in
nimbus-shared to remove the generation of these schemas. The versions in m-c
can now be the canonical versions.
Differential Revision: https://phabricator.services.mozilla.com/D150017
Previously `nsIWindowsShellService::{Check,}PinCurrrentAppToTaskbar` was doing
main thread IO. They have been replaced with async versions that do their work
on a background thread.
Differential Revision: https://phabricator.services.mozilla.com/D145244
The bulk of this is wiring in a Private Browsing flag in the places that need it, and using some of the recently added WinTaskbar code to grab the correct AUMID. Beyond that, the notable parts are:
* The interface difference between isCurrentAppPinnedToTaskbarAsync and the other changed methods. I was hoping to use the Private Browsing flag everywhere, but doing so in code that run in a separate thread ended up crashing due to the Preferences usage in WinTaskbar (https://searchfox.org/mozilla-central/rev/9d66919569655a8fae9b431550241c058fa85b8a/widget/windows/WinTaskbar.cpp#216)
* The new string for the Private Browsing shortcut. The exact string may change, so it's hardcoded for now.
* Checking the AUMID of shortcuts when looking for a match (to make sure Private Browsing doesn't pick up non-private, and visa versa)
* Some fixes for tests of ShellService.jsm -- I honestly have no idea how these ever passed on Linux.
Differential Revision: https://phabricator.services.mozilla.com/D138196
