It's widely documented on the web that Apple enforces quarantine attributes
'for us' using the list in
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist
Unfortunately, this is based on the bundle ID. Which means it won't apply to custom
builds, to Nightly, and potentially to other cases. It would also be much nicer
if we could just make these determinations ourselves. Step 1: opt-in from Info.plist
Without this, for e.g. local Nightly builds, asking for quarantine attributes
simply gets you a nil dictionary and our code bails out.
MozReview-Commit-ID: 4aLyz2901BS
--HG--
extra : rebase_source : 7aab5177276c20007036abd19efb56741d790ec2
Note that this "enables" the engine using a pref, even though it might
not be ready yet, so that the tests can pass.
MozReview-Commit-ID: AZ0TVERiQDU
--HG--
extra : rebase_source : 8ca202c1ec79e068fb9395207792942a228d4433
extra : intermediate-source : 93f41b72d8e7023b5f22c727436e836de87c9ca7
extra : source : 183547f4dbbedc9ee3399b6a474016d0e89a12e8
Note that this "enables" the engine using a pref, even though it might
not be ready yet, so that the tests can pass.
MozReview-Commit-ID: AZ0TVERiQDU
--HG--
extra : rebase_source : 3078b86c4255afd66a9c4faf895dc2b6fc43a152
extra : intermediate-source : 93f41b72d8e7023b5f22c727436e836de87c9ca7
extra : source : 183547f4dbbedc9ee3399b6a474016d0e89a12e8
As requested by UX. Disabling it behind a pref in case we decide we really
need to expose users to that form field again.
MozReview-Commit-ID: 4ICZXuApFBL
--HG--
extra : rebase_source : 8d42989c44d38299d5586eeb58d7aa6ac0196a29
Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 8cb5ea82004ad631fe688bafffa9dc9979568679
Disabling the Adobe CDM but leaving it visible means that we won't download it
and if a site tries to use it we will prompt the user to enable DRM and only
then download it.
MozReview-Commit-ID: LtEr0NJMiQM
--HG--
extra : rebase_source : b7c6f005fb6173c41af6a583c22473066a47a5eb
Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 6e678cc6d23c604d8ed0888d6ceeeb4bf797cb1f
The "Enable Crash Reporter" pref is erroneous because what it actually controls is
whether or not the "Submit crash report" checkbox is checked by default when the
crash report dialog comes up.
MozReview-Commit-ID: Ud6SLKXvxw
--HG--
extra : rebase_source : 45d3bc0e5ea727983e8c6e6c0d2c13b020dc0a11
The current UI for EME on Linux is confusing. We have the 'Play DRM Content'
checkbox ticked, but the CDM disabled. It would be clearer if we just had
the 'Play DRM Checkbox' unticked, and instead left the Widevine CDM enabled.
Then we won't download and install the CDM until the 'Play DRM Content'
checkbox is checked (which toggles media.eme.enabled).
This also means that the Widevine CDM won't appear in the plugins list
by default unless the 'Play DRM Checkbox' is checked.
MozReview-Commit-ID: 7CeCe1DOWgM
--HG--
extra : rebase_source : 39fa0bf479f3632616ef6e79178348605404c575
We don't want the Widevine CDM to be downloaded by default on Linux, as
the CDM is proprietary software and the user hasn't opted in to having such
software on their system. By leaving the CDM visible but disabled, we'll
prompt the user the first time EME is used, and they can approve the
download.
This means the Widevine CDM won't be downloaded by default. The user will
need to opt-in to enablding DRM playback before we'll download proprietary
CDMs.
MozReview-Commit-ID: GLBoK2Czjcc
--HG--
extra : rebase_source : 35aac5a84a1b779149d08fe5a2c85179bd00756d
This patch adds the gpsd location provider to |nsGeolocationService|.
On release builds, the new provider is *not* used by default, as GPS
is slow to start and unreliable indoors. To enable gpsd, users with a
supported GPS receiver must set the preference 'geo.location.use_gpsd'
to 'true'.
On non-release builds, the gpsd location provider is enabled by default
to give it some testing.
MozReview-Commit-ID: I0tj1GmmFNP
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
MacQuirks was targeted for OSX from 10.6.8 up to but not including 10.7.0. We
have now removed support for 10.6 so we can safely remove this code. This also
fixes bug 1282184 where DMD is apparently choking on memory allocated in the
interpose library.
MacQuirks was targeted for OSX from 10.6.8 up to but not including 10.7.0. We
have now removed support for 10.6 so we can safely remove this code. This also
fixes bug 1282184 where DMD is apparently choking on memory allocated in the
interpose library.
The only platform for which this change is *not* a no-op is Mulet. Last time
I checked Mulet worked fine with APZ enabled but there were a few test failures.
Now I don't believe it's running in automation anyhwere so that shouldn't be
an issue. If it is, they can re-disable APZ easily enough if needed.
MozReview-Commit-ID: 5xKUuTOnubM
Repurpose the media.gmp-*.forcevisible pref to control whether the
corresponding GMP is visible in the addons manager UI. The pref has to be true
for the GMP to be usable.
The pref is enabled and not hidden when the corresponding EME keysystem is
enabled in the mozconfig.
This means users can turn on EME without needing to recompile their build; they
just need to create a hidden pref. This will be useful for CDM developers, and
users on platforms where we've not enabled EME yet but users want to test it
(Linux).
We also need to change the GMPUtils.isPluginHidden() accessor so that plugins
are considered hidden if the "visible" pref is false OR we're on an unsupported
platform. This ensures that we must be on a supported OS and the visibility
pref is true before GMPs appear in the addon list.
A consequence of the isPluginHidden() change is that we also need to add a
"force-supported" pref to override the checks that refuse to load the GMPs on
various platform versions, so that the unit tests pass.
MozReview-Commit-ID: h6CwLDkvFW
--HG--
extra : rebase_source : d09b952cc12da6f46b404439781b62784e4f54b3
Repurpose the media.gmp-*.forcevisible pref to control whether the
corresponding GMP is visible in the addons manager UI. The pref has to be true
for the GMP to be usable.
The pref is enabled and not hidden when the corresponding EME keysystem is
enabled in the mozconfig.
This means users can turn on EME without needing to recompile their build; they
just need to create a hidden pref. This will be useful for CDM developers, and
users on platforms where we've not enabled EME yet but users want to test it
(Linux).
We also need to change the GMPUtils.isPluginHidden() accessor so that plugins
are considered hidden if the "visible" pref is false OR we're on an unsupported
platform. This ensures that we must be on a supported OS and the visibility
pref is true before GMPs appear in the addon list.
A consequence of the isPluginHidden() change is that we also need to add a
"force-supported" pref to override the checks that refuse to load the GMPs on
various platform versions, so that the unit tests pass.
MozReview-Commit-ID: h6CwLDkvFW
--HG--
extra : rebase_source : 2c077e577352e356aceeda000d873bad1439f242
Before bug 552864, the string was created with PR_smprintf, and
PR_SetEnv'ed (which, under the hood, just calls putenv). PR_smprintf was
allocating the string on the heap. Now, it's allocated on the stack, and
still putenv'ed.
putenv kind of takes ownership of the strings it's being passed, so
stack allocated strings are dangerous to use. It looks like we've been
fairly lucky that it worked, presumably because compilers would keep the
stack frame with the variable, but that's not guaranteed to happen, and
in some case, doesn't.
So we strdup the string and purposefully leak it instead, which matches
what happened before bug 552864, and is the only "sane" way to use
putenv.
--HG--
extra : rebase_source : e39349f90f5346b591e20696c0c3c7fdb26c3cfb
