716ca00ed476419c0a5a56f0c3d345e0a33398a6: Bug 1375332 - stylo: force restyle descendants after character set is updated. r=emilio
Jeremy Chen <jeremychen@mozilla.com> - Mon, 21 Aug 2017 18:58:53 +0800 - rev 426009
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1375332 - stylo: force restyle descendants after character set is updated. r=emilio In Stylo, if there exists one or more <script> elements in the document, frame construction might happen earlier than the UpdateCharSet(), which leads to an incorrect style data for the frames. So, we force a restyle in this situation, to make the style data of all the descendants up-to-date. MozReview-Commit-ID: BwCwp6Ndvmc
665197f96a9bcbbac99fe24db19532876bef9dd1: Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont. r=emilio
Jeremy Chen <jeremychen@mozilla.com> - Wed, 23 Aug 2017 18:14:03 +0800 - rev 426008
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont. r=emilio In Stylo, we read font related user prefs to set the default font size only if we set 'font-size' property. However, users are allowed to set their preferred minimum font size through the user prefs, even without using 'font-size' property. Gecko used to do this in nsRuleNode::SetDefaultOnRoot, which calles the default constructor of nsStyleFont and does the minimum font size applying right after. Moving the minimum font size applying into the default constructor of nsStyleFont shoud be no harm to Gecko, but makes Stylo share the same code path and behave the same. MozReview-Commit-ID: BDcJX92o0uR
aae46de1a7cf9f01464a04cd610ddfbbb93d7fb4: Bug 1392716 - Clean up version map while de-duping records r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 23 Aug 2017 21:28:49 -0400 - rev 426007
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1392716 - Clean up version map while de-duping records r=rnewman This is meant as a stop-gap measure to stop the obviously bad thing from happening. MozReview-Commit-ID: Gqvc32K04xD
5885fd0c53a785fd97b58d8b09a09401ee31e6fc: Bug 1378560 - The order of items in the url bar should be (from right-to-left) bookmarks, page action menu. r=Gijs
Drew Willcoxon <adw@mozilla.com> - Wed, 23 Aug 2017 19:25:10 -0700 - rev 426006
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1378560 - The order of items in the url bar should be (from right-to-left) bookmarks, page action menu. r=Gijs MozReview-Commit-ID: 8StaNxrvryT
eca0163d09645959d6bd337a10af91eb5491561e: Bug 1389939 - Stop syncing devtools theme and compact themes;r=Gijs
Brian Grinstead <bgrinstead@mozilla.com> - Wed, 23 Aug 2017 10:18:51 -0700 - rev 426005
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1389939 - Stop syncing devtools theme and compact themes;r=Gijs MozReview-Commit-ID: GUjgHU5pgg1
bc5c4ae48a738e895142a35d14058c7bd18ea4ec: Merge m-c to autoland, a=merge
Wes Kocher <wkocher@mozilla.com> - Wed, 23 Aug 2017 18:08:30 -0700 - rev 426004
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Merge m-c to autoland, a=merge MozReview-Commit-ID: AHOFLdPkEou
f4509989f87c9d2db5e33db25a0dc8c260017774: Backed out changeset 535fefe4cc5e (bug 1378560) for being the apparent cause of test_page_scroll_with_fixed_pos.html and test_pointerlock-api.html failures a=backout
Wes Kocher <wkocher@mozilla.com> - Wed, 23 Aug 2017 18:04:40 -0700 - rev 426003
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Backed out changeset 535fefe4cc5e (bug 1378560) for being the apparent cause of test_page_scroll_with_fixed_pos.html and test_pointerlock-api.html failures a=backout MozReview-Commit-ID: 87yIHMGBXBo
0574a1e595924796bb263b0d473b05bff8202989: Bug 1389787 - Let the console unwrap proxy objects to avoid running traps. r=jimb
Oriol Brufau <oriol-bugzilla@hotmail.com> - Wed, 23 Aug 2017 15:50:00 -0400 - rev 426002
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1389787 - Let the console unwrap proxy objects to avoid running traps. r=jimb
df24976c2a46beb1a009dd4d9b57fd738b2941a2: Bug 1390359 - Replace faded out (i) icon with a search icon when the location bar is empty or modified. r=adw
Dão Gottwald <dao@mozilla.com> - Wed, 23 Aug 2017 09:41:48 +0200 - rev 426001
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1390359 - Replace faded out (i) icon with a search icon when the location bar is empty or modified. r=adw MozReview-Commit-ID: BQJ8ZiFAzco
9bc61eca0ace2fdd97dfaaec454631b22f1fd6ce: Bug 1390003 - increase containers "go back" link text size to match other text links. r=jaws
Jonathan Kingston <jkt@mozilla.com> - Tue, 22 Aug 2017 14:13:59 +0100 - rev 426000
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1390003 - increase containers "go back" link text size to match other text links. r=jaws MozReview-Commit-ID: 3nggJhiEbYJ
4cea9f6657ac45eb80128ed416cbc5a6a1fc2742: Bug 1391744 - Make tooltool manifests influence the index path for toolchain jobs. r=dustin
Mike Hommey <mh+mozilla@glandium.org> - Wed, 23 Aug 2017 14:53:56 +0900 - rev 425999
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391744 - Make tooltool manifests influence the index path for toolchain jobs. r=dustin
ad553bca3aac60b2d75d292e4a129892e4840bf3: Bug 1390097 - Revert a part of bug 1354020 changes. r=masayuki
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Wed, 23 Aug 2017 12:59:40 +0900 - rev 425998
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1390097 - Revert a part of bug 1354020 changes. r=masayuki Bug 1354020 causes that IMM-IME on Windows 7 doesn't work with --no-remote. Although I think that this issue is OS or IME bug, when default window proceduce by RegisterClass is DefaultWindowProcW, Google Japanese IME doesn't work. I am not sure why this issue occurs when lpfnWndProc is DefWidnowProcW and DDE isn't started. But for workaround, we should revert a part of bug 1354020 changes. MozReview-Commit-ID: BkxlZnm8mIh
6e979acd063f0e6dc9f979d145461608facc2e89: Bug 1338848 - Skip browser_newtab_bug725996.js for mac/win debug. r=jmaher
Ed Lee <edilee@mozilla.com> - Wed, 23 Aug 2017 13:48:46 -0700 - rev 425997
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1338848 - Skip browser_newtab_bug725996.js for mac/win debug. r=jmaher MozReview-Commit-ID: 6i2x1FAdBwk
8e3a645ad94bd948d13c619e4f829d6b9578e19d: Bug 1391476 - Add UID and GID to cache parameters; r=dustin
Gregory Szorc <gps@mozilla.com> - Tue, 22 Aug 2017 16:49:26 -0700 - rev 425996
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391476 - Add UID and GID to cache parameters; r=dustin The UID and GID that a task executes under is dynamic. As a result, caches need to be aware of the UID and GID that owns files otherwise subsequent tasks could run into permission denied errors. This is why `run-task --chown-recursive` exists. By recursively changing ownership of persisted files, we ensure the current task is able to read and write all existing files. When you take a step back, you realize that chowning of cached files is an expensive workaround. Yes, this results in cache hits. But the cost is you potentially have to perform hundreds of thousands of I/O system calls to mass chown. The ideal situation is that UID/GID is consistent across tasks on any given cache and potentially expensive permissions setting can be avoided. So, that's what this commit does. We add the task's UID and GID to run-task's requirements. When we first see a cache, we record a UID and GID with it and chown the empty cache directory to that UID and GID. Subsequent tasks using this cache *must* use the same UID and GID or else run-task will fail. Since run-task now guarantees that all cache consumers use the same UID and GID, we can avoid a potentially expensive recursive chown. But there is an exception. In untrusted environments (namely Try), we recursively chown existing caches if there is a uid/gid mismatch. We do this because Try is a sandbox and any random task could experiment with a non-standard uid/gid. That populated cache would "poison" the cache for the next caller. Or vice-versa. It would be annoying if caches were randomly poisoned due to Try pushes that didn't realize there was a UID/GID mismatch. We could outlaw "bad" UID and GIDs. But that makes the barrier to testing things on Try harder. So, we go with the flow and recursively chown caches in this scenario. This change will shine light on all tasks using inconsistent UID and GID values on the same cache. Bustage is anticipated. Unfortunately, we can't easily know what will break. So it will be one of those things where we will have to fix problems as they arise. Fortunately, because caches are now tied to the content of run-task, we only need to back out this change and tasks should revert to caches without UID and GID pinning requirements and everything will work again. MozReview-Commit-ID: 2ka4rOnnXIp
06d162a52dcd66947f1ecb51718920d277bd4ccd: Bug 1391476 - Automatically set cache/volume permissions in run-task; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 23 Aug 2017 12:07:18 -0700 - rev 425995
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391476 - Automatically set cache/volume permissions in run-task; r=dustin run-task's --chown and --chown-recursive are only used on volumes and caches - the only locations that aren't controlled by the Docker image itself and thus whose permissions could be "undefined." Previous commits have taught run-task about the locations of all caches and volumes. Therefore, we no longer need to manually define paths to chown. Instead, we can chown as a side-effect of the path being a cache or a volume. So, this commit changes run-task to chown caches and volumes automatically. Since we no longer have a use for --chown and --chown-recursive, those arguments are removed. There /could/ be some paths that are caches or volumes but aren't getting defined as such in Taskgraph. I consider this a bug in Taskgraph and the recourse is to properly define a path as a cache or a volume there. MozReview-Commit-ID: 1yqrhjil6gy
1768e5267bcfbeb3bd5e6eba2fa51fc79d14beda: Bug 1391476 - Tell run-task about volumes so it can sanitize them; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 23 Aug 2017 10:47:37 -0700 - rev 425994
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391476 - Tell run-task about volumes so it can sanitize them; r=dustin We recently introduced support for telling run-task about caches so it could sanitize them automatically. We also recently taught docker-worker and docker-engine how to declare volumes. Building on that work, we now pass a list of paths corresponding to Docker volumes to run-task. run-task now verifies volumes behave as expected. Unless the volume paths correspond to caches, run-task verifies they are empty and chowns them to an appropriate owner. Requiring empty volumes is an arbitrary decision. But as the inline comment says, it keeps things simpler and makes caches and volumes behave more like each other. MozReview-Commit-ID: 5lm2uIitrS3
047cc1e53f509cbf54b1243f626c16ace22cd8c9: Bug 1391476 - Don't install nexus.xml in a Docker volume; r=mshal
Gregory Szorc <gps@mozilla.com> - Wed, 23 Aug 2017 10:34:14 -0700 - rev 425993
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391476 - Don't install nexus.xml in a Docker volume; r=mshal We're about to ban files in Docker volumes so they behave almost identically to caches (which start empty). We move the install of nexus.xml from Docker image time to task time. This also means that changes to nexus.xml don't result in having to rebuild the Docker image. MozReview-Commit-ID: JIjeJN4mt2
84fd52d2832ad1713a8698e649c22f79cad6cd40: Bug 1391476 - Require that all cache paths be declared as volumes; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 23 Aug 2017 08:57:59 -0700 - rev 425992
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391476 - Require that all cache paths be declared as volumes; r=dustin See the inline comment for the rationale here. This check may not catch all volumes and caches. But after subsequent commits refactor how permissions for caches and volumes are handled, this edge case will likely result in permissions errors in the task, so it isn't worth worrying about. Several Dockerfile have been updated to add missing VOLUME so the check passes. In the case of desktop1604-test, we stopped removing /home/worker/.cache because you can't remove a mount point, which is what volumes are inside Docker containers. MozReview-Commit-ID: GEyNkkX00kN
52a96399c1dca940a6e08e08a2706b810fa749ec: Bug 1391476 - Capture Docker volumes in docker-worker config; r=dustin
Gregory Szorc <gps@mozilla.com> - Wed, 23 Aug 2017 08:53:56 -0700 - rev 425991
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391476 - Capture Docker volumes in docker-worker config; r=dustin Docker volumes are host-mounted filesystems. We typically mount caches at their location. But not always. The reason we define VOLUME in Dockerfiles is we're guaranteed to get a fast host filesystem instead of AUFS when a cache isn't mounted. In this commit, we teach the docker-worker payload builder about the existence of Docker volumes. Docker volumes can be declared inline in the YAML. More conveniently, we automatically parse out VOLUME lines from corresponding in-tree Dockerfile. We'll do useful things with this data in subsequent commits. MozReview-Commit-ID: BNxp8EDEYw
985a6df057cb4dab6e3c51f3bd39f3c7835ccdd9: Bug 1391476 - Track whether caches should be used in untrusted environments; r=dustin
Gregory Szorc <gps@mozilla.com> - Tue, 22 Aug 2017 15:06:40 -0700 - rev 425990
Push 7761 by jlund@mozilla.com at Fri, 15 Sep 2017 00:19:52 +0000
Bug 1391476 - Track whether caches should be used in untrusted environments; r=dustin Previously, we conditionally added caches to a task if the current parameters warranted it. In order to audit that all caches fulfill basic requirements, we need to have unconditional knowledge of all caches. This commit introduces an optional key on each cache entry stating whether it should be skipped in "untrusted" environments. When we convert a task definition to a worker payload, we filter out these caches if necessary. This change uncovered an inconsistency with filtering caches. In one location we filtered on the source repo name. In others, we filtered on the SCM level. Setting the caches in the spidermonkey kind also changed slightly to ensure we're not overwriting existing caches. I don't think this has any behavior changes. But the new method is more correct. MozReview-Commit-ID: 1crpdWHqQ68
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip