507d849ea8f4ffc8cd51550d6c86b85b3faed05b: Bug 1267557 part 0 - Move JS poison constants to jsutil.h. r=jonco a=ritu
Jan de Mooij <jdemooij@mozilla.com> - Thu, 28 Apr 2016 13:38:05 +0200 - rev 365884
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1267557 part 0 - Move JS poison constants to jsutil.h. r=jonco a=ritu
f996c47e3cfeb190bc4a928f1e605ddcb29a70d4: Bug 1266878 - Fix off-by-one error in ParamTraits<StereoMode> - r=nical, a=ritu
Edwin Flores <eflores@mozilla.com> - Mon, 25 Apr 2016 18:09:59 +0100 - rev 365883
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1266878 - Fix off-by-one error in ParamTraits<StereoMode> - r=nical, a=ritu
f08801dfeb2d33a8c7415d4745f3c17cd0a79123: Bug 1264780 - Handle destructuring cases when forcing binding initialization; r=bgrins a=ritu
Morgan Phillips <winter2718@gmail.com> - Fri, 15 Apr 2016 19:01:09 -0700 - rev 365882
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1264780 - Handle destructuring cases when forcing binding initialization; r=bgrins a=ritu
38353172c113bc15326531c994a57777baec9a60: Bug 1267567 - Unit test for non-ASCII AutoConfig files. r=mkaply a=ritu
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Sat, 07 May 2016 00:06:33 +0900 - rev 365881
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1267567 - Unit test for non-ASCII AutoConfig files. r=mkaply a=ritu
845ee0a38186e90851c3d7ee49ac83da1aea3b7e: Bug 1267567 - Treat string prefs as Unicode when the script encoding is UTF-8. r=mkaply a=ritu
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Sat, 07 May 2016 00:06:33 +0900 - rev 365880
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1267567 - Treat string prefs as Unicode when the script encoding is UTF-8. r=mkaply a=ritu
16291dce26a20da5036ff92a04151d1995c95d30: Bug 1269165 - Restore ALSA plugins detection on non-Linux after bug 757637. r=jesup a=ritu
Jan Beich <jbeich@FreeBSD.org> - Sat, 30 Apr 2016 21:52:00 -0400 - rev 365879
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1269165 - Restore ALSA plugins detection on non-Linux after bug 757637. r=jesup a=ritu
3ea4c28099c532e6b3cff46265627364f301f496: Bug 1261375 fix load handling in pocket panel, r=gijs a=ritu
Shane Caraveo <scaraveo@mozilla.com> - Wed, 04 May 2016 09:19:10 -0700 - rev 365878
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1261375 fix load handling in pocket panel, r=gijs a=ritu
2b710898eaf609aa9dc45fd75e03bc134d20f6b8: Bug 1270968 - Build fix for Beta. a=bustage
Chris Pearce <cpearce@mozilla.com> - Tue, 10 May 2016 08:44:50 +1200 - rev 365877
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1270968 - Build fix for Beta. a=bustage Bug 1268313 renamed NS_NewRunnableMethod to mozilla::NewRunnableMethod, but that hasn't been uplifted, causing this bustage.
a2b29f3391d7978754a78dc5035c11f939494715: Bug 1270968 - Add mechanism to clear GMP storage when its version changes. r=gerald,a=ritu,ba=cpearce
Chris Pearce <cpearce@mozilla.com> - Sat, 07 May 2016 09:19:15 +1200 - rev 365876
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1270968 - Add mechanism to clear GMP storage when its version changes. r=gerald,a=ritu,ba=cpearce In bug 1264497 we discovered that Netflix was broken because we'd made a change to not send the Adobe GMP the device bound nodeId, which it stored in GMP storage. When the GMP was comparing the nodeId it had stored against what it was passed (nothing) the comparison was failing. Users could have worked around this problem by clearing their GMP storage, whereupon the Adobe GMP will have stored "nothing" as its nodeId. When bug 1264497 was fixed, users who'd cleared their storage will see Netflix fail again, as their stored nodeId of "nothing" will again not match what we pass in. So to fix Netflix for these users, we need to clear GMP storage. This is another instance of a more general problem that we have occasionally encountered, namely that sometimes GMP storage becomes incompatible, and we need to clear it. Having a general mechanism that we can use to clear storage remotely will be helpful, so this patch adds one, and triggers it to fire. This mechanism is pref controlled, so that we can issue a hotfix if necessary to clear GMP storage. MozReview-Commit-ID: GzSyBj0P2JG
a0c1f2f189a2d1821b7b3b59ea92d3ede0e8661f: Bug 1269185 - Prevent crashes in Windows when zip files cannot be read. r=spohl,a=ritu
Kirk Steuber <ksteuber@mozilla.com> - Wed, 04 May 2016 12:57:21 -0700 - rev 365875
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1269185 - Prevent crashes in Windows when zip files cannot be read. r=spohl,a=ritu MozReview-Commit-ID: 32uEegoKL4J
694986f3c9868adae58bceae6035acc88eb87ca7: Bug 1268984 - Prefer to re-use a GMPParent with the requested nodeId rather than clone. r=jesup,a=ritu
Chris Pearce <cpearce@mozilla.com> - Thu, 05 May 2016 22:35:44 +1200 - rev 365874
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1268984 - Prefer to re-use a GMPParent with the requested nodeId rather than clone. r=jesup,a=ritu If you request a GMPParent with a nodeId, you should get any already running instances with the same nodeId in preference to cloning an existing GMP and assigning it the nodeId. This is ensures that EME GMP actors that are same-origin run in the same GMP instance. The GMP gtests are failing because of the cross-origin checks in GeckoMediaPluginServiceParent::SelectPluginForAPI(). The loop there selects the first GMPParent that can be used from the nodeId passed in. We previously assumed a GMPParent can be used from a nodeId if the GMPParent has the same nodeId, or if it has not loaded its process and it has no nodeId. The problem with assuming that, is if an in-use GMPParent with the target nodeId lies in the GeckoMediaPluginServiceParent::mPlugins list after a GMPParent with no nodeId, we'll end up using the first GMPParent (the one with no nodeId) rather than the one with the target nodeId. The solution is to change GeckoMediaPluginServiceParent::SelectPluginForAPI() so that effectively if we have a target nodeId, we'll select the first GMPParent that has the same nodeId, or we'll clone the first which supported all the requested capabilities/tags. This means when you request a GMPParent with a given nodeId, you'll get the one with the same nodeId (origin) by preference. MozReview-Commit-ID: 4yVnrO8B1Pg
1182c6ecfe5e6e3741c4a2e8b991cd4420579387: Bug 1268984 - Store GMPStorage on GMPServiceParent so that it persists inside the same PB session. r=gerald,a=ritu
Chris Pearce <cpearce@mozilla.com> - Thu, 05 May 2016 11:41:33 +1200 - rev 365873
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1268984 - Store GMPStorage on GMPServiceParent so that it persists inside the same PB session. r=gerald,a=ritu Prior to this change, we'd store the GMPStorage records for private browsing sessions in the GMPStorageParent. The problem with this is that they only have a lifespan matching their corresponding GMPParent. This means that if a GMP stores something in a PB session, and the GMP is shutdown and then re-created, we are likely to loose the stored data. This could mean that the PB session gets results it doesn't expect, and thus expose a way for PB mode to be detected. MozReview-Commit-ID: 1OMD0LvidYs
254daaf1315f97c19f2fbd9dbefae7ec2f135399: Bug 1268984 - Ensure GMPs are re-inserted in GMPServiceParent::mPlugins in the same order in ReAddOnGMPThread. r=gerald,jesup,a=ritu
Chris Pearce <cpearce@mozilla.com> - Wed, 04 May 2016 13:57:20 +1200 - rev 365872
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1268984 - Ensure GMPs are re-inserted in GMPServiceParent::mPlugins in the same order in ReAddOnGMPThread. r=gerald,jesup,a=ritu The GMP which GeckoMediaPluginServiceParent::FindPluginForAPIFrom() returns depends on the order in which GMPs lie in GMPServiceParent::mPlugins. However when we shutdown a GMPParent we remove and then re-append the GMPParent to mPlugins. This means the order in which GMPs lie in the list changes. So when WebRTC requests an H.264 decoder, the first time it will get OpenH264, since that's first in the list. But once we dispose of that decoder, its GMPParent will be cloned and the clone will be appended to the end of the list. This means the next time WebRTC requests a decoder, it'll get whatever was next in the list. This could be the Adobe GMP, which seems to be able to handle whatever WebRTC is putting into it. However, if you do this enough times, you'll get the Widevine CDM, which can't handle whatever WebRTC is putting into it. So a quick hack to fix this is in ReAddOnGMPThread is to re-insert the clone of the GMP into the slot in mPlugins that the original occupied. Then WebRTC will always get OpenH264 whenever it requests for an H.264 decoder, as the order of the GMPParents in mPlugins won't change. MozReview-Commit-ID: Ii4AMqDqAo9
073989f714c8ade2740d57fa6b64b9ea388e88a0: Bug 1264497 - Call GMPSetNodeId in GMPLoader. r=gerald,a=ritu
Chris Pearce <cpearce@mozilla.com> - Fri, 06 May 2016 14:49:12 +1200 - rev 365871
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1264497 - Call GMPSetNodeId in GMPLoader. r=gerald,a=ritu MozReview-Commit-ID: I6BApLKpjPS
5f0df9e62467f647b93c1df8dbec87227c0d1cb6: Bug 1266336 - Clarify expected usage of CDM wrapper - r=cpearce,a=ritu
Gerald Squelart <gsquelart@mozilla.com> - Fri, 06 May 2016 12:10:59 +1000 - rev 365870
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1266336 - Clarify expected usage of CDM wrapper - r=cpearce,a=ritu Assert that the CDM wrapper is given a non-null CDM pointer. (so GetCDM() doesn't need to be null-checked.) Renamed WidevineVideoDecoder mCDM to mCDMWrapper, to avoid (my) confusion. Assert that WidevineVideoDecoder is given a non-null CDM-wrapper pointer. Assert that WidevineVideoDecoder only accesses the CDM before DecodingComplete. Small optimization: Move aCDM into mCDM (to save an AddRef/Release pair). MozReview-Commit-ID: yKupY067ly
5495417dc2fc341cd9efa55bb81c6a8ebed58c52: Bug 1266336 - Check actual CDM creation - r=cpearce,a=ritu
Gerald Squelart <gsquelart@mozilla.com> - Thu, 05 May 2016 12:04:07 +1000 - rev 365869
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1266336 - Check actual CDM creation - r=cpearce,a=ritu Check the return result from Widevine's CDM creation function, and handle failure. MozReview-Commit-ID: HYvKgdK53aQ
44a9281f2a77ca666da022d005610c3caa7a3038: Bug 1266336 - Check sCDMWrapper before creating video decoder - r=cpearce,a=ritu
Gerald Squelart <gsquelart@mozilla.com> - Thu, 05 May 2016 11:37:22 +1000 - rev 365868
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1266336 - Check sCDMWrapper before creating video decoder - r=cpearce,a=ritu Ensure that there is a CDM before creating a video decoder that relies on that CDM. This is mainly to prevent using the Widevine video decoder alone, without decryption. MozReview-Commit-ID: 7p49CnmV2r7
7ce8790265c6886eee94e5aa8438c06f1c645681: Bug 1266286 - Ensure crash reports work for GMP used by EME code. r=mconley,a=ritu
Chris Pearce <cpearce@mozilla.com> - Wed, 04 May 2016 20:32:00 -0400 - rev 365867
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1266286 - Ensure crash reports work for GMP used by EME code. r=mconley,a=ritu Crash reporting for GMPs being used from the EME call site are not generating crash reports because they depend on the MediaKeys object calling GMPService::AddPluginCrashHandler() to associate a window to which the PluginCrashedEvent is fired. This doesn't work with e10s enabled because the GMPParent which causes the plugin crash handlers to run is in the chrome process, but the MediaKeys which adds the handler is in the child process. So the crash handler is on the GMPServiceChild, but we only run the crash handlers that were added to the GMPServiceParent in the chrome/parent process. The solution is to broadcast a message from the chrome process to all the content processes when a GMP has crashed that causes the GMPServiceChild to also run its crash handlers. MozReview-Commit-ID: 8Lek16G9ZGb
fc51f034e4aca08b76934a832d7dc7db1954b9d2: Bug 1264187 - check for a ProtoAndIfaceCache before blindly destroying it; r=bz, a=ritu
Nathan Froyd <froydnj.com> - Thu, 14 Apr 2016 11:42:34 -0400 - rev 365866
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
Bug 1264187 - check for a ProtoAndIfaceCache before blindly destroying it; r=bz, a=ritu We normally create global objects in the DOM bindings via: 1. Call JS_NewGlobalObject. 2. Set a private slot to hold a ProtoAndIfaceCache. 3. Other steps that aren't relevant here. However, it's possible for step 1 to construct a global inside the JS engine and then fail to initialize it in some way. When that happens, the newly-created object will be subjected to GC and any GC-related hooks that were passed in to JS_NewGlobalObject. Which implies that our tracing and finalization hooks must be prepared to handle an object that's not fully initialized--i.e. doesn't have a ProtoAndIfaceCache object allocated for it. We handled such a case in our trace hook, but we failed to add the same check for our finalization hook. Do so.
0eb768d9a992290e12083c4f65f0c64c22517233: No bug, Automated blocklist update from host bld-linux64-spot-1053 - a=blocklist-update
ffxbld - Sat, 07 May 2016 03:16:12 -0700 - rev 365865
Push 17839 by bmo:jyavenard@mozilla.com at Wed, 11 May 2016 13:59:51 +0000
No bug, Automated blocklist update from host bld-linux64-spot-1053 - a=blocklist-update
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip