35e0a23e1c89bc55aa667915d5af41e006c9ed3f: Bug 1346012 - Handle dead object wrappers in more places in Promise code. r=shu
Till Schneidereit <till@tillschneidereit.net> - Fri, 24 Mar 2017 22:49:38 -0700 - rev 558977
Push 52999 by maglione.k@gmail.com at Sat, 08 Apr 2017 20:53:05 +0000
Bug 1346012 - Handle dead object wrappers in more places in Promise code. r=shu MozReview-Commit-ID: HlmKwoMub9D
415cd9f874580ba859372b48bfc690bc13bf3b24: Bug 1354499. Don't record further successful results after finishing in test_discardAnimatedImage.html.
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Apr 2017 18:26:20 -0500 - rev 558976
Push 52999 by maglione.k@gmail.com at Sat, 08 Apr 2017 20:53:05 +0000
Bug 1354499. Don't record further successful results after finishing in test_discardAnimatedImage.html.
37d80135ecb58eef37aba5528f271925091b9f07: Bug 1329114 - Update talos symbolication to work with profile format version 5. r?jmaher draft
Markus Stange <mstange@themasta.com> - Sat, 08 Apr 2017 15:06:41 -0400 - rev 558975
Push 52998 by bmo:mstange@themasta.com at Sat, 08 Apr 2017 20:07:55 +0000
Bug 1329114 - Update talos symbolication to work with profile format version 5. r?jmaher MozReview-Commit-ID: K2Hd6pPLaoB
7f4064e8d29261b63619a274804e5174217e4249: Bug 1329114 - Put profiles from other processes into a 'processes' array, not into the threads array, and don't stringify them. r?njn draft
Markus Stange <mstange@themasta.com> - Sat, 08 Apr 2017 16:00:30 -0400 - rev 558974
Push 52998 by bmo:mstange@themasta.com at Sat, 08 Apr 2017 20:07:55 +0000
Bug 1329114 - Put profiles from other processes into a 'processes' array, not into the threads array, and don't stringify them. r?njn MozReview-Commit-ID: Ccl6JIbRMyX
8b4f96095a48906cad2d3d3e560393b2d895939c: Bug 1354842 - Back out bug 1255911 because the subprocess marker time adjustment is now done in perf.html. r?mconley draft
Markus Stange <mstange@themasta.com> - Sat, 08 Apr 2017 15:05:41 -0400 - rev 558973
Push 52997 by bmo:mstange@themasta.com at Sat, 08 Apr 2017 20:05:45 +0000
Bug 1354842 - Back out bug 1255911 because the subprocess marker time adjustment is now done in perf.html. r?mconley MozReview-Commit-ID: 5AhYa4axOJX
31f7dd7c340c279ea61c5234f943b4bd5aff7dce: Bug 1350967 (part 2) - Remove profiler_get_profile_jsobject_async() and profiler_save_profile_to_file_async(). r=mstange. draft
Nicholas Nethercote <nnethercote@mozilla.com> - Wed, 29 Mar 2017 15:48:13 +1100 - rev 558972
Push 52997 by bmo:mstange@themasta.com at Sat, 08 Apr 2017 20:05:45 +0000
Bug 1350967 (part 2) - Remove profiler_get_profile_jsobject_async() and profiler_save_profile_to_file_async(). r=mstange. The state management is better done within nsProfiler::GetProfileDataAsync() and nsProfiler::DumpProfileToFileAsync(). (The latter function is new in this patch.) This fixes a deadlock. Other notes: - The patch moves ProfileGatherer from ProfilerState to nsProfiler. This is nice because the former is shared between threads but the latter is main thread only. (This is how the deadlock is avoided.) - ProfilerStateMutex and PSLockRef are no longer required in platform.h. Those types and variables are now only used in platform.cpp and platform-*.cpp. - ProfilerGatherer now calls profiler_get_profile() instead of ToJSON(). Which means that ToJSON() now has a single caller, so the patch inlines it at the callsite and removes it. - profiler_save_profile_to_file_async() dispatched a Runnable to the main thread. But this wasn't necessary, because it always ran on the main thread itself. So the new function nsProfiler::DumpProfileToFileAsync() doesn't do that. - profiler_will_gather_OOP_profile(), profiler_gathered_OOP_profile(), and profiler_OOP_exit_profile() are all moved into nsProfiler as well. This removes the need for the horrible fake lock in profiler_will_gather_OOP_profile(), hooray! MozReview-Commit-ID: FGpm1KWJ3K1
ec2fc87038bf14c9d011dcf2cba59e63c6aca0c3: Bug 1350967 (part 1) - Remove profiler_get_profile_jsobject. r=mstange. draft
Nicholas Nethercote <nnethercote@mozilla.com> - Tue, 28 Mar 2017 16:01:17 +1100 - rev 558971
Push 52997 by bmo:mstange@themasta.com at Sat, 08 Apr 2017 20:05:45 +0000
Bug 1350967 (part 1) - Remove profiler_get_profile_jsobject. r=mstange. The conversion to a JSObject is better done within nsProfiler::GetProfileData(). MozReview-Commit-ID: CJVEhXuEaiS
ce244cdc57a617129a12df4b7f0ab02c0c893aab: Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 13:43:09 +0200 - rev 558970
Push 52996 by mozilla@buttercookie.de at Sat, 08 Apr 2017 19:59:11 +0000
Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs - don't appear in our normal tabs UI - are opened in separate activities - when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data. Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997). Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk. Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab. To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them. Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work. MozReview-Commit-ID: 1q5Jtv0DKrE
424924e5b78bf3baf5ba9c5feeacb16228ed8fb5: Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 14:18:23 +0200 - rev 558969
Push 52996 by mozilla@buttercookie.de at Sat, 08 Apr 2017 19:59:11 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian MozReview-Commit-ID: BzqieZVi7h4
7469504bd593bd174db76895fc0f2acb5772e9b5: debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:16:31 +0200 - rev 558968
Push 52996 by mozilla@buttercookie.de at Sat, 08 Apr 2017 19:59:11 +0000
debug logging MozReview-Commit-ID: FoUd4cklLKs
4b5366cb8c45778d47f4e450e9f7b349b4756843: Bug 1352997 - Part 5 - Implement additional startup logic for Web Apps. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 558967
Push 52996 by mozilla@buttercookie.de at Sat, 08 Apr 2017 19:59:11 +0000
Bug 1352997 - Part 5 - Implement additional startup logic for Web Apps. r?sebastian Web Apps are single task activities, but Android's task switcher will only ever return the intent that originally created the activity and will never ever update its stored intent for subsequent launches via onNewIntent, so we have to do this ourselves. Additionally, web apps have some additional logic when being launched via a new intent that checks whether the currently loaded page matches the scope of the web app intent and then resets it if necessary. We now hook up this logic to the new SingleTabActivity wiring. MozReview-Commit-ID: 9bo4gXbfPNg
15dd8e7b395649cce31fa0c8aeb24ba8cbf1ed70: Bug 1352997 - Part 4 - Remember the correct tab for CustomTab/WebAppActivities. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:19:32 +0200 - rev 558966
Push 52996 by mozilla@buttercookie.de at Sat, 08 Apr 2017 19:59:11 +0000
Bug 1352997 - Part 4 - Remember the correct tab for CustomTab/WebAppActivities. r?sebastian This implements the common behaviour for restoring the correct tab when switching to/from custom tab and web app activities. Unlike our normal UI, those activities are basically single tab activities, that is each activity is linked to a certain Gecko tab, with no facilities (bugs aside) for the user to directly load/select a different tab within that activity. Therefore, here we basically update the selected tab only when the activity is starting up and initially creating its new (or, especially once tab type switching will be implemented, taking over an existing) content tab. When subsequently restoring, we then check whether the tab is still available. If it is, we select it, if not, we fall back to opening a new tab based on the available intent data. MozReview-Commit-ID: KjFz1qrqWLy
bf4d674202a9bbd64cfb6c7173d443290112710c: Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 13:43:09 +0200 - rev 558965
Push 52995 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:58:40 +0000
Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs - don't appear in our normal tabs UI - are opened in separate activities - when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data. Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997). Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk. Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab. To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them. Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work. MozReview-Commit-ID: 1q5Jtv0DKrE
1eb132d5975b01603909f62355db7a7354275836: Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 14:18:23 +0200 - rev 558964
Push 52995 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:58:40 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian MozReview-Commit-ID: BzqieZVi7h4
f6e64363462b0ec5f8efa8d944fca712f04df1e7: debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:16:31 +0200 - rev 558963
Push 52995 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:58:40 +0000
debug logging MozReview-Commit-ID: FoUd4cklLKs
89fe253c4c5b8252f4ec07d9d582900add083f3e: Bug 1352997 - Part 5 - Implement additional startup logic for Web Apps. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 558962
Push 52995 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:58:40 +0000
Bug 1352997 - Part 5 - Implement additional startup logic for Web Apps. r?sebastian Web Apps are single task activities, but Android's task switcher will only ever return the intent that originally created the activity and will never ever update its stored intent for subsequent launches via onNewIntent, so we have to do this ourselves. Additionally, web apps have some additional logic when being launched via a new intent that checks whether the currently loaded page matches the scope of the web app intent and then resets it if necessary. We now hook up this logic to the new SingleTabActivity wiring. MozReview-Commit-ID: 9bo4gXbfPNg
51e2a313eb5ab40a2fe7c7d3bc515366c04eabab: Bug 1352997 - Part 4 - Remember the correct tab for CustomTab/WebAppActivities. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:19:32 +0200 - rev 558961
Push 52995 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:58:40 +0000
Bug 1352997 - Part 4 - Remember the correct tab for CustomTab/WebAppActivities. r?sebastian This implements the common behaviour for restoring the correct tab when switching to/from custom tab and web app activities. Unlike our normal UI, those activities are basically single tab activities, that is each activity is linked to a certain Gecko tab, with no facilities (bugs aside) for the user to directly load/select a different tab within that activity. Therefore, here we basically update the selected tab only when the activity is starting up and initially creating its new (or, especially once tab type switching will be implemented, taking over an existing) content tab. When subsequently restoring, we then check whether the tab is still available. If it is, we select it, if not, we fall back to opening a new tab based on the available intent data. MozReview-Commit-ID: KjFz1qrqWLy
1cfc7056a2657e67cf6015d18d475d65456ba592: Bug 1352997 - Part 3 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:15:19 +0200 - rev 558960
Push 52995 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:58:40 +0000
Bug 1352997 - Part 3 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r?sebastian The first activity to run triggers Gecko startup and therefore session restore. Since the selected tab stored in the session file is only of interest for BrowserApp, we need to store it somewhere safe if some other activity (e.g. custom tab/web app) starts up first. This is because currently everything needs to share the same Gecko browser window, so those other activities selecting a tab of their own when starting up will necessarily override session restore's tab selection. MozReview-Commit-ID: 9GwTDbzgWF9
d6e5d9dbc67f025567ffb4b6ed44a190dc4217c0: Bug 1352997 - Part 2 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 20:57:15 +0200 - rev 558959
Push 52995 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:58:40 +0000
Bug 1352997 - Part 2 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian Currently, we basically take a snapshot of the currently selected tab when pausing an activity and then later re-select that tab ID when switching back from another activity within our application. In practice, this doesn't seem entirely fool-proof, so when switching between our normal UI (BrowserApp) and custom tabs or web apps we can eventually end up with the wrong tab being selected in the wrong activity. In this part, we'll rip out the current code and replace it by a new implementation for BrowserApp - following parts will then cover custom tabs and web apps. As BrowserApp is our normal tabbed browsing interface, we can simply track all tab switches for BROWSING-type tabs as they happen, which ensures that our data is always up-to-date. Because tab IDs are not unique across Gecko restarts, while the savedInstanceState can carry even across (OOM-)kills, we now additionally also store the respective tab object's hash to make sure that the tab we're trying to select is really the same one it was when the activity was last running. For BrowserApp this is less important because on a full startup, this behaviour will be overridden by session restore anyway (although we can still hit it if only BrowserApp gets destroyed while Gecko keeps running, or if BrowserApp is launched after some other activity has already loaded Gecko), but it'll be quite relevant for web apps and custom tabs which don't have that benefit. As it stands, this patch temporarily break behaviour around activity restoring for custom tabs/web apps, but tearing the old implementation out in one go was easier and the patch needs to be split somewhere. MozReview-Commit-ID: I0Tq9XZGvpV
7c5890d7b7a57eed6d52431269e3f64751be99de: Bug 1255894: Part 8 - Add tests for response stream filtering. r?mixedpuppy draft
Kris Maglione <maglione.k@gmail.com> - Thu, 23 Mar 2017 12:09:26 -0700 - rev 558958
Push 52994 by maglione.k@gmail.com at Sat, 08 Apr 2017 18:56:00 +0000
Bug 1255894: Part 8 - Add tests for response stream filtering. r?mixedpuppy MozReview-Commit-ID: 9C2QnNsm1W1
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip