In wpt, now we support "offset-path: none | path()", so parsing none or
path function should be correct. Animations which animate "from none"
or "to none" will pass because we could serialize "none", even if we
don't support animations on offset-path.
Depends on D2968
Differential Revision: https://phabricator.services.mozilla.com/D2969
--HG--
rename : testing/web-platform/tests/css/motion/offset-path-string.html => testing/web-platform/tests/css/motion/offset-path-string-001.html
rename : testing/web-platform/tests/css/motion/offset-path-string.html => testing/web-platform/tests/css/motion/offset-path-string-002.html
extra : moz-landing-system : lando
Define the preference. I will enable it only for debug usage and test
coverage in a different patch.
Differential Revision: https://phabricator.services.mozilla.com/D2962
--HG--
extra : moz-landing-system : lando
In wpt, now we support "offset-path: none | path()", so parsing none or
path function should be correct. Animations which animate "from none"
or "to none" will pass because we could serialize "none", even if we
don't support animations on offset-path.
Differential Revision: https://phabricator.services.mozilla.com/D2969
--HG--
rename : testing/web-platform/tests/css/motion/offset-path-string.html => testing/web-platform/tests/css/motion/offset-path-string-001.html
Even after we disable Gecko specific editing UIs by default, web apps can
enable them with execCommand. However, until such web apps change their
behavior, users cannot use Gecko specific UIs. At least for now, we should
make users can enable them by default.
MozReview-Commit-ID: AuAdw4FQ4He
--HG--
extra : rebase_source : a1f88f2928df0d7afb4361c425d75c74872ac9d5
Summary:
Mike DeBoer correctly noted in a comment at https://bugzilla.mozilla.org/show_bug.cgi?id=254592 that enabletimeout is no longer used and should be removed. I updated the timeout logic to treat a zero or negative value as effectively "no automatic timeout" for the quick-find dialog (otherwise, setting the timeout value to a small or negative value makes the feature unusable).
This is a corollary to the bugfix at https://phabricator.services.mozilla.com/D3404 ; I've split it out into a separate patch to avoid confusing that issue.
Update: this specific issue already had its own bug at https://bugzilla.mozilla.org/show_bug.cgi?id=260562, and another mention at https://bugzilla.mozilla.org/show_bug.cgi?id=265915 .
Reviewers: kmag
Reviewed By: kmag
Bug #: 260562
Differential Revision: https://phabricator.services.mozilla.com/D3504
--HG--
extra : rebase_source : 1c2b73d6af1343d536a2380dee784f8ea2339b61
extra : amend_source : cc00a2398b2c478003e842b4dc9b99bf53af6824
This would allow us to control this feature independently of the Shadow DOM pref.
The feature is only turned on when Shadow DOM is turned on.
MozReview-Commit-ID: 4g6BJigFUZs
--HG--
extra : rebase_source : d9e8ae0105fbe3dc18c9e163c612b9523db4c5b0
With the new loading model for frame scripts, lexical variables defined in a
global frame script are not available to other frame scripts.
Additionally, scripts loaded into a context object by the subscript loader
should not depend on being able to access properties of the message manager as
if they were globals.
MozReview-Commit-ID: 6QEyA1sBVOV
--HG--
extra : rebase_source : d3a7820104645dc356bdf8ea660b970e1f6c20e7
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
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
Ryan Hunt
Noemi Erli
Xidorn Quan
Ciure Andrei
Boris Chiou
Jorg K
Tanushree Podder
Daosheng Mu
Masayuki Nakano
spillner
Ehsan Akhgari
Margareta Eliza Balazs
Olli Pettay
Dorel Luca
Junior Hsu
Timothy Guan-tin Chien
Kris Maglione
Daniel Varga
Andrea Marchesini
Daniel Stenberg
Csoregi Natalia
Jonathan Kew
Jean-Yves Avenard
Coroiu Cristina
Bogdan Tara
Anny Gakhokidze
Jeff Gilbert
Valentin Gosu
Jonathan Watt
Emilio Cobos Álvarez
Luca Greco
Alex Gaynor
Matt Howell
Chris Pearce
Tiberius Oros
Randall Barker
Sam Foster
alwu
Andreea Pavel
Francois Marier
Johannes Willbold
Robert Longson
Nicholas Nethercote
Cosmin Sabou
Nathan Froyd
Tarek Ziadé
Brian Hackett
Narcis Beleuzu
Gurzau Raul
shindli