735ae776c393e7c2f7c9d64a12a61b5f7689a583: Bug 1271796 use raw bytes to calculate SRI hash r=francois
Kate McKinley <kmckinley@mozilla.com> - Mon, 05 Sep 2016 12:55:25 +0200 - rev 417625
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1271796 use raw bytes to calculate SRI hash r=francois MozReview-Commit-ID: F62t5CnsYlJ
d82676c65f7a06c8c1ce457672d2b789566c120b: Bug 882674 - Implement "pending text track change notification flag". r=rillian
bechen <bechen@mozilla.com> - Wed, 21 Sep 2016 16:01:22 +0800 - rev 417624
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 882674 - Implement "pending text track change notification flag". r=rillian MozReview-Commit-ID: G1L1ECWvNnD
1e8a7c6dcea1d73db0da4c61b2dfe4b4cbaec79f: Bug 1284588 - OS X: Disable content process write access to user files in the home directory; r=gcp
Haik Aftandilian <haftandilian@mozilla.com> - Thu, 22 Sep 2016 19:21:13 -0700 - rev 417623
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1284588 - OS X: Disable content process write access to user files in the home directory; r=gcp 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
fca01042a6099831f0250882f568710a731a2d17: Bug 1305064 - New console frontend: Fix cached message handling. r=bgrins
Lin Clark <lclark@mozilla.com> - Fri, 23 Sep 2016 16:01:20 -0400 - rev 417622
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1305064 - New console frontend: Fix cached message handling. r=bgrins
8f1247747f3ecabb9dbbe89047ca36567209076f: Bug 1305182 - Release thumbnailClient in the unittest tearDown r=ahunt
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 23 Sep 2016 16:43:10 -0700 - rev 417621
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1305182 - Release thumbnailClient in the unittest tearDown r=ahunt MozReview-Commit-ID: KoW42T57gna
f0185f22f35c84030a1c6329dc23aececaf7ba28: Backed out 2 changesets (bug 1296900) for mochitest failures in test_ext_all_apis.html a=backout
Wes Kocher <wkocher@mozilla.com> - Fri, 23 Sep 2016 16:15:05 -0700 - rev 417620
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Backed out 2 changesets (bug 1296900) for mochitest failures in test_ext_all_apis.html a=backout Backed out changeset c37cf3cfd39c (bug 1296900) Backed out changeset 998ed8336288 (bug 1296900)
89fc0a741450051c0243a264f0c8ee4ceb071395: Bug 1304961 - Retrieve buffered ranges in VideoPuppeteer. r=maja_zf
Bryce Van Dyk <bvandyk@mozilla.com> - Fri, 23 Sep 2016 17:52:57 +1200 - rev 417619
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304961 - Retrieve buffered ranges in VideoPuppeteer. r=maja_zf Update VideoPuppeteer and make small changes in YoutubePuppeteer to support retrieval of buffered ranges for wrapped video element. This will help diagnose test failures, particularly stalls we're having at the moment. Because the namedtuple storing state has all its fields logged the __str__ methods of the puppeteers don't need to be updated, the new field will be logged automatically. MozReview-Commit-ID: LYwXJfB71RE
9efa0b30eab2794efca785b24a19934d9a112dbd: Bug 1304961 - Rename variables storing played ranges to be more specific. r=maja_zf
Bryce Van Dyk <bvandyk@mozilla.com> - Fri, 23 Sep 2016 17:24:40 +1200 - rev 417618
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304961 - Rename variables storing played ranges to be more specific. r=maja_zf The played ranges being retrieved in VideoPuppeteer and YoutubePuppeteer were often referenced as some variation of 'time ranges'. This patch makes that more specific and references the played ranges as variations of 'played ranges'. This removes ambiguity if other time ranges are retrieved in future, such as the buffered ranges. MozReview-Commit-ID: CInjDCCIQkV
b451b91d4b4687f248bc7b2a4b959c7bd7459790: Bug 1302601 - Fix broken tests - poor method override r=ahunt
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 23 Sep 2016 13:27:45 -0700 - rev 417617
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1302601 - Fix broken tests - poor method override r=ahunt MozReview-Commit-ID: DX2gTqXngiq
c37cf3cfd39c46473dc3610ac4918652c18c3acb: Bug 1296900 - Hide commands API if manifest key is missing r=kmag
Rob Wu <rob@robwu.nl> - Sat, 20 Aug 2016 23:01:43 -0700 - rev 417616
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1296900 - Hide commands API if manifest key is missing r=kmag MozReview-Commit-ID: 7vld6MgSlqG
998ed833628815b2fc4fdec97dd6619a697ea634: Bug 1296900 - Add test for availability of default WebExtension APIs r=kmag
Rob Wu <rob@robwu.nl> - Sat, 20 Aug 2016 22:21:45 -0700 - rev 417615
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1296900 - Add test for availability of default WebExtension APIs r=kmag MozReview-Commit-ID: LIr5Nsv51I3
2146f5e5c5df45ec2ab4493fcdd947a7fa08f423: Bug 1303405 - Ensure `RemoveFolderTransaction::UndoTransaction` passes the reinserted GUID to observers. r=mak
Kit Cambridge <kcambridge@mozilla.com> - Fri, 16 Sep 2016 13:22:47 -0700 - rev 417614
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1303405 - Ensure `RemoveFolderTransaction::UndoTransaction` passes the reinserted GUID to observers. r=mak MozReview-Commit-ID: 5HpDKEmsjRW
a8254e91e0fed9395c238d5b60867c7907fa261a: Bug 1305061 - Don't run l10n try jobs on aurora. r=dustin
Justin Wood <Callek@gmail.com> - Fri, 23 Sep 2016 11:17:19 -0400 - rev 417613
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1305061 - Don't run l10n try jobs on aurora. r=dustin MozReview-Commit-ID: 9ReCdHUg1iY
d5355738ce1edf58cabee849024c7bd02c641b77: Bug 1304176 - Document and refactor query_virtualenv_path; r=ted
Gregory Szorc <gps@mozilla.com> - Tue, 20 Sep 2016 14:59:14 -0700 - rev 417612
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304176 - Document and refactor query_virtualenv_path; r=ted We don't need a variable to hold the result. Just use return. The "virtualenv_path" option has a default value, so it should always be set. Add code confirming that. And refactor the code to use less indentation. And remove a branch that can never occur since the virtualenv path is guaranteed to be defined. MozReview-Commit-ID: DZ6LnlxZJFj
1c0787d40b9722d31c09f243b543c64de78473ec: Bug 1304176 - Remove --venv-path as an alias to --virtualenv-path; r=ted
Gregory Szorc <gps@mozilla.com> - Tue, 20 Sep 2016 14:46:52 -0700 - rev 417611
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304176 - Remove --venv-path as an alias to --virtualenv-path; r=ted Not sure why we support this. The code goes all the way back to the import of mozharness 0.4 into the old mozharness Mercurial repo in bug 651974. Having fewer variations makes it easier to search for usage. So nuke the variation. MozReview-Commit-ID: IgwLMdvXGB0
8dc87cef62fb3dddae89f2a6a5099bb7dbaa6ebc: Bug 1304176 - Remove PIP_TRUSTED_HOST and trust-host pip.conf option; r=ted
Gregory Szorc <gps@mozilla.com> - Tue, 20 Sep 2016 14:02:08 -0700 - rev 417610
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304176 - Remove PIP_TRUSTED_HOST and trust-host pip.conf option; r=ted The Python code is now intelligent enough to add this flag on the command line if supported. Eliminate the copy pasta and help prevent cargo culting. MozReview-Commit-ID: H4rbjbbgtRd
3fd83c9c0548b3f07c844a2f6c3a23ae7569eecd: Bug 1304176 - Use vendored virtualenv if available; r=ted
Gregory Szorc <gps@mozilla.com> - Tue, 20 Sep 2016 21:19:56 -0700 - rev 417609
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304176 - Use vendored virtualenv if available; r=ted If mozharness is running from a source checkout, it has access to a modern virtualenv+pip/setuptools vendored as part of the source checkout. This commit changes the virtualenv creation code to use the vendored virtualenv when it is available. A side effect of this change is that a modern version of pip will now be used by mozharness when a source checkout is available. This has a number of consequences. First, modern versions of pip automatically create and cache wheels when building packages. This should make automation faster since it can now reuse cached wheels instead of having to download and rebuild packages all the time. Second, modern versions of pip support pinning package hashes. This opens the door to use having more secure package downloads and more determinism in our test environment. Third, modern versions of pip require connections to package servers be secure by default. Plaintext connections are disallowed by default. A --trusted-host option or environment variable can be used to override this behavior. Since upgrading pip resulted in some jobs failing due to disallowed connections to insecure servers, code to sniff the pip version and add --trusted-host where it is needed/supported. This retains the existing behavior. This is insecure. But fixing that is for another bug. As part of testing this, we were getting IOError inside virtualenv.py when installing distutils: IOError: [Errno 13] Permission denied: '/builds/slave/test/build/venv/lib/python2.7/distutils/__init__.py' We worked around this by adding --always-copy to the virtualenv.py invocation. MozReview-Commit-ID: D29ao9ZASei
b64330d3db8d5091927308dc91ac1cfd5ec7b7ad: Bug 1304176 - Use vendored tooltool.py if available; r=ted
Gregory Szorc <gps@mozilla.com> - Tue, 20 Sep 2016 12:36:33 -0700 - rev 417608
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304176 - Use vendored tooltool.py if available; r=ted Now that we can detect when we're running from a source checkout, we can start using things from source checkouts instead of relying on host machine state or grabbing files from another server. We start by using the vendored tooltool.py if available. This avoids non-determinism. It avoids a possible 3rd party hosting dependency on github.com. It avoids a possible MitM attack vector. Wins all around. MozReview-Commit-ID: L6hLveHZxBR
2e07640f74cf7531b8b2077d519557a680fea456: Bug 1304176 - Set BaseScript.topsrcdir if we have a source checkout; r=ted
Gregory Szorc <gps@mozilla.com> - Tue, 20 Sep 2016 11:28:52 -0700 - rev 417607
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304176 - Set BaseScript.topsrcdir if we have a source checkout; r=ted We're going to start executing more mozharness scripts from a source checkout. Rather than add config options to specify the location of a source checkout - something that must be added to every mozharness invocation - we teach BaseScript.__init__ to recognize when we're running from a source checkout and set self.topsrcdir accordingly. This will allow any script or class to check for self.topsrcdir and change behavior accordingly. MozReview-Commit-ID: 3uxOjol7ntR
27a183a2527cc4190691595c782b6fe53512af1b: Bug 1304282 - Disable output buffering from mozharness spawned processes; r=ted
Gregory Szorc <gps@mozilla.com> - Tue, 20 Sep 2016 23:04:37 -0700 - rev 417606
Push 30444 by bmo:pbrosset@mozilla.com at Mon, 26 Sep 2016 14:07:09 +0000
Bug 1304282 - Disable output buffering from mozharness spawned processes; r=ted Without this, process output is buffered by default. This means timestamps that mozharness prefixes to process output aren't accurate unless the process is spewing enough output to flush the output buffer. Output buffering could lead to bad things. For example, a process could emit output that would cause mozharness's output monitor to abort the process. However, if that output is caught in limbo in the output buffer, mozharness may take several seconds or even minutes to react. With this change, the mozharness process receives process output as soon as that process writes to its standard file descriptors. Once a newline is seen, mozharness will process it immediately. Note that this only impacts the case where there is no output timeout, as the existing code for output timeout uses mozprocess and I'm pretty sure mozharness doesn't buffer output. MozReview-Commit-ID: HBkYnfEw7Hb
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip