Instead of using the list of FxA devices from the Sync clients engine,
we now fetch the list of Send Tab devices from FxA. This works like
this:
* `FxAccountsDevice#getDeviceList` has been split up into
`recentDeviceList` and `refreshDeviceList`.
* `recentDeviceList` synchronously returns the last fetched list, so
that consumers like Send Tab can use it right away.
* `refreshDeviceList` is asynchronous, and refreshes the last fetched
list. Refreshes are limited to once every minute by default, matching
the minimum sync interval (Send Tab passes the `ignoreCached` option
to override the limit if the user clicks the "refresh" button).
Concurrent calls to `refreshDeviceList` are also serialized, to
ensure the list is only fetched once.
* The list is flagged as stale when a device is connected or
disconnected. It's still kept around, but the next call to
`refreshDeviceList` will fetch a new list from the server.
* The Send Tab UI refreshes FxA devices in the background. Matching FxA
devices to Sync client records is best effort; we don't do it if Sync
isn't configured or hasn't run yet. This only impacts the fallback
case if the target doesn't support FxA commands.
Differential Revision: https://phabricator.services.mozilla.com/D47521
This uses Shadow DOM slotting instead of XBL, and migrates styles from
using XBL anonymous traversal to using CSS Shadow Parts.
This also removes the basecontrol binding, since this was the last
binding to extend it.
Differential Revision: https://phabricator.services.mozilla.com/D43651
This uses Shadow DOM slotting instead of XBL, and migrates styles from
using XBL anonymous traversal to using CSS Shadow Parts.
This also removes the basecontrol binding, since this was the last
binding to extend it.
Differential Revision: https://phabricator.services.mozilla.com/D43651
This is a necessary change that was done for Fluent access in bug 1573276. In almost all cases,
we want to rely on the principal for making security decisions, but the principal does not
store the original URI in cases where an about: page was sandboxed (it becomes a null principal URI),
and thus we need to use the documentURI here.
Differential Revision: https://phabricator.services.mozilla.com/D47582
Other tests in the file explicitly call closeStream. It seems to help with the issue, but this
is a bit guess fix, since I'm not at all familiar with the relevant code. Perhaps the test
should pass without explicit closeStream? If so, there should be a comment why.
Differential Revision: https://phabricator.services.mozilla.com/D47647
In order to show a correct tooltip after toggling the TP switch. We
update the tooltip of the tracking protection icon when toggling the TP
switch right before the 500 ms waiting.
Differential Revision: https://phabricator.services.mozilla.com/D47587
Now that we only use a single field of the browser that gets passed in
to isWebRemoteType, I think it makes more sense to just pass in the
remote type directly.
Differential Revision: https://phabricator.services.mozilla.com/D47179
Nika said that any `web'-prefixed remote type should be valid, so this
function can be simplified. For instance, webLargeAllocation should
return true.
This removes the need for ownerGlobal, so a few wrappers can be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D45374
As we roll out the TLS 1.0 and 1.1 deprecation, sites that don't support TLS 1.2
will show the neterror page. This adds a box to that page that shows in this
specific case. That box explains what is going on and gives an option to
re-enable TLS 1.0.
As mentioned, this will show alongside an option to reset TLS-related
preferences if any overrides are active.
Hitting the button will set the new pref to 'true' and reload the page.
Once the override is engaged, the option won't show, but that option to reset
preferences will show (as this is a TLS-related preference).
The intent is to remove this affordance in March 2020 as we formally move to
having TLS 1.2 the minimum version. All going to plan, this will only affect
prerelease channels, though anyone who has tweaked security.tls.version.* could
also see this.
Differential Revision: https://phabricator.services.mozilla.com/D45799
This flips the default for security.tls.version.min to 3 (TLS 1.2) for the
Nightly channel.
Having had this pref at this level for the last year, I can confirm that this
does break the occasional site, but it is quite rare. The intent of this change
is to start making it more obvious when sites don't support TLS 1.2.
I'm asking for wider review because this is a disruptive change.
Differential Revision: https://phabricator.services.mozilla.com/D45627
As we roll out the TLS 1.0 and 1.1 deprecation, sites that don't support TLS 1.2
will show the neterror page. This adds a box to that page that shows in this
specific case. That box explains what is going on and gives an option to
re-enable TLS 1.0.
As mentioned, this will show alongside an option to reset TLS-related
preferences if any overrides are active.
Hitting the button will set the new pref to 'true' and reload the page.
Once the override is engaged, the option won't show, but that option to reset
preferences will show (as this is a TLS-related preference).
The intent is to remove this affordance in March 2020 as we formally move to
having TLS 1.2 the minimum version. All going to plan, this will only affect
prerelease channels, though anyone who has tweaked security.tls.version.* could
also see this.
Differential Revision: https://phabricator.services.mozilla.com/D45799
