When Windows presents the dialog asking the user to give geolocation permission
to Firefox, we need to wait for the user to make a choice before running the
geolocation request. Previously, we were not waiting for the user's response
so most requests would timeout and fail, even if the user replied "Yes".
This dialog is only ever presented once -- the first time that Firefox asks
Windows for a wifi scan. It does not reappear on restarts or reinstalls. This
dedicated Yes/No system prompt is a bit more user-friendly than system settings.
This "system will prompt for permission" case could be completely avoided since
wifi scanning is not useful to us when it requires geolocation permissions as
geolocation would override it. We would need the MLSFallback behavior to skip
scanning wifi when geolocation permission wasn't already granted, or else the
MLSFallback would present the system prompt in question, despite the user having
already denied permission. On the other hand, we need the old scanning behavior
for this case when running versions of Windows 10 and 11 that don't have these
updates. (The updates are set to appear in the 24H2 version of Windows 11.)
This approach avoids that kind of version special-casing.
Differential Revision: https://phabricator.services.mozilla.com/D218589
When Windows presents the dialog asking the user to give geolocation permission
to Firefox, we need to wait for the user to make a choice before running the
geolocation request. Previously, we were not waiting for the user's response
so most requests would timeout and fail, even if the user replied "Yes".
This dialog is only ever presented once -- the first time that Firefox asks
Windows for a wifi scan. It does not reappear on restarts or reinstalls. This
dedicated Yes/No system prompt is a bit more user-friendly than system settings.
This "system will prompt for permission" case could be completely avoided since
wifi scanning is not useful to us when it requires geolocation permissions as
geolocation would override it. We would need the MLSFallback behavior to skip
scanning wifi when geolocation permission wasn't already granted, or else the
MLSFallback would present the system prompt in question, despite the user having
already denied permission. On the other hand, we need the old scanning behavior
for this case when running versions of Windows 10 and 11 that don't have these
updates. (The updates are set to appear in the 24H2 version of Windows 11.)
This approach avoids that kind of version special-casing.
Differential Revision: https://phabricator.services.mozilla.com/D218589
Previously, the WebExtension protocol used dynamic protocol flags which
were based on the WebExtension policy in order to enforce things such as
availability in private browsing and the accessibility of certain
resources.
Since the shift to MV3, these checks have required more complex checks
than what was possible to specify with protocol flags, which required
the addition of WEBEXT_URI_WEB_ACCESSIBLE - a security flag which would
trigger further checks with the EPS to determine if the URI can be
loaded.
This was somewhat inefficient, as fetching the URI flags would require
looking up the policy each time dynamic flags were looked up, as well as
when policy specifics were being checked after loading flags. In
addition, it lead to a number of flags which were very specific to
extension protocols.
This patch changes extensions to no longer have dynamic flags, instead
specifying the static `URI_IS_WEBEXTENSION_RESOURCE` security flag. When
this flag is specified, security checks are made by querying the
ExtensionPolicyService to ask if the load should be permitted, combining
the specific security checks for Extension resources into a simpler
code-path, and avoids redundant checks.
Differential Revision: https://phabricator.services.mozilla.com/D216076
These registrars can hold channels alive, which can hold listeners alive,
which can hold cycle collected things alive. By clearing the registrars
before the final CC instead of after the final CC, we can avoid spurious
leaks.
It would make more logical sense to do this earlier, at net teardown,
but I've made the minimal change to try to avoid stirring up weird
shutdown issues.
Differential Revision: https://phabricator.services.mozilla.com/D177182
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
This patch removes the redundant nsICryptoHMAC interface and implementation,
updates front-end code to use WebCrypto, and changes back-end code to use the
helper class HMAC introduced by this patch.
This also removes the last uses of nsIKeyObject and nsIKeyObjectFactory, and
thus those interfaces and implementations as well.
Differential Revision: https://phabricator.services.mozilla.com/D145656
