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
This makes it possible to use different lists for tracking protection
and for the features that rely on tracking annotations.
Differential Revision: https://phabricator.services.mozilla.com/D2484
--HG--
extra : moz-landing-system : lando
It was accidentally changed from 524288 to 32768 on Android by bug 1448222.
This commit changes it back.
--HG--
extra : rebase_source : 9181928dccf0cfcd0f70c1c3840d43c378f38ca4
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Renamed the pref media.webrtc.rsdparsa_enabled to media.peerconnection.sdp.rust.compare
Added the pref media.peerconnection.sdp.rust.enabled
Added both to all.js
media.peerconnection.sdp.rust.compare: Controls whether the parsing result comparer for sipcc and rsdparsa runs or not.
media.peerconnection.sdp.rust.enabled: Controls whether the rsdparsa runs in parallel to the sipcc parser.
MozReview-Commit-ID: Ac5P7T2NBYD
--HG--
extra : rebase_source : afd60243ccba27965bea193bbe29d91bf7bf2644
Adds a performance counter in ParentAPIManager to track the
number and duration of API calls by webextensions.
MozReview-Commit-ID: PTpaSCkE6A
--HG--
extra : rebase_source : 21c6c7f2e38c8808771fe4fea90d2750196202bd
Adds a performance counter in ParentAPIManager to track the
number and duration of API calls by webextensions.
MozReview-Commit-ID: PTpaSCkE6A
--HG--
extra : rebase_source : e9a61cf0cf755db96f1fd0dacbc2744fe19fe08e
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
In order to avoid the overhead of doing a full pref lookup for every static
var cache at content process startup, we currently assume that the default
value of any static varcache pref will always match the default value of its
database entry (as long as the pref isn't locked). This lets us only perform
lookups for preferences which have a user value, or are locked.
If the default values of those preferences are changed in a bundled preference
file, though, the varcache value will be correct in the parent process, but
not in child processes. Since this is an easy mistake to make, we should
assert that it doesn't happen.
Note: This change only affects applications which use e10s. Applications like
Thunderbird can still override default values of any static pref with
impunity. Repacks and distributors can only do so by changing user values or
locking the preference after the change (which is the standard practice for
enterprise deployments).
MozReview-Commit-ID: JMHQBrp9HN
--HG--
extra : source : 1b389b00030ed38cdb3543aa5d1a67795be47565
extra : amend_source : 16f2dccf40664db9daa42a6edaabb933acbc6204
In order to avoid the overhead of doing a full pref lookup for every static
var cache at content process startup, we currently assume that the default
value of any static varcache pref will always match the default value of its
database entry (as long as the pref isn't locked). This lets us only perform
lookups for preferences which have a user value, or are locked.
If the default values of those preferences are changed in a bundled preference
file, though, the varcache value will be correct in the parent process, but
not in child processes. Since this is an easy mistake to make, we should
assert that it doesn't happen.
Note: This change only affects applications which use e10s. Applications like
Thunderbird can still override default values of any static pref with
impunity. Repacks and distributors can only do so by changing user values or
locking the preference after the change (which is the standard practice for
enterprise deployments).
MozReview-Commit-ID: JMHQBrp9HN
--HG--
extra : rebase_source : 2f51295def52cbca316227f202158cb22656441a
Jonathan Watt
Dorel Luca
Luca Greco
Alex Gaynor
Matt Howell
Noemi Erli
Ryan Hunt
Chris Pearce
Tiberius Oros
Randall Barker
Sam Foster
alwu
Andreea Pavel
dvarga
Andrea Marchesini
Francois Marier
Johannes Willbold
Anny Gakhokidze
Robert Longson
Nicholas Nethercote
Cosmin Sabou
Coroiu Cristina
Nathan Froyd
Tarek Ziadé
Ehsan Akhgari
Kris Maglione
Brian Hackett
Narcis Beleuzu
Gurzau Raul
shindli
Liang-Heng Chen
Brindusan Cristian
Tim Nguyen