a4a1e993657ff3abcc975249812723ab46bc84a8: Bug 1359090 - load devtools-browser.css dynamically when starting devtools;r=ochameau draft
Julian Descottes <jdescottes@mozilla.com> - Thu, 27 Apr 2017 16:05:31 +0200 - rev 570388
Push 56470 by jdescottes@mozilla.com at Fri, 28 Apr 2017 19:53:28 +0000
Bug 1359090 - load devtools-browser.css dynamically when starting devtools;r=ochameau This changeset modifies devtools-browser.css to import: - commandline-browser.css (needed for GCLI) - responsivedesign.css (needed for the old RDM) These files are no longer included in the main browser.css files. devtools-browser.css is also no longer loaded by browser.xul. Instead it is dynamically loaded when devtools need the browser stylesheet: - when creating a side or bottom host (need the splitter) - when opening gcli - when opening the old responsive design devtools-browser.js keeps track of the browser stylesheets loaded in the various tracked windows and will remove the stylesheet when the window is unloaded. MozReview-Commit-ID: AL3CxS7mvdO
13d2aef113377682f79c861a66a715b6e24f144d: Bug 1336763 - Wait for the browser to say it can go back before going back in browser_grouped_shistory_dead_navigate.js test. r?mystor draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 15:07:55 -0400 - rev 570387
Push 56469 by mconley@mozilla.com at Fri, 28 Apr 2017 19:52:42 +0000
Bug 1336763 - Wait for the browser to say it can go back before going back in browser_grouped_shistory_dead_navigate.js test. r?mystor This test was accidentally taking advantage of the fact that closing a tab will result in a nested event loop while waiting for the permitUnload messages to be sent back and forth from the content process. This meant that the message that tells the parent that the browser (which is having its history set) can now go back had a chance to be received by the parent. With the patches in bug 1336763, we're no longer spinning the event loop if the closing tab doesn't have a beforeunload event handler in it, so we need to wait for the browser to report that it can go back before actually sending it back in order to avoid a test failure. MozReview-Commit-ID: Lpl55iErrvf
774f46bc9638562c49c7226c075c68109b1b2c27: Bug 1336763 - Don't wait for response from content process in browser_closeTab.js UITour test to avoid a timeout. r?MattN draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 15:04:46 -0400 - rev 570386
Push 56469 by mconley@mozilla.com at Fri, 28 Apr 2017 19:52:42 +0000
Bug 1336763 - Don't wait for response from content process in browser_closeTab.js UITour test to avoid a timeout. r?MattN The closeTab API call from UITour tells the parent process to close the current tab, and doing so might end up disconnecting the message manager. This means that the Promise that the ContentTask returns may never resolve. Instead of waiting for it to resolve, we just wait for the TabClose event in the parent process. MozReview-Commit-ID: Ci7ck9j4llK
7e5b695fbd4578d3a74888ac121c63d8841cf58b: Bug 1336763 - Update browser_beforeunload_between_chrome_content.js to use ContentTask. r?jessica draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 12:46:59 -0400 - rev 570385
Push 56469 by mconley@mozilla.com at Fri, 28 Apr 2017 19:52:42 +0000
Bug 1336763 - Update browser_beforeunload_between_chrome_content.js to use ContentTask. r?jessica By using ContentTask, we get a Promise that resolves once we've heard confirmation from the content process that the ContentTask function has completed running. This means we can be certain that browser_beforeunload_between_chrome_content.js has had the beforeunload event handlers added before attempting to unload the page. MozReview-Commit-ID: DhoTsOZ4BNk
830afcae08b9cc5efc7364b073664e716ea342b0: Bug 1336763 - If browser.permitUnload times out in CanCloseWindow, make sure to check the rest of the browsers belonging to other processes before returning a result. r?dao draft
Mike Conley <mconley@mozilla.com> - Wed, 19 Apr 2017 14:29:42 -0400 - rev 570384
Push 56469 by mconley@mozilla.com at Fri, 28 Apr 2017 19:52:42 +0000
Bug 1336763 - If browser.permitUnload times out in CanCloseWindow, make sure to check the rest of the browsers belonging to other processes before returning a result. r?dao MozReview-Commit-ID: D59PVfsbDV0
9d72e1703e33bdafaa4f3c81d1cd65cef3c71ee8: Bug 1336763 - Don't ask content process for permission to unload a window if it never set an onbeforeunload event handler. r?dao draft
Mike Conley <mconley@mozilla.com> - Thu, 13 Apr 2017 19:13:34 -0400 - rev 570383
Push 56469 by mconley@mozilla.com at Fri, 28 Apr 2017 19:52:42 +0000
Bug 1336763 - Don't ask content process for permission to unload a window if it never set an onbeforeunload event handler. r?dao MozReview-Commit-ID: JfNz5SdKRTN
093547d34bd6fdd0ef8a934f97a46288314058ff: Bug 1336763 - Regression tests that exercise nsITabParent's hasBeforeUnload attribute. r?ehsan draft
Mike Conley <mconley@mozilla.com> - Fri, 14 Apr 2017 18:32:37 -0400 - rev 570382
Push 56469 by mconley@mozilla.com at Fri, 28 Apr 2017 19:52:42 +0000
Bug 1336763 - Regression tests that exercise nsITabParent's hasBeforeUnload attribute. r?ehsan MozReview-Commit-ID: 5prqteICE7M
c7fcbbae4712e21b79793c2a41c4580f02bec366: Bug 1336763 - Add a hasBeforeUnload attribute to nsITabParent. r?ehsan draft
Mike Conley <mconley@mozilla.com> - Thu, 13 Apr 2017 17:54:07 -0400 - rev 570381
Push 56469 by mconley@mozilla.com at Fri, 28 Apr 2017 19:52:42 +0000
Bug 1336763 - Add a hasBeforeUnload attribute to nsITabParent. r?ehsan This will return true if any of the frames loaded in the associated TabChild have set at least one onbeforeunload event handler. If those handlers are all removed, or all of the documents with onbeforeunload event handlers are unloaded, this becomes false again. Note that subframes that are sandboxed without the allow-modals permission will not affect the hasBeforeUnload attribute, since those iframes should never cause the beforeunload confirmation dialog to display. MozReview-Commit-ID: 8b0gBYWwMDn
f9f6f401896d08aafde263f5afe9af6a8640c5d7: part 2 draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 28 Apr 2017 20:05:22 +0200 - rev 570380
Push 56468 by mozilla@buttercookie.de at Fri, 28 Apr 2017 19:52:36 +0000
part 2 MozReview-Commit-ID: LdmyJ5i10jZ
4478f2e6f17145eca168e5d9e20693373ba17723: Bug 1358223 - On Windows and macOS hardcode the minimum content sandbox level at 1. draft
Alex Gaynor <agaynor@mozilla.com> - Tue, 25 Apr 2017 10:03:09 -0400 - rev 570379
Push 56467 by bmo:agaynor@mozilla.com at Fri, 28 Apr 2017 19:44:01 +0000
Bug 1358223 - On Windows and macOS hardcode the minimum content sandbox level at 1. 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
f702e3998a6a929df0067cdec1390e75f66a969a: part 2 draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 28 Apr 2017 20:05:22 +0200 - rev 570378
Push 56466 by mozilla@buttercookie.de at Fri, 28 Apr 2017 19:36:51 +0000
part 2 MozReview-Commit-ID: LdmyJ5i10jZ
cf221c1ab979e7c17267a3cb47eb29eae52dd67a: Bug 1359531 - Part 1 - Call GeckoApp's tab event handler from web apps/custom tabs, too. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 28 Apr 2017 20:16:19 +0200 - rev 570377
Push 56466 by mozilla@buttercookie.de at Fri, 28 Apr 2017 19:36:51 +0000
Bug 1359531 - Part 1 - Call GeckoApp's tab event handler from web apps/custom tabs, too. r?sebastian,walkingice We want to move the activity switching code into the activity (i.e. GeckoApp) itself and run it from its onTabChanged handler in response to the appropriate events (at the moment that's only SELECTED), so we need to ensure that this will actually be called within custom tabs/web apps as well. Additionally, there's no need to separately register the tab events listener from the CustomTabs/WebAppActivity as well if our parent class already does it for us. MozReview-Commit-ID: 6PIq1KncDcA
6d45f81212059b7a0c47cebf603f5f8198f2f5f2: Bug 1359653: Part 7 - Use the script preloader for loading frame scripts. r?billm draft
Kris Maglione <maglione.k@gmail.com> - Thu, 27 Apr 2017 23:48:04 -0700 - rev 570376
Push 56465 by maglione.k@gmail.com at Fri, 28 Apr 2017 19:36:32 +0000
Bug 1359653: Part 7 - Use the script preloader for loading frame scripts. r?billm MozReview-Commit-ID: L0EjM0Uomfb
32eef54e4828db39a9f8ba02994a0e40e87eab1e: Bug 1359653: Part 6 - Use the script precompiler in the JS component loader and subscript loader. r?mccr8,shu draft
Kris Maglione <maglione.k@gmail.com> - Fri, 28 Apr 2017 12:25:13 -0700 - rev 570375
Push 56465 by maglione.k@gmail.com at Fri, 28 Apr 2017 19:36:32 +0000
Bug 1359653: Part 6 - Use the script precompiler in the JS component loader and subscript loader. r?mccr8,shu MozReview-Commit-ID: HMl0xbAARHK
56496615b2f626513166b0c9192916b7e630363a: Bug 1359653: Part 5 - Pre-load scripts needed during startup in a background thread. r?shu,erahm draft
Kris Maglione <maglione.k@gmail.com> - Fri, 28 Apr 2017 12:28:16 -0700 - rev 570374
Push 56465 by maglione.k@gmail.com at Fri, 28 Apr 2017 19:36:32 +0000
Bug 1359653: Part 5 - Pre-load scripts needed during startup in a background thread. r?shu,erahm One of the things that I've noticed in profiling startup overhead is that, even with the startup cache, we spend about 130ms just loading and decoding scripts from the startup cache on my machine. I think we should be able to do better than that by doing some of that work in the background for scripts that we know we'll need during startup. With this change, we seem to consistently save about 3-5% on non-e10s startup overhead on talos. But there's a lot of room for tuning, and I think we get some considerable improvement with a few ongoing tweeks. Some notes about the approach: - Setting up the off-thread compile is fairly expensive, since we need to create a global object, and a lot of its built-in prototype objects for each compile. So in order for there to be a performance improvement for OMT compiles, the script has to be pretty large. Right now, the tipping point seems to be about 20K. There's currently no easy way to improve the per-compile setup overhead, but we should be able to combine the off-thread compiles for multiple smaller scripts into a single operation without any additional per-script overhead. - The time we spend setting up scripts for OMT compile is almost entirely CPU-bound. That means that we have a chunk of about 20-50ms where we can safely schedule thread-safe IO work during early startup, so if we schedule some of our current synchronous IO operations on background threads during the script cache setup, we basically get them for free, and can probably increase the number of scripts we compile in the background. - I went with an uncompressed mmap of the raw XDR data for a storage format. That currently occupies about 5MB of disk space. Gzipped, it's ~1.2MB, so compressing it might save some startup disk IO, but keeping it uncompressed simplifies a lot of the OMT and even main thread decoding process, but, more importantly: - We currently don't use the startup cache in content processes, for a variety of reasons. However, with this approach, I think we can safely store the cached script data from a content process before we load any untrusted code into it, and then share mmapped startup cache data between all content processes. That should speed up content process startup *a lot*, and very likely save memory, too. And: - If we're especially concerned about saving per-process memory, and we keep the cache data mapped for the lifetime of the JS runtime, I think that with some effort we can probably share the static string data from scripts between content processes, without any copying. Right now, it looks like for the main process, there's about 1.5MB of string-ish data in the XDR dumps. It's probably less for content processes, but if we could save .5MB per process this way, it might make it easier to increase the number of content processes we allow. MozReview-Commit-ID: CVJahyNktKB
c870ccf566f3b57e672ab15ce6203c280db310f3: Bug 1359653: Part 4 - Fallback to the default JS version when decoding regexps off-thread. r?shu draft
Kris Maglione <maglione.k@gmail.com> - Fri, 28 Apr 2017 11:55:52 -0700 - rev 570373
Push 56465 by maglione.k@gmail.com at Fri, 28 Apr 2017 19:36:32 +0000
Bug 1359653: Part 4 - Fallback to the default JS version when decoding regexps off-thread. r?shu When decoding off-thread, we can't safely access the JS runtime to get the current JS version, and doing so causes failed assertions. MozReview-Commit-ID: Lra437aa8SM
1d04e935773ada5045798a31194de3a5767279a6: Bug 1359653: Part 3 - Add a Clear() method to AutoCleanLinkedList. r?waldo draft
Kris Maglione <maglione.k@gmail.com> - Thu, 27 Apr 2017 21:15:09 -0700 - rev 570372
Push 56465 by maglione.k@gmail.com at Fri, 28 Apr 2017 19:36:32 +0000
Bug 1359653: Part 3 - Add a Clear() method to AutoCleanLinkedList. r?waldo MozReview-Commit-ID: 2bUTMPviJzg
12abb113b05de62352182de4b377e521d183a77a: Bug 1359653: Part 2 - Allow CloneAndExecuteScript with non-lexical scripts. r?shu draft
Kris Maglione <maglione.k@gmail.com> - Thu, 27 Apr 2017 23:23:54 -0700 - rev 570371
Push 56465 by maglione.k@gmail.com at Fri, 28 Apr 2017 19:36:32 +0000
Bug 1359653: Part 2 - Allow CloneAndExecuteScript with non-lexical scripts. r?shu MozReview-Commit-ID: Hq3rvgjwH3f
77b4b08c558c73611bce28e578f969d382536213: Bug 1359653: Part 1 - Use a const Range rather than a Vector for XDR decoding. r?shu draft
Kris Maglione <maglione.k@gmail.com> - Fri, 28 Apr 2017 09:47:07 -0700 - rev 570370
Push 56465 by maglione.k@gmail.com at Fri, 28 Apr 2017 19:36:32 +0000
Bug 1359653: Part 1 - Use a const Range rather than a Vector for XDR decoding. r?shu MozReview-Commit-ID: JkGNmOAKAxD
31e2d2ae13c8ff757dfda56b20a69a33367f0110: Bug 1358774 - Prevent dynamic toolbar from changing state when transitioning from multiple touch sources to a single touch source r=botond draft
Randall Barker <rbarker@mozilla.com> - Tue, 25 Apr 2017 12:04:25 -0700 - rev 570369
Push 56464 by bmo:rbarker@mozilla.com at Fri, 28 Apr 2017 19:34:48 +0000
Bug 1358774 - Prevent dynamic toolbar from changing state when transitioning from multiple touch sources to a single touch source r=botond The MultiTouchInput::MULTITOUCH_END generated from transitioning from multiple touch sources to a single source would often cause the content to shift under the remaining finger which would look like a fling and cause the content to rapidly scroll. This patch treats the transition from multiple touch source to a single source as if the touch event were starting over by resetting all the variables tracking the touch drag that is in progress. MozReview-Commit-ID: 42L1Q622fww
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip