Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW

Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh

Bug 1397530 - report all exceptions checking the account status. r?eoger MozReview-Commit-ID: ClCaDhgdQ0a

Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW

Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh

Bug 1341504 - Don't disable incremental linking when optimizations are turned off. r?ted Incremental linking is automatically disabled when -OPT:REF or -OPT:ICF are used. Seeing that we're disabling optimizations anyway, may as well not use those linker flags as they considerably slow down linking. MozReview-Commit-ID: 9OXG19uxeI9

Merge autoland to central, a=merge MozReview-Commit-ID: GQpNetIXsWP

Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW

Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh

Bug 1393497 - remove Valence from WebIDE; r=ochameau MozReview-Commit-ID: 9mEhpfIFo7n

Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW

Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh

Bug 1377587 - Always act like __exposedProps__ is missing. This patch gently removes support for __exposedProps__ by changing ExposedPropertiesOnly::check() to always return false, while still failing silently in deny for some kinds of access. The tests that I changed all involve testing the behavior with __exposedProps__. I adjusted them to expect it to fail, or to adjust the error message they get when they fail. That seemed better than deleting them entirely. Note that test_bug1065185.html had a bug, so that it never executed the first case. I fixed that, and then fixed up the test to work when __exposedProps__ is not supported. This also removes various bits of the test framework that use __exposedProps__, but don't actually need to. MozReview-Commit-ID: 8fvkAmITmXY

Bug 1397460 - Don't throw for a failure in cpows_child.js. r=billm When ok() is passed false, we send a message to the parent, which will cause the test to fail. Throwing in this helper in the child just makes the test hang for a while. MozReview-Commit-ID: 4gwBACPYfDO

Bug 1395322 Part 3: Change timeouts to failures in layout/style/test/chrome/test_stylesheet_clone_import_rule.html. MozReview-Commit-ID: 8ea7J5ExmzH

Bug 1395322 Part 2: Make ServoCSSRuleList::InsertRule map DOMCSSRule types to Rule types. MozReview-Commit-ID: 9lvQLsQItEy

Bug 1395322 Part 1: Add a mapping function from nsIDOMCSSRule type enum to Rule type enum. MozReview-Commit-ID: 7ocyE3RQnOG

Bug 1392143 - P3. Retry the readback after relocating the window to (0,0). r?mattwoodrow This is a workaround until bug 1397253 is resolved. MozReview-Commit-ID: I3jLkbPRNE4

Bug 1392143 - P2. Disable hardware decoding for small videos. r?mattwoodrow As the H264 SanityTest uses a 132x132 videos to determine if the hardware decoder is working, we always use the software decoder for smaller videos. MozReview-Commit-ID: 8VbZTiJO9mA

Bug 1392143 - P1. Change video size used for testing if h264 decoder is working. r?mattwoodrow AMD incorrectly decode videos with a resolution that is less than 128x128, as such with the test failing we disable hardware decoding on those machines, even though other resolutions work well. So we use a 132x132 video instead. MozReview-Commit-ID: 80mk11CNsil