This only records whether Firefox is the default PDF handler for now.
But it will accommodate additional file types and protocols in the
future, should they be desired.
This is Windows 10+ only, since we really only care about PDF handling
defaults where Edgium is the OS default.
Differential Revision: https://phabricator.services.mozilla.com/D132659
This only records whether Firefox is the default PDF handler for now.
But it will accommodate additional file types and protocols in the
future, should they be desired.
This is Windows 10+ only, since we really only care about PDF handling
defaults where Edgium is the OS default.
Differential Revision: https://phabricator.services.mozilla.com/D132659
This only records whether Firefox is the default PDF handler for now.
But it will accommodate additional file types and protocols in the
future, should they be desired.
This is Windows 10+ only, since we really only care about PDF handling
defaults where Edgium is the OS default.
Differential Revision: https://phabricator.services.mozilla.com/D132659
The `-osint` flag is used as the signal that Windows is invoking
Firefox to handle a file type or protocol. The `-osint` flag was
introduced in order to mitigate security breaches due to poor argument
quoting (by consumers invoking Firefox); to use it for this new
purpose, it must be preserved for downstream consumers to react to.
Alternately, some marker of the flag could be maintained. Since the
flag needs to transit through the launcher process, I've elected to
simply not strip it as we validate command lines, and to accommodate
it further downstream. (It looks like Thunderbird already
accommodates `-osint`: see
https://searchfox.org/comm-central/rev/3e8f926de9ea09945b237177eb6d489c70318f0e/mail/components/MessengerContentHandler.jsm#568.)
The telemetry in this patch achieves two purposes. The first is to
count the number of times Firefox is invoked to handle a registered
file type or protocol: for this, a new keyed uint scalar was added.
File types start with a ".", just like on Windows; protocols
(equivalently, the schemes used to identify them) do not start with a
".".
The second is to identify times when Firefox is launched (i.e., it was
not already running) to handle a registered file type or protocol.
This generalizes the existing `os.environment.launch_method`,
introducing `os.environment.launched_to_handle` and
`os.environment.invoked_to_handle` string scalars, which record the
file type or protocol.
The command line state `STATE_INITIAL_LAUNCH` is used to discriminate
launching from invoking.
Differential Revision: https://phabricator.services.mozilla.com/D132288
Remove start screen reusing its subtitle on the colorway screen. Get the previous theme before ready as colorway screen is now first and randomly picks a color, so detect testing to remove randomness. Show rounded mostly transparent background for variants now packed more tightly within the disc. Shrink and deemphasize secondary button. Reenable upgrade spotlight after turning off in D131023.
https://www.figma.com/file/blhdnzQOhWYKcdiCzywMuG/MR2-Onboarding?node-id=2548%3A158106
Differential Revision: https://phabricator.services.mozilla.com/D130930
There's a lot of history in this area that mostly explains why this
has not been supported in the past, leading to several awkward
workarounds in tests. But it doesn't appear that there's any reason
to prevent tests from creating actual command lines, so that's what we
allow here.
I've elected to flesh out `Cu.createCommandLine` rather than expose
`.init(..._)` directly since `Cu.createCommandLine` is already used in
the relevant tests and is only used in tests. And I've made the
arguments required, rather than optional, so that consumers think
about the arguments, in particular `state`.
Differential Revision: https://phabricator.services.mozilla.com/D132089
There's a lot of history in this area that mostly explains why this
has not been supported in the past, leading to several awkward
workarounds in tests. But it doesn't appear that there's any reason
to prevent tests from creating actual command lines, so that's what we
allow here.
I've elected to flesh out `Cu.createCommandLine` rather than expose
`.init(..._)` directly since `Cu.createCommandLine` is already used in
the relevant tests and is only used in tests. And I've made the
arguments required, rather than optional, so that consumers think
about the arguments, in particular `state`.
Differential Revision: https://phabricator.services.mozilla.com/D132089
Turn off by default as "Mikal won't want to see us ship another experience devoid of the pin and set to default prompts."
Differential Revision: https://phabricator.services.mozilla.com/D131023
Rework theme and variant activation to make variants sticky. Reorder Default to show Light then Auto so that Light and Soft are the same index. Also select the initial index based on current dark or light theme. Add transitions for variation children. Compute about:welcome variant index based on active theme instead of specifying both default variants for system and colorways.
Differential Revision: https://phabricator.services.mozilla.com/D128404
Add newtab pref checks and record events for when checkbox button is handled. Split up trigger tests to own file and share telemetry helpers from head.js.
Differential Revision: https://phabricator.services.mozilla.com/D127722
Replace almost all MR1 content with MR2 start, colorway and thank you screens. Reuse confetti from about:welcome. Add variant selection with transitions. Update triggering to show for 94 but not for windows 7.
Differential Revision: https://phabricator.services.mozilla.com/D127252
These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
