Unfortunately couldn't add all the debug checks that I'd want, since we can't
assert that is not safe to run script in quite a few places :(
MozReview-Commit-ID: 8m3Wm1WntZs
Say PDMFactory::EnsureInit() runs on the main thread (effectively locking it)
and then tries to lock sMonitor; if another thread was also running
EnsureInit() and locked sMonitor, it will dead-lock when trying to sync-
dispatch the GMPDecoderModule creation to the main thread.
This can be fixed by ensuring that the actual PDMFactory instance creation is
always done on the main thread (and that we don't hold sMonitor before
dispatching to the main thread.)
Note that we can now simplify GMPDecoderModule::Init and assert we are already
on the main thread.
MozReview-Commit-ID: 8xHpoymw6po
--HG--
extra : rebase_source : aabc1f4768aebdd16873bbc1afdd1679d90aed6f
Its value was only used in a couple C++ files, and a corresponding value
can be gotten directly from including winsdkver.h.
--HG--
extra : rebase_source : 618f1eb2ee0243a6c1c652ccce45b2aeba959edf
In particular, this change uses the root frame of the touch target document,
so that the correct presShell resolution is used when doing the touch-action
hit test.
MozReview-Commit-ID: 2bra6PIRqkR
Adds content sandbox metadata to parent and child crash reports:
Includes the value of pref security.sandbox.content.level,
whether or not the system is capable of sandboxing, if the
sandbox was successfully turned on, and (on Linux systems)
the sandbox capabilities flags.
New crash report keys:
"ContentSandboxLevel" in parent and content
"ContentSandboxCapable" in parent
"ContentSandboxEnabled" in content
"ContentSandboxCapabilities" in content on Linux
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
On Windows XP (and others before Vista), if WMF is required to play a format,
the console message should not refer to Microsoft software as it is not
available there.
MozReview-Commit-ID: LaERcaOfePe
--HG--
extra : rebase_source : 72b6e24683be4eb2c21c9ccff039f326cf5647a7
This ensures we'll only retry requests if we know the install operation has
completed for a given GMP. This means if (say) OpenH264 happens to install
while we have a Widevine request pending, we won't retry the Widevine request,
as that would fail. The Widevine request will retry once the Widevine CDM
has downloaded and in turn fires its gmp-changed notification.
MozReview-Commit-ID: E3CV9uID4pS
--HG--
extra : rebase_source : 4e27210a9e6c28118e93f45846b63aaa64f5882d
We're already routing the "gmp-changed" observer service notification over from
the chrome process to the content process, and it fires at pretty much the same
time as the "gmp-path-added" notification (and a few more) so we can just switch
to have the MediaKeySystemAccessManager listen on that notification instead, and
we'll be e10s compatible.
MozReview-Commit-ID: EowFDfdWgAJ
--HG--
extra : rebase_source : ad01990278cf9005f6676ef0b7fa0acbf69249eb
CGBridgeLayer was only ever constructed with aAvoidCGCrashes as false so its property mAvoidCGCrashes was removed and all conditionals that relied on it were removed. This also resulted in protectLastCGContext never doing any work so it was removed as well. r=spohl
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
We're supposed to reject MediaKeySystemCapabilities which have a contentType
that has codecs which don't match their major type, i.e. audio codecs in a
video container type.
I missed that, and it's causing us to fail the
test_eme_requestMediaKeySystemAccess case "MP4 video container with both audio
and video codec type in videoType".
MozReview-Commit-ID: KQVGk9hX3eC
--HG--
extra : rebase_source : f8ed145d050bb27f2f6867ec4b308bbcd30d17a5
The Adobe GMP only supports up to GMPDecryptor version 7. We're now up to
version 9. So we need to provide an adaptor to convert the old version to run
with the new interface.
MozReview-Commit-ID: 5dKreev7JMv
--HG--
extra : rebase_source : b9aa1b66ad23e9f7ddbe60b71c94c161ad974818
The only thing we're now not up to date on (in terms of WebIDL) is the
"persistent-usage-record" MediaKeySessionType.
MozReview-Commit-ID: 4CKK35HAxKK
--HG--
extra : rebase_source : 2015a2d0c61e09e329f5f9cc699f5d946e97862b
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
As requested by Jonas, we should put a note in the test in case someone
would like to re-enable this in the future.
Right now the test will trigger the mismatch loadInfo and loadContext,
because it's using System Principal to fetch sub-resources, hence its
loadInfo doesn't have the isIsolatedMozBrowser flag set.
Now everything is ready. We can make NotifyQueuedTrackChanges only triggered by TRACK_EVENT_CREATED and TRACK_EVENT_ENDED without breaking anything. Also we make TrackUnionStream no longer copying data in video case.
MozReview-Commit-ID: IgLx1mpBWB3
--HG--
extra : transplant_source : %9Fk%8F%20%FE%12%FC%DF%A0%C6%02%AC%D2%3C%EE%08%26%E3%9E%27
Now everything is ready. We can make NotifyQueuedTrackChanges only triggered by TRACK_EVENT_CREATED and TRACK_EVENT_ENDED without breaking anything. Also we make TrackUnionStream no longer copying data in video case.
MozReview-Commit-ID: IgLx1mpBWB3
--HG--
extra : transplant_source : %21M%C5%07%B9%CB%16%96%D6gN%C0g%0A%E8%7D%A0%AB%98%26
Now everything is ready. We can make NotifyQueuedTrackChanges only triggered by TRACK_EVENT_CREATED and TRACK_EVENT_ENDED without breaking anything. Also we make TrackUnionStream no longer copying data in video case.
MozReview-Commit-ID: IgLx1mpBWB3
--HG--
extra : amend_source : 2c57e72a84dee45f673d7d02eaa8c973ca9f634a
Add MediaStreamVideoRecorderSink into MediaEncorder. In this patch, I still keep use duration to pass to TrackEncoders. Don't want to make this bug too big and out of control. We can file a new bug to change TrackEncoders use TimeStamp only.
MozReview-Commit-ID: KGftzulZynj
--HG--
extra : transplant_source : %3A%8Dv%85%A3%D8Y%99%D6%BB%A1%0A%BB%DE%806%C1yV%28
Add MediaStreamVideoRecorderSink into MediaEncorder. In this patch, I still keep use duration to pass to TrackEncoders. Don't want to make this bug too big and out of control. We can file a new bug to change TrackEncoders use TimeStamp only.
MozReview-Commit-ID: KGftzulZynj
--HG--
extra : transplant_source : %E9%22B%90%D6%CF%08%12X%D1%E2%17%90%99%B2%91%24B%EA%1D
Add MediaStreamVideoRecorderSink into MediaEncorder. In this patch, I still keep use duration to pass to TrackEncoders. Don't want to make this bug too big and out of control. We can file a new bug to change TrackEncoders use TimeStamp only.
MozReview-Commit-ID: KGftzulZynj
--HG--
extra : amend_source : 90fd7ddab4ecda4b95cd77c705cfb29692782de9
Make CaptureTask to inherite from MediaStreamVideoSink. The main change is to move the logic of |NotifyQueuedTrackChanges| to |SetCurrentFrames|.
The original image capture is not modified for support multiple video MediaStreamTracks. The design still used the track id in owned media stream. The should be fixed in the following bug if we still want to support ImageCapture in multiple video tracks case.
MozReview-Commit-ID: Od4tHoR8Ef
--HG--
extra : transplant_source : %8D%848%99%1C%DFOz%40r%D5%F4%85%10%9A6%E1%A6%3Fs
In this patch, we first deal with the case of MediaElement. Now we replace |PlayVideo| with |VideoFrameContainer::SetCurrentFrames| in |SourceMediaStream::AppendToTrack|. The MSG use TimeStamp::Now() for the TimeStamp of each video frame in most of case except MediaElement case. Becasue the MediaElement has its own VideoQueue, we need to calucalte the correct Timestamp based on the StartTimeStamp of this MediaStream and the elpased time of the video frame in DecodedStream.
MozReview-Commit-ID: 2bm2AHkFXHu
--HG--
extra : transplant_source : %C4n%D7a%10%CFK%D5%F2%DC%10%08%C2%24%EC%11%13J%DB%5D
Make CaptureTask to inherite from MediaStreamVideoSink. The main change is to move the logic of |NotifyQueuedTrackChanges| to |SetCurrentFrames|.
The original image capture is not modified for support multiple video MediaStreamTracks. The design still used the track id in owned media stream. The should be fixed in the following bug if we still want to support ImageCapture in multiple video tracks case.
MozReview-Commit-ID: Od4tHoR8Ef
--HG--
extra : transplant_source : %AA%1BD%20%1D%8F%D0%9A%5B%9C%7Ef%A0%1C%E9%D7%EE%AE%E6%93
In this patch, we first deal with the case of MediaElement. Now we replace |PlayVideo| with |VideoFrameContainer::SetCurrentFrames| in |SourceMediaStream::AppendToTrack|. The MSG use TimeStamp::Now() for the TimeStamp of each video frame in most of case except MediaElement case. Becasue the MediaElement has its own VideoQueue, we need to calucalte the correct Timestamp based on the StartTimeStamp of this MediaStream and the elpased time of the video frame in DecodedStream.
MozReview-Commit-ID: 2bm2AHkFXHu
--HG--
extra : transplant_source : %3D%AA%00%CE%A3SV5%8F%84%96%AC%E2%D9%10%EC%85%07N%DF
Make CaptureTask to inherite from MediaStreamVideoSink. The main change is to move the logic of |NotifyQueuedTrackChanges| to |SetCurrentFrames|.
The original image capture is not modified for support multiple video MediaStreamTracks. The design still used the track id in owned media stream. The should be fixed in the following bug if we still want to support ImageCapture in multiple video tracks case.
MozReview-Commit-ID: Od4tHoR8Ef
--HG--
extra : amend_source : a3318f6fd3d9104c2f84a8ed5e79cf68f304308c
In this patch, we first deal with the case of MediaElement. Now we replace |PlayVideo| with |VideoFrameContainer::SetCurrentFrames| in |SourceMediaStream::AppendToTrack|. The MSG use TimeStamp::Now() for the TimeStamp of each video frame in most of case except MediaElement case. Becasue the MediaElement has its own VideoQueue, we need to calucalte the correct Timestamp based on the StartTimeStamp of this MediaStream and the elpased time of the video frame in DecodedStream.
MozReview-Commit-ID: 2bm2AHkFXHu
--HG--
extra : amend_source : 7b9c51dcb4046c6c807d1cf1e48bef301e45fa8e
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
The WebRTC implementation inherits cipher suite preferences from PSM and then
enables a few mandatory ones and disables a number of undesirable ones. If PSM
makes a change to a cipher suite preference that isn't in WebRTC's whitelist or
blacklist, compatibility issues can arise. See bug 1288246 for an example.
--HG--
rename : security/manager/ssl/tests/unit/test_fallback_cipher.js => security/manager/ssl/tests/unit/test_weak_crypto.js
The Mozilla Location Service is the fallback for gpsd. If no location
information is received from GSP within a few seconds, MLS provides a
position. It will be updated once GPS is ready. If GPS fails, MLS will
take over again until GPS has been restored.
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
Gpsd is the GPS daemon on Linux. It implements support for a wide range
of GPS receivers. This patch adds support for gpsd to the Geolocation
module.
The build system can now test for libgps, which provides the public
interface to gpsd's functionality. If found, |GpsdLocationProvider|
is added to the build.
MozReview-Commit-ID: 1kBgFdEZePI
We don't actually need to re-calculate if the updated properties are the
same as the old one. This change avoids problematic nested calls of
nsStyleSet::GetContext() in particular cases.
MozReview-Commit-ID: JksiTGX57Fy
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %9D%86%93%A6%DF%D5%9Ep%20%DF%FD%C1%E2%BA%A3Gq%1A%7E%A3
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %008z%D8W%EE%87%8E%E9/%2CT%26%EBvo%AE%099%A6
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : amend_source : 7eb1e87fdcbc61f2f9831fa3a6d803cc50306604
There were a couple of problems when delivering tap gestures to content with
full zoom applied. One was that the ConverToGecko function converted the coords
into "CSS pixel" space by using the web content's CSS-to-LD scale, but also
applied that on the translation from the chrome area. Moving that conversion
to later in the process (after the coords got passed through TabParent::
AdjustTapToChildWidget) corrected that issue.
The other problem was that bits of code in APZEventState and APZCCallbackHelper
were using the widget->GetDefaultScale() value as the CSS-to-LD scale, but that
omitted the full zoom value. Getting the CSS-to-LD scale from the presShell and
propagating that through corrected that issue.
MozReview-Commit-ID: KdrkdEZslHo
By the time that the parent is being asked to create a new window, the name
really doesn't matter anymore.
MozReview-Commit-ID: 4IKrEEylaLY
--HG--
extra : rebase_source : bcb7e316534c522a5ff8d7be336c940eccffbe3e
extra : source : e91913cd64b8bebe80c661935adee644f24c6055
Before this commit, one could either capture all stack frames (by passing
maxFrameCount = 0) or a maximum of N frames (by passing maxFrameCount = N). This
commit introduces the ability to capture the first frame (by default ignoring
self hosted frames) with some target principals. This new option required
replacing the `unsigned maxFrameCount` parameter with the introduction of a new
sum type to describe the stack capturing behavior:
StackCapture = AllFrames
| MaxFrames(unsigned n)
| FirstSubsumedFrame(JSPrincipals* p, bool ignoreSelfHosted)
This is obviously more wordy in C++ than we'd like, but does make the stack
capturing more explicit rather than relying on the sentinal 0 to stand in for
infinity.
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.
Chih-Yi Leu
James Cheng
Shih-Chiang Chien
Xidorn Quan
Ben Kelly
Daniel Holbert
Thomas Wisniewski
bechen
Olli Pettay
Jeff Gilbert
Geoff Brown
Bobby Holley
Emilio Cobos Álvarez
Eric Rahm
Andrew McCreight
Kyle Machulis
Jonathan Chan
John Dai
Boris Zbarsky
Nicolas Silva
Carsten "Tomcat" Book
Gerald Squelart
Daisuke Akatsuka
Mike Hommey
Wes Kocher
Chris Pearce
Benoit Girard
Christoph Kerschbaumer
JW Wang
Iris Hsiao
Sotaro Ikeda
Hiroyuki Ikezoe
Matt Woodrow
Kartikaya Gupta
Matthew Gregan
Andrea Marchesini
Jan-Ivar Bruaroey
Boris Chiou
Tim Huang
Jim Mathies
Ethan Lin
isangelawu
Haik Aftandilian
Kate McKinley
Kilik Kuo
Morris Tseng
Gijs Kruitbosch
Chris Peterson
Manish Goregaokar
Sebastian Hengst
Jessica Jong
Neil Deakin
Geoff Lankow
Franziskus Kiefer
Phil Bystrican
Jan de Mooij
Lee Salzman
Blake Kaplan
JerryShih
Nathan Froyd
Stone Shih
Alex Chronopoulos
Alexandre Lissy
Yoshi Huang
Johann Hofmann
Robert Longson
Jonathan Watt
David Zbarsky
Eugen Sawin
ctai
Wei-Cheng Pan
David Keeler
Paul Adenot
Thomas Zimmermann
Cervantes Yu
Mike Conley
Karl Tomlinson
Nick Fitzgerald
Ryan VanderMeulen
Jim Chen
Andi-Bogdan Postelnicu
David Anderson