This patch introduces a new cookie behavior policy called
BEHAVIOR_REJECT_TRACKER. It also makes it possible to override that
behavior with cookie permissions similar to other cookie behaviors.
Set the "network.trr.disable-ECS" pref to false to disable.
MozReview-Commit-ID: GE6L8Vpvuu0
Differential Revision: https://phabricator.services.mozilla.com/D2933
--HG--
extra : moz-landing-system : lando
We should get feedback from each CJKT testers at least one cycle after Win10
RS5 is released. Until then, we should not stop hacking GetTextExt() result
in late Beta nor Release builds.
This is done by ensuring that all methods is called are usable off the main thread and creating the required preference accessors.
Differential Revision: https://phabricator.services.mozilla.com/D2790
Screen's MediaCapabilities extensions aren't fully defined yet, but we don't want this to be blocking the release of the remaining features.
As such, we place those extensions behind a new pref: media.media-capabilities.screen.enabled
Differential Revision: https://phabricator.services.mozilla.com/D3060
--HG--
extra : moz-landing-system : lando
We originally thought that this would enable us to disconnect from the
windowserver local service (which is a significant sandbox escape risk),
however investigations revealed that that requires changes to WebGL and thus
will be handled separately.
This also corrects an incorrect usage of the (undocumented) APIs for closing
windowserver connections. If CGSSetDenyWindowServerConnections is called while
there are open connections it is a no-op, so it must be called after
disconnecting any open connections.
Differential Revision: https://phabricator.services.mozilla.com/D2478
--HG--
extra : moz-landing-system : lando
We're experiencing a high volume of content crashes on linux, most likely due to
free type thread unsafety seen in bug 1477444 and 1479498. This commit disables
tiling to stop the crashes for now while we investigate further.
--HG--
extra : rebase_source : 9becf3d4c5e41eb6a30ed12008ed342663660291
extra : intermediate-source : b9b178105f1bd1d794e53c2fb128bd9e505f8f32
extra : source : d28438c3e7596af6d6e482f3b227c7cb43dbbf26
Various web authors have expressed desire to know in advance whether autoplay
will work.
They want this in order to avoid paying the price for downloading media that
won't play. Or they want to take other action such as showing a poster image
instead.
This is of particular interest to Firefox, as we're planning on showing a
prompt to ask the user whether they would like a site to play. If sites want to
determine whether they can autoplay but avoid the prompt showing, they won't be
able to just call play() in Firefox and see whether it works, as that would
likely show the prompt if the user doesn't already have a stored permission.
We've been working out a spec here:
https://github.com/whatwg/html/issues/3617#issuecomment-398613484
This implements what is the consensus to date there;
HTMLMediaElement.allowedToPlay, which returns true when a play() call would not
be blocked with NotAllowedError by autoplay blocking policies.
MozReview-Commit-ID: AkBu0G7uCJ0
--HG--
extra : rebase_source : 3f31db79aa1e570fdd9fc7062d0ddac7c96a8931
We're experiencing a high volume of content crashes on linux, most likely due to
free type thread unsafety seen in bug 1477444 and 1479498. This commit disables
tiling to stop the crashes for now while we investigate further.
--HG--
extra : rebase_source : cedd55d2c8b96e298b2a96f84428abaf95dcde80
extra : source : d28438c3e7596af6d6e482f3b227c7cb43dbbf26
* Get default checkedness for the card persist checkbox from a new pref: dom.payments.defaults.saveCreditCard
* Get default checkedness for the address persist checkbox from a new pref: dom.payments.defaults.saveAddress
* Remember checked state from card page (only) so it doesnt change back when returning from add/edit address page
* Fix up card form tests to verify behavior in private/not-private windows, pref value, user opt-in for persisting the card
* Fix up address form tests to not conflate private/not-private windows with expected address persisting behaviour
MozReview-Commit-ID: GXMjqStlnlu
--HG--
extra : rebase_source : e267187766d221e4f865cb84065ea18231e7c012
* Get default checkedness for the card persist checkbox from a new pref: dom.payments.defaults.saveCreditCard
* Get default checkedness for the address persist checkbox from a new pref: dom.payments.defaults.saveAddress
* Remember checked state from card page (only) so it doesnt change back when returning from add/edit address page
* Fix up card form tests to verify behavior in private/not-private windows, pref value, user opt-in for persisting the card
* Fix up address form tests to not conflate private/not-private windows with expected address persisting behaviour
MozReview-Commit-ID: GXMjqStlnlu
--HG--
extra : rebase_source : eb5931bff4ba348503144139d3f7f625e0a4af91