This patch includes a new test file to cover a scenario similar to the one
fixed in Bug 1735899, and possibly some other similar ones that may slip
through unnoticed.
This test triggers the issue consistently on a build where the fix
is not included and pass consistently in build including the fix,
but even if it doesn't include any arbitrary timeouts to trigger the
issue there is still a chance that the test may start to fail
intermittently for some other reasons.
Keeping it as a separate test file will make it easier to disable it
as a temporary measure if turns out to be necessary.
Differential Revision: https://phabricator.services.mozilla.com/D132267
As suggested by :jamie, this patch causes focus to move to the item at the top of the list whenever the download panel is shown. In the event that the download panel is opened automatically because a new download has been started, this will have the effect of always bringing the new download directly to the attention of accessibility tools (because the panel itself also receives focus).
Differential Revision: https://phabricator.services.mozilla.com/D133160
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This modifies the opt-in modal so that opting in or out affects only the
data-collection pref and not suggestions like it currently does.
Depends on D131751
Differential Revision: https://phabricator.services.mozilla.com/D131752
This enables suggestions by default in the online scenario. Data collection is
still disabled by default. With this revision, there's now no difference between
online and offline in terms of defaults.
Part 2 of this bug will modify the opt-in modal so that opting in or out affects
only the data-collection pref and not suggestions like it currently does.
For users who were already enrolled in online, saw the modal, and did not opt in
or otherwise enable suggestions, suggestions will remain disabled when they
upgrade. Users in online who did enable suggestions will continue to see them
when they upgrade. Users in online who did *not* see the modal will also have
suggestions enabled when they upgrade. That's unfortunate since they currently
have suggestions disabled, but based on telemetry data, the number of these
users is small, and it's a little risky to handle that case specifically because
if we're not careful we could end up disabling suggestions for all users coming
from 94.0.1 and earlier who enroll in online in the future. The code comment in
`UrlbarPrefs._migrateFirefoxSuggestPrefsUnversionedTo2Online()` and discussion
in D131751 talk about this.
For all other users, suggestions will default to enabled when/if they are
enrolled in online.
I added another prefs migration to implement all this.
I wrote a [test plan doc](https://docs.google.com/document/d/1tcbrBZmIaL_cQhvycoVL602kQqFtQvOBRhKV9zKqghE/edit?usp=sharing) to make sure all relevant upgrade paths work correctly
and I've verified it myself. I also added new automated tests of course.
Differential Revision: https://phabricator.services.mozilla.com/D131751
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 adds a `setDefaultPDFHandler` that extends the existing
`setDefaultBrowserUserChoice` to also set Firefox as the default PDF
handler when setting Firefox as the default browser. (Since this uses
User Choice, it's Windows 10+ only.)
Differential Revision: https://phabricator.services.mozilla.com/D132660
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 adds a `setDefaultPDFHandler` that extends the existing
`setDefaultBrowserUserChoice` to also set Firefox as the default PDF
handler when setting Firefox as the default browser. (Since this uses
User Choice, it's Windows 10+ only.)
Differential Revision: https://phabricator.services.mozilla.com/D132660
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 adds a `setDefaultPDFHandler` that extends the existing
`setDefaultBrowserUserChoice` to also set Firefox as the default PDF
handler when setting Firefox as the default browser. (Since this uses
User Choice, it's Windows 10+ only.)
Differential Revision: https://phabricator.services.mozilla.com/D132660
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
This is a small follow-up to bug 1745297. UrlbarQuickSuggest can now be queried
even when suggestions are disabled and its `_rs` property (the remote settings
client instance) is null, which is a problem for `_fetchIcon` since it assumes
`_rs` is non-null. It can just bail in that case.
Differential Revision: https://phabricator.services.mozilla.com/D133540
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This makes the quick suggest provider active when suggestions are disabled but
data collection is enabled. Currently the provider is not active in that case.
The provider will fetch from both Merino and remote settings in that case
(assuming each is enabled), updating latency and Merino-response telemetry, but
the provider will discard any suggestions that happen to be returned.
However, Merino should not return any suggestions because this also sets its
`providers` query param to the empty string in this case, which tells Merino not
to fetch anything.
The `merino.providers` pref overrides this behavior. i.e., if suggestions are
disabled and data collection is enabled and `merino.providers` is non-empty,
then the `providers` query param will still be set to the pref's value.
Differential Revision: https://phabricator.services.mozilla.com/D133430
