fb99ac0fe4e349f50740c923af37ea8b5c3c702b: Bug 1367596 - Don't show blank for tabs that haven't presented if they've loaded a non-blank page and are not busy. r=billm"
Mike Conley <mconley@mozilla.com> - Mon, 29 May 2017 02:21:26 -0400 - rev 361686
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1367596 - Don't show blank for tabs that haven't presented if they've loaded a non-blank page and are not busy. r=billm" MozReview-Commit-ID: 3HFG2uzlQRe
533d0f2004986ddecca666aa3ce82860df6fd002: Bug 1358223 - Part 2 - In telemetry send the effective sandbox level instead of the raw value r=Dexter
Alex Gaynor <agaynor@mozilla.com> - Fri, 12 May 2017 17:05:53 -0400 - rev 361685
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1358223 - Part 2 - In telemetry send the effective sandbox level instead of the raw value r=Dexter This gives us the most actionable piece of information from the perspective of correlating between how the sandbox is configured and behavior we see. MozReview-Commit-ID: EWWQrDHns1R
39941ecd60960ab28f5839eb0dabae669c1ab391: Bug 1358223 - Part 1 - On Windows and macOS hardcode the minimum content sandbox level at 1. r=bobowen,haik,jimm
Alex Gaynor <agaynor@mozilla.com> - Fri, 12 May 2017 17:04:42 -0400 - rev 361684
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1358223 - Part 1 - On Windows and macOS hardcode the minimum content sandbox level at 1. r=bobowen,haik,jimm If the "security.sandbox.content.level" preference is set to a value less than 1, all consumers will automatically treat it as if it were level 1. On Linux and Nightly builds, setting the sandbox level to 0 is still allowed, for now. MozReview-Commit-ID: 9QNTCkdbTfm
d8118603a0bd2e2b41bcbfd97e763e04ba4d2efe: Bug 1354155 - fix pocket button's checks for whether it is the mainview in a panelmultiview, r=mikedeboer
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 30 May 2017 16:29:45 +0100 - rev 361683
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1354155 - fix pocket button's checks for whether it is the mainview in a panelmultiview, r=mikedeboer MozReview-Commit-ID: 6kLNAtOmCjn
718fc2e88bb1daff46725c30c73dec2366d7bc33: Bug 1354155 - create library button with initial history and synced tabs views, r=bgrins
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Thu, 25 May 2017 15:15:21 +0100 - rev 361682
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1354155 - create library button with initial history and synced tabs views, r=bgrins MozReview-Commit-ID: J65DnluTXdA
27e39a0dead1a034e2bbc08fa6e88e2840fc15b8: Bug 1354155 - use photon panelmultiview for individual subviews, r=mikedeboer
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 30 May 2017 16:30:25 +0100 - rev 361681
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1354155 - use photon panelmultiview for individual subviews, r=mikedeboer MozReview-Commit-ID: 9iEHcGDLbJt
44c831aee2d0dc9a96c7a3f792420d9af0998b65: Bug 1365333 - Avoid quadratic performance in nsDisplayLayerEventRegions::AddFrame() when the maybe-hit region has many rects. r=tnikkel
Botond Ballo <botond@mozilla.com> - Wed, 31 May 2017 14:42:59 -0400 - rev 361680
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1365333 - Avoid quadratic performance in nsDisplayLayerEventRegions::AddFrame() when the maybe-hit region has many rects. r=tnikkel MozReview-Commit-ID: 99QrhFpHw15
c0db7825ec5b09c128924ae1f9b1e4186430f512: servo: Merge #17008 - Make armv7-linux-androideabi default target on Android (from MortimerGoro:android_default_armv7); r=larsberg
Imanol Fernandez <mortimergoro@gmail.com> - Wed, 31 May 2017 16:29:19 -0500 - rev 361679
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
servo: Merge #17008 - Make armv7-linux-androideabi default target on Android (from MortimerGoro:android_default_armv7); r=larsberg <!-- Please describe your changes on the following line: --> See https://github.com/servo/servo/issues/11921 After fixing problematic dependencies this is the last step to support armv7-linux-androideabi target on Android: - Updates skia dependency to fix a linker error. See https://github.com/servo/skia/pull/136 - Fixes specifying android targets on `./mach package` and `./mach install` steps: -`./mach package --release --target=arm-linux-androideabi` -`./mach package --release --target=armv7-linux-androideabi` -`./mach package --release --target=aarch64-linux-android` - Make `armv7-linux-androideabi`default when `--android` param is used in build, package or install commands --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #11921 (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> Source-Repo: https://github.com/servo/servo Source-Revision: a694f70acf2f011da816a24716d6501ab153c64e
8905663e76c5d8ed9b17d4c6a679791f3f280d1f: servo: Merge #17105 - Update rayon to 0.7.1 (from heycam:rayonup); r=nox
Cameron McCormack <cam@mcc.id.au> - Wed, 31 May 2017 15:20:22 -0500 - rev 361678
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
servo: Merge #17105 - Update rayon to 0.7.1 (from heycam:rayonup); r=nox To take advantage of nikomatsakis/rayon#348. <!-- Please describe your changes on the following line: --> --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [ ] `./mach build -d` does not report any errors - [ ] `./mach test-tidy` does not report any errors - [ ] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> Source-Repo: https://github.com/servo/servo Source-Revision: 3337fccd991fcf9e935b1ada55621be474ffb6e6
bdb2387396b4a74dfefb7c983733eed3625e906a: Bug 1369250 - set VIRTUALENV_NO_DOWNLOAD so virtualenv versions >=14 will know to not download new packages, and older versions won't object to not knowing about the commandline --no-download, a=philor CLOSED TREE
Aki Sasaki <asasaki@mozilla.com> - Wed, 31 May 2017 22:47:08 -0700 - rev 361677
Push 31938 by philringnalda@gmail.com at Thu, 01 Jun 2017 05:47:39 +0000
Bug 1369250 - set VIRTUALENV_NO_DOWNLOAD so virtualenv versions >=14 will know to not download new packages, and older versions won't object to not knowing about the commandline --no-download, a=philor CLOSED TREE
c81fbc7bbc63ccde05ba7bc132b9cbd57f606da0: bug 1369250 - avoid hitting the network with virtualenv 15.1.0. a=philor CLOSED TREE
Aki Sasaki <asasaki@mozilla.com> - Wed, 31 May 2017 21:04:18 -0700 - rev 361676
Push 31937 by philringnalda@gmail.com at Thu, 01 Jun 2017 04:26:23 +0000
bug 1369250 - avoid hitting the network with virtualenv 15.1.0. a=philor CLOSED TREE MozReview-Commit-ID: 9Pyh3wapEvc
edffa38ec0c515198f360f23d286290cb5081996: Backout bug 1368286 because of event processing regressions with nested event loops on OSX a=RyanVM
Ehsan Akhgari <ehsan@mozilla.com> - Wed, 31 May 2017 22:45:35 -0400 - rev 361675
Push 31936 by eakhgari@mozilla.com at Thu, 01 Jun 2017 02:48:07 +0000
Backout bug 1368286 because of event processing regressions with nested event loops on OSX a=RyanVM Landing on a CLOSED TREE
a8f378825e81daff1279a7d6e940b610912ee6dc: Merge inbound to m-c. a=merge
Ryan VanderMeulen <ryanvm@gmail.com> - Wed, 31 May 2017 20:25:52 -0400 - rev 361674
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +0000
Merge inbound to m-c. a=merge
2df9b5a84a80ba7259e6175c126727b87b4ce808: Bug 1367393 - Turn TFO off. r=jduell
Dragana Damjanovic <dd.mozilla@gmail.com> - Wed, 24 May 2017 05:22:00 -0400 - rev 361673
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +0000
Bug 1367393 - Turn TFO off. r=jduell
3e9ceef9b2802d2d2353b8389e6f09c77f991577: Bug 1360068 - Overhaul WebAppActivity to use GeckoView rather than GeckoApp. r=jchen,daleharvey
Dylan Roeh <droeh@mozilla.com> - Wed, 31 May 2017 16:59:50 -0500 - rev 361672
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +0000
Bug 1360068 - Overhaul WebAppActivity to use GeckoView rather than GeckoApp. r=jchen,daleharvey
5eb1cfd59d0017e714ac7eafc78561e346d5ed5f: Bug 1356346 - Overhaul CustomTabsActivity.java to use GeckoView rather than GeckoApp. r=jchen, walkingice
Dylan Roeh <droeh@mozilla.com> - Tue, 25 Apr 2017 11:48:05 -0500 - rev 361671
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +0000
Bug 1356346 - Overhaul CustomTabsActivity.java to use GeckoView rather than GeckoApp. r=jchen, walkingice
b94150e0a2991fe40a3504355fad38969b413da0: Bug 1365599 - Make Tabs use the window event dispatcher rather than global in some instances. r=jchen
Dylan Roeh <droeh@mozilla.com> - Wed, 31 May 2017 16:58:54 -0500 - rev 361670
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +0000
Bug 1365599 - Make Tabs use the window event dispatcher rather than global in some instances. r=jchen
ef0ddbc20a37650c964cd6d6e0547b9339868f16: Bug 1358798 - add a test preventing us from loading scripts unintentionally during startup, r=mconley,mccr8.
Florian Quèze <florian@queze.net> - Wed, 31 May 2017 23:00:43 +0200 - rev 361669
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +0000
Bug 1358798 - add a test preventing us from loading scripts unintentionally during startup, r=mconley,mccr8.
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 361668
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +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 361667
Push 31935 by ryanvm@gmail.com at Thu, 01 Jun 2017 00:25:58 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip