65251b0ed973675e2d490458fedfc5cb75753abb: Bug 1352889 - Ensure that PLDHashTable's second hash doesn't have padding with 0 bits for tables with capacity larger than 2^16. r=njn
L. David Baron <dbaron@dbaron.org> - Wed, 31 May 2017 13:44:02 -0700 - rev 587411
Push 61697 by bmo:tigleym@gmail.com at Thu, 01 Jun 2017 00:38:44 +0000
Bug 1352889 - Ensure that PLDHashTable's second hash doesn't have padding with 0 bits for tables with capacity larger than 2^16. r=njn PLDHashTable takes the result of the hash function and multiplies it by kGoldenRatio to ensure that it has a good distribution of bits across the 32-bit hash value, and then zeroes out the low bit so that it can be used for the collision flag. This result is called hash0. From hash0 it computes two different numbers used to find entries in the table storage: hash1 is used to find an initial position in the table to begin searching for an entry; hash2 is then used to repeatedly offset that position (mod the size of the table) to build a chain of positions to search. In a table with capacity 2^c entries, hash1 is simply the upper c bits of hash0. This patch does not change this. Prior to this patch, hash2 was the c bits below hash1, padded at the low end with zeroes when c > 16. (Note that bug 927705, changeset 1a02bec165e16f370cace3da21bb2b377a0a7242, increased the maximum capacity from 2^23 to 2^26 since 2^23 was sometimes insufficient!) This manner of computing hash2 is problematic because it increases the risk of long chains for very large tables, since there is less variation in the hash2 result due to the zero padding. So this patch changes the hash2 computation by using the low bits of hash0 instead of shifting it around, thus avoiding 0 bits in parts of the hash2 value that are significant. Note that this changes what hash2 is in all cases except when the table capacity is exactly 2^16, so it does change our hashing characteristics. For tables with capacity less than 2^16, it should be using a different second hash, but with the same amount of random-ish data. For tables with capacity greater than 2^16, it should be using more random-ish data. Note that this patch depends on the patch for bug 1353458 in order to avoid causing test failures. MozReview-Commit-ID: JvnxAMBY711
d8c7a5c7cb77f8fc3527a4b020291b920a7afda2: Bug 1352888 - Don't set the collision flag when adding to PLDHashTable if we've already found the entry we're going to add. r=njn
L. David Baron <dbaron@dbaron.org> - Wed, 31 May 2017 13:44:02 -0700 - rev 587410
Push 61697 by bmo:tigleym@gmail.com at Thu, 01 Jun 2017 00:38:44 +0000
Bug 1352888 - Don't set the collision flag when adding to PLDHashTable if we've already found the entry we're going to add. r=njn PLDHashTable's entry store has two types of unoccupied entries: free entries and removed entries. The search of a chain of entries (determined by the hash value) in the entry store to search for an entry can stop at free entries, but it continues across removed entries, because removed entries are entries that may have been skipped over when we were adding the value we're searching for to the hash, but have since been removed. For live entries, we also maintain this distinction by using one bit of storage for a collision flag, which notes that if the hashtable entry is removed, its place in the entry store must become a removed entry rather than a free entry. When we add a new entry to the table, Add's semantics require that we return an existing entry if there is one, and only create a new entry if no existing entry exists. (Bug 1352198 suggests the possibility of a faster alternative Add API where the caller guarantees that the key is not already in the hashtable.) When we search for the existing entry, we must thus continue the search across removed entries, even though we record the first removed entry found to return if the search for an existing entry fails. The existing code adds the collision flag through the entire table search during an Add. This patch changes that behavior so that we only add the collision flag prior to finding the first removed entry. Adding it after we find the first removed entry is unnecessary, since we are not making that entry part of a path to a new entry. If it is part of a path to an existing entry, it will already have the collision flag set. This patch effectively puts an if (!firstRemoved) around the else branch of the if (MOZ_UNLIKELY(EntryIsRemoved(entry))), and then refactors that condition outwards since it is now around the contents of both the if and else branches. MozReview-Commit-ID: CsXnMYttHVy
Sam Foster <sfoster@mozilla.com> - Wed, 24 May 2017 15:03:33 -0700 - rev 587409
Push 61696 by bmo:sfoster@mozilla.com at Thu, 01 Jun 2017 00:28:43 +0000
0573788632df7d9bbf13f184a547792a33b73028: Bug 1369198: Ensure pushing a declaration to a declaration block always inserts it at the last position. r?heycam draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 01 Jun 2017 02:24:58 +0200 - rev 587408
Push 61695 by bmo:emilio+bugs@crisal.io at Thu, 01 Jun 2017 00:26:52 +0000
Bug 1369198: Ensure pushing a declaration to a declaration block always inserts it at the last position. r?heycam MozReview-Commit-ID: LM9mK6ngZ4e
2a3a0f8b97fe84bc57b326771216b03a32990446: Bug 1354016 - Forms validator ignore clientMissing. r?tcsc draft
tiago <tiago.paez11@gmail.com> - Wed, 31 May 2017 21:16:57 -0300 - rev 587407
Push 61694 by bmo:tiago.paez11@gmail.com at Thu, 01 Jun 2017 00:17:13 +0000
Bug 1354016 - Forms validator ignore clientMissing. r?tcsc MozReview-Commit-ID: 1ekE6VsrD3m
bf8cb1e1286493d23daafca841a4516dd6a49da0: Bug 1369228: Respect `all` shorthand position when parsing property declaration blocks. r?heycam draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 01 Jun 2017 01:18:43 +0200 - rev 587406
Push 61693 by bmo:emilio+bugs@crisal.io at Thu, 01 Jun 2017 00:01:06 +0000
Bug 1369228: Respect `all` shorthand position when parsing property declaration blocks. r?heycam MozReview-Commit-ID: 457spIBP4df
d34ee11252f17e6a19f8b38aace626e08b8510d5: Bug 1369214 - test_getProcess.html should explicitly require Services in its process script. r=poirot draft
Andrew McCreight <continuation@gmail.com> - Wed, 31 May 2017 16:09:06 -0700 - rev 587405
Push 61692 by bmo:continuation@gmail.com at Wed, 31 May 2017 23:40:17 +0000
Bug 1369214 - test_getProcess.html should explicitly require Services in its process script. r=poirot MozReview-Commit-ID: BIjsqgIedxD
17be1af9ec29aac09ff046e436c7ea464bd8707e: Bug 1363843 - Remove Java Addons support from Fennec, Part 2 draft
Varun Iyer <dev.varuniyer@gmail.com> - Wed, 31 May 2017 16:22:47 -0700 - rev 587404
Push 61691 by bmo:dev.varuniyer@gmail.com at Wed, 31 May 2017 23:27:42 +0000
Bug 1363843 - Remove Java Addons support from Fennec, Part 2 MozReview-Commit-ID: IefloUObRvY
39ff874ad32489fef24d11e468e7999b82588922: Bug 1363843: Remove Java Addons support from Fennec, Part 2 draft
Varun Iyer <dev.varuniyer@gmail.com> - Wed, 31 May 2017 16:22:47 -0700 - rev 587403
Push 61690 by bmo:dev.varuniyer@gmail.com at Wed, 31 May 2017 23:26:06 +0000
Bug 1363843: Remove Java Addons support from Fennec, Part 2 MozReview-Commit-ID: IefloUObRvY
af880361e17e441101913b39e916a5c43dce7923: Bug 1369214 - test_getProcess.html should explicitly require Services in its process script. r=poirot draft
Andrew McCreight <continuation@gmail.com> - Wed, 31 May 2017 16:09:06 -0700 - rev 587402
Push 61689 by bmo:continuation@gmail.com at Wed, 31 May 2017 23:25:03 +0000
Bug 1369214 - test_getProcess.html should explicitly require Services in its process script. r=poirot MozReview-Commit-ID: BIjsqgIedxD
Varun Iyer <dev.varuniyer@gmail.com> - Wed, 31 May 2017 16:22:47 -0700 - rev 587401
Push 61688 by bmo:dev.varuniyer@gmail.com at Wed, 31 May 2017 23:23:58 +0000
Remove Java Addons support from Fennec, Part 2 MozReview-Commit-ID: IefloUObRvY
a5428b6eb66c2852186d2eba7d8679b4dd2e6662: Bug 1348932 - (be) Search engine set up for Firefox Mobile for Belarusian, r?flod draft
Delphine Lebédel <dlebedel@mozilla.com> - Wed, 31 May 2017 16:21:20 -0700 - rev 587400
Push 61687 by bmo:lebedel.delphine@gmail.com at Wed, 31 May 2017 23:22:36 +0000
Bug 1348932 - (be) Search engine set up for Firefox Mobile for Belarusian, r?flod MozReview-Commit-ID: KlNXwdnyPe8
e8e4a16ce8275bee54ed6109ac71cb5b3ac704b5: Bug 1313398: P4. Check that the out of band extradata hasn't changed. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 31 May 2017 22:03:55 +0200 - rev 587399
Push 61686 by bmo:jyavenard@mozilla.com at Wed, 31 May 2017 23:04:39 +0000
Bug 1313398: P4. Check that the out of band extradata hasn't changed. r?gerald On androi, where decoders can sometimes be recycled, the h264converter can be fed over its lifetime MediaRawData with different mExtraData. So we need to ensure that not only, the inband one hasn't changed, but that the out of band one hasn't changed either. This is a condition we could totally ignore on desktop, as when the resolution change the H264Converter is destroyed. MozReview-Commit-ID: 7w6ku6by1Qi
8c0990af2a9be74a64209c98e04824c741b77c19: Bug 1313398: P3. Don't always check if the decoder supports being recycled. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 31 May 2017 21:43:53 +0200 - rev 587398
Push 61686 by bmo:jyavenard@mozilla.com at Wed, 31 May 2017 23:04:39 +0000
Bug 1313398: P3. Don't always check if the decoder supports being recycled. r?gerald The value never changes on a system, so there's no point checking it every single time MozReview-Commit-ID: KTSslluQsKw
e4f23f0e495b0fa3640f42c644a76b3158000702: Bug 1369160 - Add a Shavar list to be used to suppress the infobar draft
Kirk Steuber <ksteuber@mozilla.com> - Wed, 31 May 2017 15:13:12 -0700 - rev 587397
Push 61685 by ksteuber@mozilla.com at Wed, 31 May 2017 22:13:44 +0000
Bug 1369160 - Add a Shavar list to be used to suppress the infobar The Flash infobar is showing up a bit too often. There are a few changes planned to address this. One of them is a list that will contain sites that should never display infobars. This patch allows the list to be downloaded from Shavar and updated via the URL classifier. MozReview-Commit-ID: BgAaysyRzIE
1ab1d812674d321d76e634953284b3983774d798: Bug 1367488 - Pre-render offscreen portions of scrollbar thumbs inside an iframe. r=mstange draft
Botond Ballo <botond@mozilla.com> - Mon, 29 May 2017 18:05:05 -0400 - rev 587396
Push 61684 by bballo@mozilla.com at Wed, 31 May 2017 21:57:15 +0000
Bug 1367488 - Pre-render offscreen portions of scrollbar thumbs inside an iframe. r=mstange MozReview-Commit-ID: LCBHnFJdGtp
a8f0beb0ed40865d6a6fdd4ceeac9e3aace7948c: Refactor gfx blocklist tests to fail on unsupported platforms. r?kats draft
Alexis Beingessner <a.beingessner@gmail.com> - Tue, 30 May 2017 09:25:40 -0400 - rev 587395
Push 61683 by bmo:a.beingessner@gmail.com at Wed, 31 May 2017 21:52:54 +0000
Refactor gfx blocklist tests to fail on unsupported platforms. r?kats MozReview-Commit-ID: CPYdL242bGc
8cf51052344c781883349975bbe58efea871e7e3: Bug 1365772 - Allow component alpha to be managed by blocklists. r?kats draft
Alexis Beingessner <a.beingessner@gmail.com> - Tue, 30 May 2017 09:25:40 -0400 - rev 587394
Push 61683 by bmo:a.beingessner@gmail.com at Wed, 31 May 2017 21:52:54 +0000
Bug 1365772 - Allow component alpha to be managed by blocklists. r?kats MozReview-Commit-ID: 5iEuUtmfkLl
eb1287715d11559f72051874eb4618e0749c6c28: Bug 1308337 - Post: Remove old background telemetry code r=nalexander draft
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 11 Apr 2017 22:31:18 -0400 - rev 587393
Push 61682 by bmo:gkruglov@mozilla.com at Wed, 31 May 2017 21:42:26 +0000
Bug 1308337 - Post: Remove old background telemetry code r=nalexander MozReview-Commit-ID: CONHqQWzB6c
15efd801d92e0a1be9db4bd2e2b1ede86583426a: Bug 1308337 - Part 8: Receive sync telemetry, construct and upload sync pings r=nalexander draft
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 31 May 2017 17:37:25 -0400 - rev 587392
Push 61682 by bmo:gkruglov@mozilla.com at Wed, 31 May 2017 21:42:26 +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 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 established, to make that work easier. MozReview-Commit-ID: 4TAT2fKrAYZ