fd91e4d8ca980a018b2319795e12685aadfe2614: Part 3c: Extract GeckoInterface.openWindowForNotification. r=sebastian draft
Nick Alexander <nalexander@mozilla.com> - Thu, 17 Nov 2016 14:15:55 -0800 - rev 445767
Push 37604 by nalexander@mozilla.com at Wed, 30 Nov 2016 07:13:23 +0000
Part 3c: Extract GeckoInterface.openWindowForNotification. r=sebastian GeckoView (and GeckoView consumers) shouldn't be referencing AppConstants.{ANDROID_PACKAGE_NAME,MOZ_ANDROID_BROWSER_INTENT_CLASS}. For GeckoView consumers, I don't have a clear picture of what Web Notification support looks like, let alone Web Push support. For now, ignore these API decisions. MozReview-Commit-ID: GLqvGyAQzr0
f1d54da2d52495aa3c1573b3d94a029d243a4ba9: Bug 1291366 - Part 3b: Make EventDispatcher stricter in RELEASE_OR_BETA. r=jchen draft
Nick Alexander <nalexander@mozilla.com> - Wed, 16 Nov 2016 21:18:20 -0800 - rev 445766
Push 37604 by nalexander@mozilla.com at Wed, 30 Nov 2016 07:13:23 +0000
Bug 1291366 - Part 3b: Make EventDispatcher stricter in RELEASE_OR_BETA. r=jchen The EventDispatcher contract should be constant across our release channels. If Fennec (or GeckoView!) is incorrectly registering and unregistering event listeners, that's a bug; a quick crash is better than an ignored warning. In the unlikely event that add-ons are incorrectly registering (or perhaps indirectly causing incorrect registrations), it's even more critical that they crash in release channels, because there are essentially zero add-on users *not* on release channels. I am sympathetic to protecting release builds, but we should be precise and consistent. MozReview-Commit-ID: BQs5lT3IlCt
d8bc75fc2ac337aafafc039a9a8fdf3b7b8ddc15: Bug 1291366 - Part 3a: Add o.m.geckoview.BuildConfig. r=sebastian draft
Nick Alexander <nalexander@mozilla.com> - Fri, 18 Nov 2016 17:35:43 -0800 - rev 445765
Push 37604 by nalexander@mozilla.com at Wed, 30 Nov 2016 07:13:23 +0000
Bug 1291366 - Part 3a: Add o.m.geckoview.BuildConfig. r=sebastian This is the first, mostly mechanical, introduction of a GeckoView specific BuildConfig. We have a few "debug logging" like checks. I introduced a MOZILLA_OFFICIAL abstraction and removed some of the checks as I saw fit. Subsequent patches will remove more of these checks. With this change applied, Gradle is broken, because there will be duplicate BuildConfig files included in the build. That will be fixed in subsequent patches. MozReview-Commit-ID: KHhV32o5j5A
e3005aaad7f7b7c8cb191025f90bf37e4e0d8681: Bug 1291366 - Pre: don't force generated/ in Java generated_sources. r=gps draft
Nick Alexander <nalexander@mozilla.com> - Mon, 14 Nov 2016 22:17:27 -0800 - rev 445764
Push 37604 by nalexander@mozilla.com at Wed, 30 Nov 2016 07:13:23 +0000
Bug 1291366 - Pre: don't force generated/ in Java generated_sources. r=gps This was a mistake from the beginning. I'm removing it now so that I can easily generate across objdirs. While we transition from moz.build to Gradle, I want all the build logic to be in mobile/android/base but the outputs to be split across Gradle project locations. That's hard to do when generated/ is automatically prepended to generated_sources paths. MozReview-Commit-ID: L07ZZBTsNw5
af4615ae9611e139b244f300f6098d05e53405c7: Bug 1291366 - Pre: Don't check against {MIN,MAX}_SDK_VERSION. r=sebastian draft
Nick Alexander <nalexander@mozilla.com> - Mon, 14 Nov 2016 20:46:31 -0800 - rev 445763
Push 37604 by nalexander@mozilla.com at Wed, 30 Nov 2016 07:13:23 +0000
Bug 1291366 - Pre: Don't check against {MIN,MAX}_SDK_VERSION. r=sebastian This had some value for Fennec when we shipped split APKs. Since we don't, there's little value left; and there's definitely no value for GeckoView, which will only ever ship a single library AAR for all consumers. (That library AAR will have a minimum SDK, but it'll be enforced by the Gradle build system, not by runtime checks.) MozReview-Commit-ID: 3l0jUKdCepS
6296e08b7737002f9547cccfcfe8f35b6e7f7e8a: Bug 1291366 - Pre: Inline AppConstants.Versions in GeckoView. r=sebastian draft
Nick Alexander <nalexander@mozilla.com> - Mon, 14 Nov 2016 20:44:22 -0800 - rev 445762
Push 37604 by nalexander@mozilla.com at Wed, 30 Nov 2016 07:13:23 +0000
Bug 1291366 - Pre: Inline AppConstants.Versions in GeckoView. r=sebastian This patch inlines most uses of Versions in GeckoView. The Android linter can check that symbols only defined in particular versions of Android are only accessed behind safe guards. However, our Versions symbolic constants defeat the Android linter's simplistic code analysis. The value of the linter is (much!) greater than the explanatory value of our symbolic constants, especially for GeckoView, which will only ever ship a single library AAR suitable for all consumers. I manually tried to squash a few linter errors; subsequent tickets will track enabling the linter for GeckoView specifically, and burning down the remaining linter version errors. MozReview-Commit-ID: cZmNehx8tR
fddadcf8da9c1706685aa822dfa8f856d8182674: Bug 1291366 - Part 1: Use GENERATED_FILES to produce AppConstants.java. r=gps draft
Nick Alexander <nalexander@mozilla.com> - Mon, 14 Nov 2016 20:06:31 -0800 - rev 445761
Push 37604 by nalexander@mozilla.com at Wed, 30 Nov 2016 07:13:23 +0000
Bug 1291366 - Part 1: Use GENERATED_FILES to produce AppConstants.java. r=gps This patch lays the groundwork for two things. First, it paves the way for splitting AppConstants.java into two parts, a GeckoView part and a Fennec part. This is necessary because the Makefile.in preprocessing is not flexible enough to write two separate GeckoView and Fennec constants files into different directories. Second, this allows us to more flexibly generate the file contents. Gradle has a way to get compile-time constants into Java code, which we want to migrate to. The details don't matter right here, but this paves the way to move from preprocessing to generating the Gradle-style BuildConfig files while we continue to support both build systems. MozReview-Commit-ID: 2o8X99uLoaM
1637779d55f4d8deddb7b1a516db9e1fd3242de6: Bug 1313758 - set media.getusermedia.browser.enabled to default false; r=jib draft
Munro Mengjue Chiang <mchiang@mozilla.com> - Wed, 30 Nov 2016 15:03:48 +0800 - rev 445760
Push 37603 by mchiang@mozilla.com at Wed, 30 Nov 2016 07:04:18 +0000
Bug 1313758 - set media.getusermedia.browser.enabled to default false; r=jib MozReview-Commit-ID: 54YTn2p4nnX
2593d1be726947e1d7c4a519a4045c29f776f71a: Bug 1321094 - Change angle::Format from constexpr to const to pass build with VS2015u2, r?jgilbert draft
peter chang <pchang@mozilla.com> - Wed, 30 Nov 2016 14:45:17 +0800 - rev 445759
Push 37602 by bmo:howareyou322@gmail.com at Wed, 30 Nov 2016 06:48:04 +0000
Bug 1321094 - Change angle::Format from constexpr to const to pass build with VS2015u2, r?jgilbert MozReview-Commit-ID: 10nWkgMYf5R
97461b27705294523d6cb346c194c657b05c2a80: Bug 1319301 - Part 2. add a regression test for controlsSpacer. r=jaws draft
Ray Lin <ralin@mozilla.com> - Wed, 23 Nov 2016 18:10:51 +0800 - rev 445758
Push 37601 by bmo:ralin@mozilla.com at Wed, 30 Nov 2016 06:38:06 +0000
Bug 1319301 - Part 2. add a regression test for controlsSpacer. r=jaws MozReview-Commit-ID: 2yhiaZgReRQ
bae61cc03ce52fc16705dc35dcfd7339ac58d731: Bug 1319301 - Part 1. fadeout grey spacer when play event is not triggered by controls. r=jaws draft
Ray Lin <ralin@mozilla.com> - Tue, 22 Nov 2016 11:48:04 +0800 - rev 445757
Push 37601 by bmo:ralin@mozilla.com at Wed, 30 Nov 2016 06:38:06 +0000
Bug 1319301 - Part 1. fadeout grey spacer when play event is not triggered by controls. r=jaws MozReview-Commit-ID: AouOiY9EGo8
1bd3f784338d23edb0ce8560b5a8874084e99b72: Bug 1285608 - Part 3: Make Android "build-like" jobs "other" or "test" in TH. r=dustin draft
Nick Alexander <nalexander@mozilla.com> - Tue, 29 Nov 2016 19:51:37 -0800 - rev 445756
Push 37600 by nalexander@mozilla.com at Wed, 30 Nov 2016 06:34:39 +0000
Bug 1285608 - Part 3: Make Android "build-like" jobs "other" or "test" in TH. r=dustin MozReview-Commit-ID: 7k7T6OZsHfn
626639dc8674d477259e2e03aa90e50990ebe64b: Bug 1285608 - Part 2: Make --artifact handle Android builds. r=maja_zf,chmanchester draft
Nick Alexander <nalexander@mozilla.com> - Tue, 29 Nov 2016 19:52:01 -0800 - rev 445755
Push 37600 by nalexander@mozilla.com at Wed, 30 Nov 2016 06:34:39 +0000
Bug 1285608 - Part 2: Make --artifact handle Android builds. r=maja_zf,chmanchester I'm not a fan of introducing a new configuration flags (and not knowing where or how to document it!), but there's a clear need for configuration in the absence of a documented way to add a coherent "artifact build dimension" akin to "opt/debug". I like adding a subtle tri-state flag even less, but I tried this with two flags (ignore and build-variant) and it was worse, so I'm rolling with a tri-state flag. MozReview-Commit-ID: KTNvacTBUXB
df6670faf970017c5a54e49392fce0c4f1f166a9: Bug 1285608 - Part 1: Add Android moz.build and Gradle artifact build configs. r=maja_zf draft
Nick Alexander <nalexander@mozilla.com> - Tue, 29 Nov 2016 20:10:31 -0800 - rev 445754
Push 37600 by nalexander@mozilla.com at Wed, 30 Nov 2016 06:34:39 +0000
Bug 1285608 - Part 1: Add Android moz.build and Gradle artifact build configs. r=maja_zf MozReview-Commit-ID: AXh5ueeUs38
2c28e52a991f039f32dbaa1d63c507e285022381: Bug 1291821 - Post: remove unused files r=rnewman draft
Grisha Kruglov <gkruglov@mozilla.com> - Tue, 29 Nov 2016 13:36:26 -0800 - rev 445753
Push 37599 by gkruglov@mozilla.com at Wed, 30 Nov 2016 06:33:43 +0000
Bug 1291821 - Post: remove unused files r=rnewman MozReview-Commit-ID: 4qM5vx4AQyQ
7fb9f3be33549ee0f78ed0661e280702a2afb792: Bug 1291821 - Allow BatchingDownloader to resume downloads using offset or high water mark r=rnewman draft
Grisha Kruglov <gkruglov@mozilla.com> - Tue, 29 Nov 2016 21:53:03 -0800 - rev 445752
Push 37599 by gkruglov@mozilla.com at Wed, 30 Nov 2016 06:33:43 +0000
Bug 1291821 - Allow BatchingDownloader to resume downloads using offset or high water mark r=rnewman BatchingDownloader uses provided RepositoryStateProvider instance in order to track offset and high water mark as it performs batching. These objects are initialized by individual ServerSyncStages, and prefixes are used to ensure keys won't clash. Two RepositoryStateProvider implementations are used: persistent and non-persistent. Non-persistent state provider does not allow for resuming after a sync restart, while persistent one does. Persistent state provider is used by history stage. It is fetched oldest-first, and records are applied to live storage as they're downloaded. These conditions let use resume downloads. It's also possible to resume downloads for stages which use a persistent buffer, but currently we don't have any. Offset value is reset if we hit a 412 error; it is maintained if we hit a sync deadline, allowing us to minimize number of records we'll redownload. High water mark is maintained across syncs and used instead of stage's "last-synced" timestamp. MozReview-Commit-ID: IH28YrDU4vW
c49abe8e93423cd3c52de26a6cb8ab3419e0aed0: Bug 1291821 - Track incomplete stages and re-sync them r=rnewman draft
Grisha Kruglov <gkruglov@mozilla.com> - Tue, 29 Nov 2016 20:38:17 -0800 - rev 445751
Push 37599 by gkruglov@mozilla.com at Wed, 30 Nov 2016 06:33:43 +0000
Bug 1291821 - Track incomplete stages and re-sync them r=rnewman Stage re-sync is requested if: - We hit a 412 either during batching download or batching upload - We hit a sync deadline either during batching download or when merging records from the buffer SessionStoreDelegate interface was expanded with onStoreFailed, indicating that not just a particular record failed, but the whole operation did. onFetchFailed is used to inform delegates of 412/deadline failures during downloads. Three new exception types were added, to facilitated messaging between different layers. MozReview-Commit-ID: Ltdi5noEvdV
b5365e77e4af402bd45f646e2df34387d1fff2d2: Bug 1291821 - Move bulk insert logic for new history to BrowserProvider r=rnewman draft
Grisha Kruglov <gkruglov@mozilla.com> - Tue, 29 Nov 2016 13:42:53 -0800 - rev 445750
Push 37599 by gkruglov@mozilla.com at Wed, 30 Nov 2016 06:33:43 +0000
Bug 1291821 - Move bulk insert logic for new history to BrowserProvider r=rnewman This commit does two things: 1) It simplifies history insertion logic, which wrongly assumed that history which was being inserted might be not new. As such, it was necessary to check for collisions of visit inserts, record number of visits actually inserted, and update remote visit counts correspondingly in a separate step, making history insert a three step operation (insert history record, insert its visits, update history record with a count). However, bulkInsert runs only for records which were determined to be entirely new, so it's possible to drop the third step. 2) Makes all of the insertions (history records and their visits) run in one transaction. Prepared statements for both history and visit inserts are used are used as a performance optimization measure. MozReview-Commit-ID: 48T4G5IsQNS
1f6424ba1c1a7190a67231c8da4428830fd3840e: Bug 1291821 - Rename repositories/sessions r=rnewman draft
Grisha Kruglov <gkruglov@mozilla.com> - Tue, 01 Nov 2016 18:56:38 -0700 - rev 445749
Push 37599 by gkruglov@mozilla.com at Wed, 30 Nov 2016 06:33:43 +0000
Bug 1291821 - Rename repositories/sessions r=rnewman We're at Sync 1.5 now, so might as well rename the files. Also, renamed the ConstrainedRepository... to a name that's more reflective of that session's role after the changes. MozReview-Commit-ID: 96XCzoBzD5D
b9d2c8a69fe194ee856621bc8db203d53d55eb72: Bug 1291821 - Get tests to work after sync changes r=rnewman draft
Grisha Kruglov <gkruglov@mozilla.com> - Tue, 11 Oct 2016 20:02:02 -0700 - rev 445748
Push 37599 by gkruglov@mozilla.com at Wed, 30 Nov 2016 06:33:43 +0000
Bug 1291821 - Get tests to work after sync changes r=rnewman MozReview-Commit-ID: 3djnmEmzndU
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip