12f745ddf086bcf4166f4d840f3307b3015a38dc: Bug 1353461 - Chunk OSX debug reftests to 3, r?jmaher draft
Andrew Halberstadt <ahalberstadt@mozilla.com> - Fri, 23 Feb 2018 15:31:04 -0500 - rev 759227
Push 100313 by ahalberstadt@mozilla.com at Fri, 23 Feb 2018 22:02:04 +0000
Bug 1353461 - Chunk OSX debug reftests to 3, r?jmaher With run-by-manifest, the debug reftests timeout on OSX. Increasing the chunks by 1 seems to improve them. MozReview-Commit-ID: 14xidhwXCue
e7b720539186896156d5da19b95080fb1860007a: Bug 1353461 - [reftest] Implement run-by-manifest for reftest, r?jmaher draft
Andrew Halberstadt <ahalberstadt@mozilla.com> - Thu, 08 Feb 2018 16:16:34 -0500 - rev 759226
Push 100313 by ahalberstadt@mozilla.com at Fri, 23 Feb 2018 22:02:04 +0000
Bug 1353461 - [reftest] Implement run-by-manifest for reftest, r?jmaher Run-by-manifest is a mode where we restart Firefox between every manifest of tests. It sacrifices a little bit of runtime for better test isolation and improved stability. This turns run-by-manifest on for all platforms except Android. It also skips jsreftests and crashtests for now (mostly to limit the scope of what was landing all at once). Follow-ups will be filed to get it turned on in those places. MozReview-Commit-ID: DmvozAIPE5Q
160501b1348a8a404072135fc88cf9f6617842d0: Bug 1353461 - [reftest] remove the start-after-crash feature, r?jmaher draft
Andrew Halberstadt <ahalberstadt@mozilla.com> - Mon, 05 Feb 2018 14:24:49 -0500 - rev 759225
Push 100313 by ahalberstadt@mozilla.com at Fri, 23 Feb 2018 22:02:04 +0000
Bug 1353461 - [reftest] remove the start-after-crash feature, r?jmaher The point of start-after-crash was to resume running tests after a crash so we don't miss out on test coverage when a crash happens. Now that we're close to landing run-by-manifest, this feature is as necessary since only tests that appear later in the same manifest as the crashing test will be skipped. Another reason to remove it, is that it's current implementation is buggy. It assumes tests have a unique ID (they don't), which means we could accidentally get into an infinite loop if the wrong test happens to crash at the wrong time. A third reason to remove it is that it adds a lot of complexity to the harness. Especially now with run-by-manifest, supporting both would require handling a lot of different edge cases and make things much more complicated than the already are. All that being said, it would still provide value. Not only would it allow us to resume tests in the same manifest, but run-by-manifest isn't yet enabled on Android, jsreftest or crashtest (though we hope to get it enabled in those places in the future). So it may be worth re-implementing start-after-crash again based on the new manifest parsing mechanism that run-by-manifest uses. It should be possible to implement it a lot more cleanly now. This work will have to be left to a follow-up. MozReview-Commit-ID: P2hh5VecKW
bd8a7c41f61e27e311a35fd0f1535853742e9fae: Bug 1353461 - [manifestparser] Implement a chunk_by_manifest algorithm, r?jmaher draft
Andrew Halberstadt <ahalberstadt@mozilla.com> - Tue, 13 Feb 2018 15:16:37 -0500 - rev 759224
Push 100313 by ahalberstadt@mozilla.com at Fri, 23 Feb 2018 22:02:04 +0000
Bug 1353461 - [manifestparser] Implement a chunk_by_manifest algorithm, r?jmaher This implements a chunk_by_manifest algorithm. It is similar to chunk_by_slice in that it tries to make an even number of tests run in each chunk. However, unlike chunk_by_slice it will guarantee that tests in the same manifest will all run in the same chunk. This makes it suitable to use with run-by-manifest. This means the chunks won't be perfect (as manifests are differnet sizes). It is also prone to more randomization, similar to chunk-by-runtime. In fact, this algorithm is nearly identical to the chunk-by-runtime one, so it was refactored out to a base class. MozReview-Commit-ID: HI2ByxW0i8V
badc6da7444dcec2b24668ed01a85a5173b50bbf: Bug 1434376 - Switch over all uses of BrowserUtils.promiseLayoutFlushed to window.promiseDocumentFlushed. r?paolo draft
Mike Conley <mconley@mozilla.com> - Sun, 11 Feb 2018 20:15:11 -0500 - rev 759223
Push 100312 by mconley@mozilla.com at Fri, 23 Feb 2018 21:54:40 +0000
Bug 1434376 - Switch over all uses of BrowserUtils.promiseLayoutFlushed to window.promiseDocumentFlushed. r?paolo window.promiseDocumentFlushed will call a callback as soon as a style or layout flush is not required for the document (which might be immediately). This is a new ChromeOnly API introduced in an earlier patch in this series. This patch also removes the now-unneeded BrowserUtils.promiseLayoutFlushed and BrowserUtils.promiseReflowed methods and infrastructure. MozReview-Commit-ID: Jv7KoxBXhHG
272e54fcf817a3fb6601a44b2e529b750525c53f: Bug 1434376 - Add basic tests for window.promiseDocumentFlushed. r?paolo draft
Mike Conley <mconley@mozilla.com> - Sun, 11 Feb 2018 20:13:53 -0500 - rev 759222
Push 100312 by mconley@mozilla.com at Fri, 23 Feb 2018 21:54:40 +0000
Bug 1434376 - Add basic tests for window.promiseDocumentFlushed. r?paolo MozReview-Commit-ID: KmyqaupJRtw
f00510794a003dd5ca260131d5dadf428053089e: Bug 1434376 - Introduce ChromeOnly window.promiseDocumentFlushed to detect when refresh driver ticks have completed. r?bz draft
Mike Conley <mconley@mozilla.com> - Sun, 11 Feb 2018 20:14:49 -0500 - rev 759221
Push 100312 by mconley@mozilla.com at Fri, 23 Feb 2018 21:54:40 +0000
Bug 1434376 - Introduce ChromeOnly window.promiseDocumentFlushed to detect when refresh driver ticks have completed. r?bz This is particularly useful for knowing when it's safe to query for style and layout information for a window without causing a synchronous style or layout flush. Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed to avoid potential confusion with the actual network-level refresh of browsers or documents. MozReview-Commit-ID: Am3G9yvSgdN
f82947aa3cd259880ba1013566421113d574238f: Bug 1440118 - Mochitest for scrolling over unlayerized subframe with overscroll-behavior. r=kats draft
Botond Ballo <botond@mozilla.com> - Fri, 23 Feb 2018 16:11:50 -0500 - rev 759220
Push 100311 by bballo@mozilla.com at Fri, 23 Feb 2018 21:53:16 +0000
Bug 1440118 - Mochitest for scrolling over unlayerized subframe with overscroll-behavior. r=kats MozReview-Commit-ID: JbMpBQqBm2y
a75aa57831ec65f6390b445a24481900195e0441: Bug 1440118 - If the APZ content response timeout is set to zero, use the fallback (timeout) behavior unconditionally. r=kats draft
Botond Ballo <botond@mozilla.com> - Wed, 21 Feb 2018 17:55:03 -0500 - rev 759219
Push 100311 by bballo@mozilla.com at Fri, 23 Feb 2018 21:53:16 +0000
Bug 1440118 - If the APZ content response timeout is set to zero, use the fallback (timeout) behavior unconditionally. r=kats MozReview-Commit-ID: HrkUd3MJoxC
4cf71ea7d6eac0841facb75b8925efe29fd34c55: Bug 1440772 - Add Section menu, Pocket highlights and bug fixes to Activity Stream. r?ursula draft
Ed Lee <edilee@mozilla.com> - Fri, 23 Feb 2018 12:36:37 -0800 - rev 759218
Push 100310 by bmo:edilee@mozilla.com at Fri, 23 Feb 2018 21:52:46 +0000
Bug 1440772 - Add Section menu, Pocket highlights and bug fixes to Activity Stream. r?ursula MozReview-Commit-ID: CYzpltysMbd
63b30073ea00418496ea9715778ebd90971e50b8: Bug 1437382 - Part 11 - Shorten save delay when private tabs are closed. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 17 Feb 2018 16:42:13 +0100 - rev 759217
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 11 - Shorten save delay when private tabs are closed. r?esawin In most cases (e.g. new tabs added, page navigation, scrolling, etc.), we can live with the fact the the private tab data held by GeckoApp might be up to ~10 seconds out of date if we don't manage to send an update within the time limit given by the UI during backgrounding. Where the closing of private tabs is concerned, this is different, as not remembering that the user already closed some tabs just before switching away from Firefox could lead to potentially embarrassing situations when the user returns and unexpectedly finds those tabs still open. Therefore we now use the infrastructure added in the previous parts to speed up the saving process when private tabs are closed. MozReview-Commit-ID: KpfXinOl5Ki
1d1d8a113eba74fd8d0b637953ee58fbc2cef612: Bug 1437382 - Part 10 - Use a reduced save delay when saving private tabs. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 17 Feb 2018 16:31:20 +0100 - rev 759216
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 10 - Use a reduced save delay when saving private tabs. r?esawin ... and also shorten any already running save timer if necessary. This is because the private tab data kept by GeckoApp, that will be restored if we are OOM-killed, cannot be updated anymore after Firefox goes into the back- ground, even if we aren't immediately killed by the OS. Because during backgrounding the UI only waits a limited amount of time for the latest private tab data in order to avoid causing an ANR if Gecko is busy, we need to compensate by sending private tab data updates faster to GeckoApp than the usual write throttling interval of every 10 s would allow. To allow multiple successive tab events to be batched together in one update, e.g. if the user closes *all* private tabs, we still introduce a small save delay of a few hundred ms. MozReview-Commit-ID: J15RNfAlfy2
0a2702ecfbcb028dcff935d0aaa714136ae8c7c1: Bug 1437382 - Part 9 - Track number of outstanding "private tabs only" saveState calls. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 22:15:35 +0100 - rev 759215
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 9 - Track number of outstanding "private tabs only" saveState calls. r?esawin Private tabs are saved in memory only by sending them to GeckoApp, so to speed up processing (compare part 3), we want to avoid writing out the full session store file for normal tabs as well if all outstanding saveState(Delayed) calls concerned private tabs only. To that effect, we slightly change the semantics of our pendingWrites counter and now increment it each time saveStateDelayed is called, even if the save timer is already running. This is because if e.g. a private tab update started the timer and then another saveStateDelayed call happens for a non-private tab, we need to change our plans and write the normal session store file after all as well. Tracking every saveStateDelayed call allows us to do this. Because writeFile only cares about the fact whether additional pending writes were queued while it was executing asynchronously or not, but not about the absolute amount of pending writes (if no additional writes were queued, the count is simply reset to 0), incrementing the pending writes count even when the timer is already running causes no ill effects. MozReview-Commit-ID: AjhIp8bpyf
819a9dabfecea69fb02e7a35e73177a891d506f7: Bug 1437382 - Part 8 - Extract functions for creating and cancelling the delayed write timer. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 20:19:15 +0100 - rev 759214
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 8 - Extract functions for creating and cancelling the delayed write timer. r?esawin MozReview-Commit-ID: BjZ2XYSi9rR
9fb375b6022a3395d0db737d1405cf2f9d7d31be: Bug 1437382 - Part 7 - Change session store time callback behaviour. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 20:11:46 +0100 - rev 759213
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 7 - Change session store time callback behaviour. r?esawin When we get a timer callback for delayed saving, we already only proceed if we've still got a write pending. Conversely if for whatever reasons _saveState() is called from outside of a timer callback, any still pending save timer is cancelled again. With that in mind, when executing the delayed write timer callback there's no reason to call the public version of saveState(), whose only extra task is to increment the pending write count again. Instead, we can just directly call the internal _saveState() version. MozReview-Commit-ID: 11EucNm5KFB
4e3ee67e307d5719a975ade60aaebd4599fd58b5: Bug 1437382 - Part 6 - Switch to using PrivateBrowsing helper method in session store. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 12 Feb 2018 20:37:07 +0100 - rev 759212
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 6 - Switch to using PrivateBrowsing helper method in session store. r?esawin As far as I can tell, that line dates back to approximately the time Private- BrowsingUtils were introduced in the first place. MozReview-Commit-ID: BLn13X7DVJt
4e096fd78cba90bc4c1c39d6a46ddb3fd327e4c6: Bug 1437382 - Part 5 - Measure how long we actually wait for the session data to arrive. r?liuche draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 22 Feb 2018 21:01:26 +0100 - rev 759211
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 5 - Measure how long we actually wait for the session data to arrive. r?liuche We want to know how long we actually have to block during onSaveInstanceState while waiting for the session store to send fresh data and how commonly we give up after waiting the maximum amount of time (currently 500 ms). MozReview-Commit-ID: CJ6fnzsKGLs
796590f1e15569fa68109b54b97468b8021d1296: Bug 1437382 - Part 4 - Test that flushing pending session store data sends the expected messages to Java. r?jchen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 20 Feb 2018 20:18:36 +0100 - rev 759210
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 4 - Test that flushing pending session store data sends the expected messages to Java. r?jchen We attempt to get the session store into a known state as far as is possible from Java and then test various situations to check that the expected "PrivateBrowsing:Data" message is received in each case. MozReview-Commit-ID: 8RkCQjAPXTT
63a7e4416d012cb8f4bd3c79b27b8c1275d09470: Bug 1437382 - Part 3 - Make sure that flushing private tabs data reaches GeckoApp in time. r?jchen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 11 Feb 2018 17:54:58 +0100 - rev 759209
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 3 - Make sure that flushing private tabs data reaches GeckoApp in time. r?jchen There are two parts to this: 1. While the file writing itself can be done either synchronously or asynchro- nously, the session store's _writeFile function as a whole always behaves asynchronously. To make sure that the private tab data held in GeckoApp is updated before being passed off to the OS during onSaveInstanceState, we therefore need to send it while still executing synchronously within our onApplicationBack- ground handling, i.e. before calling _writeFile. 2. Sending the data to Java needs to happen synchronously as well, so we need to listen for "PrivateBrowsing:Data" on the Gecko thread now. This in turn means that some sychronisation is now required between the UI thread handling onSaveInstanceState and the Gecko thread that is actually receiving the data. To avoid hanging the UI and causing ANRs, we only wait a limited amount of time for Gecko to respond with fresh private tabs data, though. As this still leaves a certain possibility of outdated private browsing data being saved and possibly restored after an OOM-kill, we're also going to speed up the processing of TabClosed events by the session store in the following parts. MozReview-Commit-ID: EkNFre5RhQW
dc9674bd1207231a9903006b2b27bee37227c536: Bug 1437382 - Part 2 - Flush session store tab data separately from application-background. r?jchen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 22 Feb 2018 19:55:13 +0100 - rev 759208
Push 100309 by mozilla@buttercookie.de at Fri, 23 Feb 2018 21:48:48 +0000
Bug 1437382 - Part 2 - Flush session store tab data separately from application-background. r?jchen We need to block onSaveInstanceState until we're sure that our private browsing data is up to date, however we can't block on the whole of our application- background handling (GeckoThread.onPause), as that will take too much time. In addition, we need to update the stored tab data not just when the application goes into the background, but every time we're leaving GeckoApp and onSave- InstanceState is called, e.g. when visiting our settings activity. MozReview-Commit-ID: DgtUvatD6h3
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip