When `pip` encounters an error during mach bootstrapping in `mach_bootstrap.py` there is no error log because of `-q`. The output will only be read when an error was encountered, so this looks like an unintended mistake.
---
This gives error outputs like:
```
D:\Code\moz\servo>mach.bat -h
Pip failed to execute properly:
Output: Collecting marionette_driver>=2.4 (from -r D:\Code\moz\servo\tests\wpt\web-platform-tests\tools\wptrunner\requirements_firefox.txt (line 1))
Using cached marionette_driver-2.4.0.tar.gz
Collecting mozprofile>=0.21 (from -r D:\Code\moz\servo\tests\wpt\web-platform-tests\tools\wptrunner\requirements_firefox.txt (line 2))
Using cached mozprofile-0.28.tar.gz
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Users\$USER\AppData\Local\Temp\pip-build-zqivz5en\mozprofile\setup.py", line 12, in <module>
assert sys.version_info[0] == 2
AssertionError
----------------------------------------
Error: Command "python setup.py egg_info" failed with error code 1 in C:\Users\$USER\AppData\Local\Temp\pip-build-zqivz5en\mozprofile\
```
instead of:
```
D:\Code\moz\servo>mach.bat -h
Pip failed to execute properly:
Output:
Error: Command "python setup.py egg_info" failed with error code 1 in C:\Users\$USER\AppData\Local\Temp\pip-build-htd5no9k\mozprofile\
```
Source-Repo: https://github.com/servo/servo
Source-Revision: b5b24559254f265a6783c3e91a833d51319dccfa
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 304689f45f488ccddaf0547df80f066bf199b484
New stable release.
We leave the win32 builds on rust 1.21.0 for now:
- Building with 1.22.1 fails on win32 opt, we think, because
the code tree passed to llvm exhausts 32-bit address space
under -Clto. Bug 1417268.
- Resolving the above by building with 64-bit rust is blocked
by build.rs scripts not picking up the correct platform in
automation builds. Bug 1401647.
- Building with 1.23.0-beta.1 fails on win32 debug with a
bindgen panic. Bug 1420301.
MozReview-Commit-ID: 9Q1K7dSBlEv
--HG--
extra : rebase_source : 84d1d0306934fffceda7b242615d89722d02c6f5
Hopefully most of these changes are self-explanatory however a few notes follow.
* In timing-model/animations/play-states.html, as well as making the tests match
the updated spec, one or two tests have also been moved to better reflect the
order in the spec (to make it obvious which branch of the algorithm is being
tested).
* In timing-model/animations/set-the-timeline-of-an-animation.html we previously
had two tests that check:
a) That the playState was 'pending' before and after setting the timeline.
b) That the playState was 'pending' before setting the timeline and then,
after setting the timeline and waiting on the ready promise, would become
'running'.
Likewise we had the same test for pausing.
Since these are basically the same test--(b) just adds the wait on the ready
promise--we combine them here into one test that covers both (a) and (b).
MozReview-Commit-ID: CLoDJvsdwmF
--HG--
extra : rebase_source : c2f34fa6614795f2d3ba9ca3e572f11306f96463
Currently we have a test in interfaces/Animation/playState.html that somewhat
randomly tests the result of the `playState` member.
However, there's no complex logic associated with the `playState` member in the
IDL. It simply returns "The play state of this animation". The logic we need to
test is in the definition of 'play state' which is in the timing model.
As a result we move this test to timing-model/animations/play-states.html
However, this test as it stands does not test the calculation of the play state
in a particularly thorough manner. For example, it does not contain a single
test for the 'finished' state.
Given that this patch series will change the definition of the 'play state' we
first fix this test to cover each of the different cases in the definition of
the 'play state' prior to these changes. That is, we update the tests based on
the definition of 'play state' here:
https://www.w3.org/TR/2016/WD-web-animations-1-20160913/#play-states
(Note that at this point in the patch series the pref to turn on the changed
definition behavior has not been enabled even for tests so this patch is
actually testing the behavior when that pref is false. We'll replace much of
this test in the next patch but by updating the test first, we should be able to
more clearly see the changes in the next patch.)
MozReview-Commit-ID: 1xkOmuY1SxD
--HG--
rename : testing/web-platform/tests/web-animations/interfaces/Animation/playState.html => testing/web-platform/tests/web-animations/timing-model/animations/play-states.html
extra : rebase_source : 1890e1b4db007452df393e8a9e4b3ccf42bca237
This reflects the change made to the Web Animations specification in:
9e2053f5531c3415f4cc
(I got it wrong the first time. The second commit fixes the first.)
And discussed in:
https://github.com/w3c/web-animations/issues/196
In summary, we are splitting the "pending" play state out into a separate
boolean member so that it is possible to distinguish between "play-pending" and
"pause-pending" and because most of the time when you check for
animation.playState === 'running' you also really want to include play-pending
animations.
MozReview-Commit-ID: IJSNoZTKW2I
--HG--
extra : rebase_source : 5d17239fd087cfe3cce1c9697eff97d062b6dd4b
This fixes missing menu styling caused by Bug 1416493
MozReview-Commit-ID: 4w9BGAOqQjR
--HG--
extra : rebase_source : b640f978008859d4de21dff8793d91427d05adcb
Simon Wörner
Ralph Giles
Ryan Leake
Gabriele Svelto
dluca
Anthony Ramine
Coroiu Cristina
arthur.iakab
Brian Birtles
Patrick Brosset
Russell
Chris H-C
peter chang
Edgar Chen
Tom Tung
Jeff Walden
Andrew Osmond
Tooru Fujisawa
sotaro
Geoff Brown
Gurzau Raul
Tiberius Oros
Jonathan Kew
ffxbld
Brian Grinstead