38e611761168e65679d4c3981ffc4341e5c1a850: servo: Merge #17027 - Rollup of 9 pull requests (from Manishearth:rollup); r=Manishearth
Manish Goregaokar <manishsmail@gmail.com> - Wed, 24 May 2017 16:08:02 -0500 - rev 584178
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
servo: Merge #17027 - Rollup of 9 pull requests (from Manishearth:rollup); r=Manishearth - Successful merges: #16993, #17000, #17010, #17013, #17014, #17017, #17019, #17020, #17022 - Failed merges: Source-Repo: https://github.com/servo/servo Source-Revision: 8ae546f7ea158466441987d4a86c5c440f0a5e00
d10f5ccd882b965fcad39914f7c3c930d1301a41: Bug 1359965 - Support and generate tar.gz WPT archive; r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 08 May 2017 17:19:05 -0700 - rev 584177
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1359965 - Support and generate tar.gz WPT archive; r=glandium Several years ago there was a single zip file for all test files. Clients would only extract the files they needed. Thus, zip was a reasonable archive format because it allowed direct access to members without having to decompress the entirety of the stream. We have since split up that monolithic archive into separate, domain-specific archives. e.g. 1 archive for mochitests and one for xpcshell tests. This drastically cut down on network I/O required on testers because they only fetched archives/data that was relevant. It also enabled parallel generation of test archives, we shaved dozens of seconds off builds due to compression being a long pole. Despite the architectural changes to test archive management, we still used zip files. This is not ideal because we no longer access specific files in test archives and thus don't care about single/partial member access performance. This commit implements support for generating tar.gz test archives. And it switches the web-platform archive to a tar.gz file. The performance implications for archive generation are significant: before: 48,321,250 bytes; 6.05s after: 31,844,267 bytes; 4.57s The size is reduced because we have a single compression context so data from 1 file can benefit compression in a subsequent file. CPU usage is reduced because the compressor has to work less with 1 context than it does with N. While I didn't measure it, decompression performance should also be improved for the same reasons. And of course network I/O will be reduced. mozharness consumers use a generic method for handling unarchiving. This method automagically handles multiple file extensions. So as long as downstream consumers aren't hard coding ".zip" this change should "just work." MozReview-Commit-ID: LQa5MIHLsms
a872303fd08497bbde0e3b4cea09a88a4182810e: Bug 1359965 - Support mozpack.file.BaseFile in create_tar_from_files; r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 08 May 2017 17:00:20 -0700 - rev 584176
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1359965 - Support mozpack.file.BaseFile in create_tar_from_files; r=glandium This allows us to write files coming from a finder or other source that isn't directly the filesystem. MozReview-Commit-ID: KhPSD0JYzsQ
056af0b6adda57f3f3084df80ea494bd70ed0e89: Bug 1366180 - Fix title and parent links in resource:// listings. r=valentin
Mike Hommey <mh+mozilla@glandium.org> - Wed, 24 May 2017 11:27:22 +0900 - rev 584175
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1366180 - Fix title and parent links in resource:// listings. r=valentin For a long time, opening a resource:// url that leads to a file list has used a title of the form "Index of jar:file://..." where the jar:file://... url is the actual location the resource:// url has been resolved to in the omni.ja. That same url is used to derive a link to the parent directory. Because of security context restrictions, the resource://... page can't open a link to jar:file://... . So we use the original resource:// url to derive the parent directory link, and while here, also fix the title.
489fa9fd69d0a6a84c05687cb36c915ec0fb91a8: Bug 1367087: Update firefox.latest.macosx64-opt index. r=dustin
Wander Lairson Costa <wcosta@mozilla.com> - Tue, 23 May 2017 11:58:28 -0300 - rev 584174
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1367087: Update firefox.latest.macosx64-opt index. r=dustin The current indexed task has a big rank number, we blocks a new indexed task update. Add an index rank to uploader task big enough to replace the old indexed task. MozReview-Commit-ID: Hg5Ya4D0qYt
c2f5bb3e04cb5cf3441434c6dcf183c9e3a48a53: Bug 1352358 - Implement compact and touch theme modes for the navigation toolbar. r=dao
Johann Hofmann <jhofmann@mozilla.com> - Wed, 10 May 2017 14:58:09 -0400 - rev 584173
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1352358 - Implement compact and touch theme modes for the navigation toolbar. r=dao MozReview-Commit-ID: IXs6xe09FU9
fdb4db2101198b76fffda315963a462ee0b5931b: Bug 1367267 - Pass -fPIC when compiling the -pie configure test. r=gps
Mike Hommey <mh@glandium.org> - Wed, 24 May 2017 09:24:09 +0900 - rev 584172
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1367267 - Pass -fPIC when compiling the -pie configure test. r=gps
be8d550b1adc8d2bb756416a9bde2099920c9716: Bug 1346413 - Part 3 - Remove GeckoActivityStatus-based background detection. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 23 May 2017 21:15:13 +0200 - rev 584171
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1346413 - Part 3 - Remove GeckoActivityStatus-based background detection. r=jchen MozReview-Commit-ID: 6EhSACAvgt8
828b3361dcd5e37ac914cfc4b1f9184e23550a6c: Bug 1346413 - Part 2 - Remove GeckoActivityMonitor onNewIntent handling. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 23 May 2017 21:00:07 +0200 - rev 584170
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1346413 - Part 2 - Remove GeckoActivityMonitor onNewIntent handling. r=jchen We no longer use the activity monitor for tab type activity switching (which could happen in response to onNewIntent, so in the original implementation the GAM's current activity had to be up-to-date at that point as well) and only track the current activity via onStop/onStart, so there's no longer any need to manually monitor onNewIntent. MozReview-Commit-ID: AawXbII29qE
34672acd7c14a60cfe3b8c54e067276090de5658: Bug 1346413 - Part 1 - GeckoActivityMonitor/onStop-based application-background/foreground tracking. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 23 May 2017 21:10:55 +0200 - rev 584169
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1346413 - Part 1 - GeckoActivityMonitor/onStop-based application-background/foreground tracking. r=jchen We want to do certain things on the Gecko side when our app goes into the background (being prepared for being killed without further ado [1], setting tab visibility status, ...) or comes back into the foreground. At the moment, this works by having participating activities manually call into GeckoApplication from onPause()/onResume(), from where we then forward this to Gecko as appropriate. There also is some additional logic because we want to avoid triggering a background-/foreground-notification combo each time we switch activities *within* Firefox, e.g. when going from BrowserApp into our settings, or navigating within the settings themselves. The problem with the current implementation is that we basically need to second guess whether we were opening one of our own activities or not when an onPause() call comes in and that we have to keep remembering the assumptions made there when implementing new activities. E.g. currently we assume that if an activity is finishing during onPause(), we're not leaving the app and therefore never trigger an application-background notification. Until recently, this was correct because except for quitting the app [2], we only finished activities when going backwards through our settings menu, from which we would only end up back in our main activity. With the advent of custom tabs, this is no longer correct, as we have to finish those as well when going back - and in that case we're returning to the app that originally created the custom tab, so we ought to send an application-background notification in fact. With this patch, we therefore switch our approach and base our background-/foreground tracking on watching onStop() instead. While unlike onPause(), onStop() has the slight drawback of not being absolutely guaranteed to be called before Android possibly kills us, the big advantage is that because of the normal Android lifecycle event order [3], by the time onStop for the previous activity is called we know for sure whether another activity of our own has been launched or whether we're being sent into the background. Additionally, using an ActivityLifecycleCallbacks instance makes it easy to monitor *all* onStop/onStart calls in our app without requiring any special support from our activities. [1] E.g. cleanly shutting down the cache service, flushing pending session store writes... [2] In which case Gecko would be shutting down on its own anyway, so a missing application-background notification wouldn't matter. [3] Old activity onPause, new activity onCreate, onStart, onResume, old activity onStop, onDestroy. MozReview-Commit-ID: 4QEUMz6NLfV
232a228949834038e0601d7fbdce6acb576dbbf7: Bug 1346413 - Part 0 - Remove unneeded imports. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 23 May 2017 21:15:01 +0200 - rev 584168
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1346413 - Part 0 - Remove unneeded imports. r=jchen MozReview-Commit-ID: 4JwHRdI4JGy
9920ad0223261212b6800d1f6f018b515f023586: Bug 1355274 - Polyfill SOCK_DGRAM socketpairs with SOCK_SEQPACKET, for libasyncns. r=gcp
Jed Davis <jld@mozilla.com> - Tue, 11 Apr 2017 20:55:34 -0600 - rev 584167
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1355274 - Polyfill SOCK_DGRAM socketpairs with SOCK_SEQPACKET, for libasyncns. r=gcp MozReview-Commit-ID: 2DeklSGsjUV
a6c98d7ddc3d2a376d1ec68479bdeb7d7260aa7b: Bug 1364887: don't run SETA on try pushes; r=jmaher
Dustin J. Mitchell <dustin@mozilla.com> - Mon, 15 May 2017 13:32:15 +0000 - rev 584166
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1364887: don't run SETA on try pushes; r=jmaher MozReview-Commit-ID: 7L2I3WWziSE
7a9918ba3731b23a89abae5f9ea5584e96159ba4: Bug 1367427 - The one-offs bar is not displayed in the Awesome Bar while search suggestions hint is displayed. r=adw
Marco Bonardo <mbonardo@mozilla.com> - Wed, 24 May 2017 17:14:33 +0200 - rev 584165
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1367427 - The one-offs bar is not displayed in the Awesome Bar while search suggestions hint is displayed. r=adw MozReview-Commit-ID: KpVwQ3XzivB
139e72efae8a6ca49c5b0fa82b8e873f3e03a122: Bug 1367166 - Add MOZ_PHOTON_ANIMATIONS to AppConstants. r=jaws
Sam Foster <sfoster@mozilla.com> - Wed, 24 May 2017 10:57:31 -0700 - rev 584164
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1367166 - Add MOZ_PHOTON_ANIMATIONS to AppConstants. r=jaws MozReview-Commit-ID: 3l88gd6KmOO
89319dc2a1d0b8790e9d3a813c237ad574db86e3: Bug 869225 - Move decision whether to restore session or not onto background thread. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 11 May 2017 22:19:18 +0200 - rev 584163
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 869225 - Move decision whether to restore session or not onto background thread. r=sebastian This involves accessing the file system to check whether our last session crashed or not (as well as reading some shared preferences), so moving this onto the background thread as well avoids some strict mode warnings. With the exception of loadStartupTab(), mShouldRestore and mLastSessionCrashed are always accessed from the background thread. loadStartupTab() can potentially run on the main thread, however this is okay, because as far as I can see it is only called after the main and background thread have synchronised with each other during initialize(). mPrivateBrowsingSession in turn is now initially only accessed from the background thread for storing the data from the savedInstanceState and the passing it on to session restore. Afterwards, we pass through the synchronisation in initialize() and then all further accesses - receiving private tab data from Gecko and saving it during onSaveInstanceState - happen only on the main thread. Additionally, all data updates from Gecko will completely overwrite the previous state, so the initial value set during onCreate() will soon become irrelevant, anyway. MozReview-Commit-ID: L5hMFCXLcIf
1475d108174d941fb18cb546ff89076da9de8845: Bug 1355331 - Create an option to move sidebar between the left and right sides of the window;r=mikedeboer
Brian Grinstead <bgrinstead@mozilla.com> - Wed, 24 May 2017 09:54:34 -0700 - rev 584162
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1355331 - Create an option to move sidebar between the left and right sides of the window;r=mikedeboer MozReview-Commit-ID: 79ts9djMC3e
58f1f2ef3d07643330ea732adcafa2611cb2f92b: Bug 1352863 - Implement support for slider.snapMultiplier during APZ dragging. r=kats
Botond Ballo <botond@mozilla.com> - Fri, 19 May 2017 20:15:44 -0400 - rev 584161
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1352863 - Implement support for slider.snapMultiplier during APZ dragging. r=kats MozReview-Commit-ID: EbmjdNLVsq7
a1a7093513d03ee0f4e2eff47fb6cce346945bd6: Bug 1352863 - Rename a couple of local variables for clarity. r=kats
Botond Ballo <botond@mozilla.com> - Fri, 19 May 2017 18:43:48 -0400 - rev 584160
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1352863 - Rename a couple of local variables for clarity. r=kats MozReview-Commit-ID: 13dMmtyXL0d
f3a6eadd0a977a588b5076ece395e1e2f2929167: Bug 1352863 - Record the position of the scrollbar thumb at the start of a scrollbar drag. r=kats
Botond Ballo <botond@mozilla.com> - Fri, 19 May 2017 20:14:14 -0400 - rev 584159
Push 60644 by hikezoe@mozilla.com at Wed, 24 May 2017 23:58:23 +0000
Bug 1352863 - Record the position of the scrollbar thumb at the start of a scrollbar drag. r=kats MozReview-Commit-ID: JqEi1zJZOJa
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip