85f41e26f8b6e85b0d5ded8c182c5a6667968985: Bug 1369837: Add a void cast to silence clang Wcomma build warning, in sandbox's snapshot of chromium header. r=bobowen
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 02 Jun 2017 12:45:01 -0700 - rev 362120
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1369837: Add a void cast to silence clang Wcomma build warning, in sandbox's snapshot of chromium header. r=bobowen The build warning is for "possible misuse of comma operator". The comma operator is a bit of a footgun becasue its first operand's result just gets dropped on the floor (in this case, the result of the DCHECK expression). It appears that Chromium's use of the comma operator here is intentional, though -- so we might as well accept clang's suggestion and "cast expression to void to silence warning". This is also filed upstream as: https://bugs.chromium.org/p/chromium/issues/detail?id=729123 MozReview-Commit-ID: Al2xsYEo3p0
d9b7971a270cde0cff0adbe068707fd6f92f5028: Bug 1321847 - Add new linux jobs using the baseline of supported toolchains. r=mshal
Mike Hommey <mh+mozilla@glandium.org> - Fri, 02 Jun 2017 11:34:46 +0900 - rev 362119
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1321847 - Add new linux jobs using the baseline of supported toolchains. r=mshal For a long time, we've kind of forced the GCC version used to compile Firefox on automation to the minimum version we do support, because using a newer version would pretty much guarantee that builds with older versions would break. Ideally, the same would be true of rust, but it's not the case, and sure enough, building with older versions breaks. The most recent example is bug 1367734 making rustc 1.17.0 required but leaving configure checking for version 1.15.1. There are multiple reasons why we'd want to use newer versions of rust to build shipping versions of Firefox other than language requirements, but we should still ensure building with supported versions of rust doesn't break silently. Here we add a set of new linux jobs that build opt and debug build with the baseline of supported toolchains. At the moment, that's GCC 4.9, rust 1.15.1, and clang 3.9 (for bindgen). That's a copy of the current toolchains used for normal linux jobs, with rustc downgraded to the package used after bug 1338311. Further down the line, we'll be able to bump the versions of GCC, rust and/or clang for the shipped Firefox builds, while keeping those jobs on GCC 4.9, rust 1.15.1 and clang 3.9, until we do intentionally want to bump those versions (as well as the corresponding configure checks).
4db381159f27a7d1a1b5d112be7441290dc12550: Bug 1321847 - Allow to override the mozharness tooltool manifest from the environment. r=mshal
Mike Hommey <mh+mozilla@glandium.org> - Fri, 02 Jun 2017 11:28:26 +0900 - rev 362118
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1321847 - Allow to override the mozharness tooltool manifest from the environment. r=mshal The main motivation behind this change is that going towards toolchain tasks hooked up in the task graph (bug 1313111), we're going to end up with jobs using both taskcluster toolchain job and tooltool artifacts for their toolchain needs. With the current setup, this means the toolchain dependencies will be spread between taskcluster task graph definition and mozharness configuration. It also makes things more complex to provide a command that pulls the right toolchains from both taskcluster and tooltool (bug 1356529), because one needs to find and parse the mozharness config (which also happens to be python code that uses platform-specific things, so e.g. reading windows mozharness config fails on other platforms). All in all, moving the tooltool manifest path to the taskcluster task definitions would make things simpler, and would also allow make patches switching from tooltool to taskcluster artifacts more straightforward to validate. But since some build types still run on buildbot, we'll have to keep part of the current setup using mozharness configs. So we allow to override the tooltool manifest path from the environment, and we'll rely on taskcluster task definitions being able to set environment variables. Actually moving the relevant tooltool manifest paths from mozharness config to taskcluster task definitions is left for a followup. Another followup is to move the tooltool manifest paths declared in some ad-hoc build scripts to taskcluster task definitions as well. The immediate need for this, though, is to allow to have duplicated jobs that only differ in their tooltool manifest, without duplicating a complete mozharness config that will end up stale (the goal being that really only the tooltool manifest differs, even when the original jobs change).
2c0e0f3062aeb2e1bca2b743ab0d82ca19619c9e: Bug 1365554 - Fix storage inspector failures in browser_devtools_api.js r=jdescottes
Michael Ratcliffe <mratcliffe@mozilla.com> - Fri, 02 Jun 2017 14:15:41 +0100 - rev 362117
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1365554 - Fix storage inspector failures in browser_devtools_api.js r=jdescottes The changes to devtools/client/framework/test/browser_devtools_api.js are purely eslint fixes so you only need to glance over them. The changes to ui.js checks if the toolbox is being destroyed... if it is we don't log an error, otherwise we do. MozReview-Commit-ID: JJTqkYXVsYG
3c59f4cceb9a7f4acca9331409c91d148405382c: Bug 1338860 fix onErrorOccurred to handle some additional errors, r=aswan,kmag
Shane Caraveo <scaraveo@mozilla.com> - Fri, 02 Jun 2017 14:16:48 -0700 - rev 362116
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1338860 fix onErrorOccurred to handle some additional errors, r=aswan,kmag MozReview-Commit-ID: I5uZmhWFBUd
5092c00facfaacf3f761a5c9384b1b639d5de41d: Bug 1367923 - Enable link attr tests for Stylo. r=Manishearth
J. Ryan Stinnett <jryans@gmail.com> - Thu, 01 Jun 2017 17:42:19 -0500 - rev 362115
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1367923 - Enable link attr tests for Stylo. r=Manishearth MozReview-Commit-ID: 9wkSpx7h0km
7b8fcdae113f0fa1c1c0ccc6dcdc0d2602501c7e: Bug 1367923 - Store Servo decls when link preshints change. r=Manishearth
J. Ryan Stinnett <jryans@gmail.com> - Thu, 01 Jun 2017 13:37:02 -0500 - rev 362114
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1367923 - Store Servo decls when link preshints change. r=Manishearth When any of the link preshints (link, vlink, alink) on <body> are set, we store a Servo declaration block to hold the color from the hint. This uses a one-off approach instead of `nsMappedAttributes` that is used for other preshints because it depends on element state and also it affects links through the document (as opposed to the element where the attribute is set). MozReview-Commit-ID: KUvyCq9KfHT
ac5fcb551e41400cdaad4a9659e33c1852edcd31: servo: Merge #17144 - Stylo: Support link preshints on <body> (from jryans:link-pres-hints); r=Manishearth
J. Ryan Stinnett <jryans@gmail.com> - Fri, 02 Jun 2017 13:08:04 -0700 - rev 362113
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
servo: Merge #17144 - Stylo: Support link preshints on <body> (from jryans:link-pres-hints); r=Manishearth https://bugzilla.mozilla.org/show_bug.cgi?id=1367923 Source-Repo: https://github.com/servo/servo Source-Revision: 54448305de3048f23004de0d9ee84efd25af8a79
3226b56675ffdb2af7790e13a5a4b927ceb0b063: Bug 1369871: Add "const" keyword to a long* param in a pkix test function. r=keeler
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 02 Jun 2017 13:45:41 -0700 - rev 362112
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1369871: Add "const" keyword to a long* param in a pkix test function. r=keeler The only reason this param is a pointer is so that it can be optional. It's not an outparam -- the function does not (and does not intend to) modify it -- so it should be declared as 'const' to make that clearer & to allow clients to pass in pointers to const values. MozReview-Commit-ID: HbF96YNfnSt
63cc19a2300f356abf1fa03884a9ac3d4792ef57: Bug 1362462: Fallback to main document widget for frames which haven't been inserted yet. r=mconley
Kris Maglione <maglione.k@gmail.com> - Mon, 29 May 2017 13:16:23 -0700 - rev 362111
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1362462: Fallback to main document widget for frames which haven't been inserted yet. r=mconley MozReview-Commit-ID: Ayr2kQ9KqbW
72a455b224e63335c4cf6cce7588d2b9c9de7a5f: Bug 1308337 - Post: Remove old background telemetry code r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 11 Apr 2017 22:31:18 -0400 - rev 362110
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Post: Remove old background telemetry code r=nalexander MozReview-Commit-ID: CONHqQWzB6c
bae470a1d3973491f713fdd5d466001abe1c7b79: Bug 1308337 - Part 8: Receive sync telemetry, construct and upload sync pings r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Thu, 01 Jun 2017 17:16:09 -0400 - rev 362109
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 8: Receive sync telemetry, construct and upload sync pings r=nalexander This patch includes some "pre" work, which should have been a separate patch (my apologies!): - telemetry ping is (needlessly) coupled with information about where it should be uploaded. It wasn't a problem before, since core pings are "upload right away", and are never bundled together during an upload. However, for sync ping, we need to bundle a bunch of "syncs" and "events" (down the road) into one single "sync ping", and as such we need a separate representation for a "ping that is not meant to be uploaded directly". - instead of dealing with the coupling directly, a simpler approach is taken: - a "ping" is split into two types of pings: local and outgoing - outgoing ping is what the old "ping" was - a data bundle that is ready to be uploaded - local ping is not meant to be uploaded directly, but is intended to be a part of an outgoing ping, along with other local pings - the main difference between local and outgoing pings is the URL: local pings don't have it while outgoing pings do have it. As background telemetry is received via LocalBroadcastManager, it is processed as follows: - telemetry data is processed into "local pings" which are stored on disk - as enough telemetry is gathered, or we hit one of "let's upload now" conditions, the persisted local pings are gathered into an "outgoing ping" via a SyncPingBundleBuilder, which is persisted on disk. - upload of the bundled "sync ping" is attempted - as individual "local pings" are processed into outgoing "Sync ping" bundles, they are removed from disk Hooks for the upcoming event telemetry data are in place to make that follow-up work easier. MozReview-Commit-ID: 6uXi6pjXiSv
4acec427f8b4bc4730692ba08cfefffdea32d047: Bug 1308337 - Part 7: Instrument Crypto Keys stage r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 29 May 2017 17:20:20 -0400 - rev 362108
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 7: Instrument Crypto Keys stage r=nalexander MozReview-Commit-ID: 8a9zKsdhkbv
6e63f290b631cc9883059f3896fa88386c95b246: Bug 1308337 - Part 6: Instrument FetchInfoConfiguration stage r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 31 May 2017 17:38:47 -0400 - rev 362107
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 6: Instrument FetchInfoConfiguration stage r=nalexander MozReview-Commit-ID: HvDWBVBxb5I
04eedff08896bd610fac62f18b4a27b5a09dd96a: Bug 1308337 - Part 5: Instrument FetchInfoCollectionsStage r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 31 May 2017 17:38:30 -0400 - rev 362106
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 5: Instrument FetchInfoCollectionsStage r=nalexander MozReview-Commit-ID: 64jTO81tDpK
99d1101ae492edd972dcad4a4831be71c780b3c0: Bug 1308337 - Part 4: Instrument FetchMetaGlobal stage r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 29 May 2017 21:48:05 -0400 - rev 362105
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 4: Instrument FetchMetaGlobal stage r=nalexander MozReview-Commit-ID: 6zXqgsAIajN
2597d0701648726433d3c46a1236684fe220c706: Bug 1308337 - Part 3: Handle sync restarts during telemetry collection r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 30 May 2017 19:46:31 -0400 - rev 362104
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 3: Handle sync restarts during telemetry collection r=nalexander The approach here is to simply mark current TelemetryCollector as having restarted. The downside of this approach is that two technically separate syncs are combined into one telemetry ping. However, the two syncs are logically connected to each other, and combining their telemetry will make it easier to figure out why a restart occurred, as well as what happened after the restart. MozReview-Commit-ID: AtJbge2ulMz
846114208d7b988d2ce5864f59056cb84c0d5821: Bug 1308337 - Part 2: Instrument Clients engine r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 31 May 2017 17:38:59 -0400 - rev 362103
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 2: Instrument Clients engine r=nalexander While this is a "named" stage, it doesn't follow the Repository<->Repository semantics of other named stages, and so it needs to be instrumented separately. MozReview-Commit-ID: IKrc5Fb1bYm
02d589c299a4aa9b6b0d247693c5ae1e82dd42d2: Bug 1308337 - Part 1: Instrument named sync stages and broadcast collected telemetry r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 31 May 2017 17:38:14 -0400 - rev 362102
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Part 1: Instrument named sync stages and broadcast collected telemetry r=nalexander SyncAdapter owns a TelemetryCollector, which is passed into GlobalSession to be "filled up" with telemtry data. GlobalSession obtains instances of TelemetryStageCollector from the TelemetryCollector, and passes them into individual stages. They are filled up with telemetry as stages are executed. Stage errors are recorded in TelemetryStageCollector. Various global errors are recorded in TelemetryCollector itself. On completion (success, failure, abort), telemetry is "built" and broadcasted via LocalBroadcastManager. TelemetryContract is used to establish a key convention between the "broadcaster" and whoever is on the receiving end of this telemetry. This patch instruments stages which follow the Repository<->Repository flow semantics. Other stages, such as the clients stage, meta/globa, info/* and crypto/keys are instrumented separately in follow-up patches. MozReview-Commit-ID: 5VLRc96GLdV
38894ad99464973a4be0963641569dfa4d96ecdd: Bug 1308337 - Pre: Read hashedFxaUid from the token server r=nalexander
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 26 May 2017 17:44:42 -0400 - rev 362101
Push 31960 by archaeopteryx@coole-files.de at Sat, 03 Jun 2017 18:13:06 +0000
Bug 1308337 - Pre: Read hashedFxaUid from the token server r=nalexander This is what we (and other platforms) use as part of telemetry payloads in place of either our local FxA Device ID or the sync client ID. Note that this server API is currently undocumented. Parameter introduced in https://github.com/mozilla-services/tokenserver/commit/2021994ca4682acde83242ee0b96140a05c7c4f5 MozReview-Commit-ID: 64sY5RZ2ZxK
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip