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
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
