923d12a0f0b31518a6f85bafe9fde8f885a2d22a: Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 18:26:45 +0200 - rev 558937
Push 52992 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:39:26 +0000
Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian Differences to custom tabs: - We don't have to store the full intent, just storing the manifest path is enough. - Akin to the LauncherActivity we have to route the request to the correct WebAppActivity instance depending on the manifest path. We also have to modify the intent handling when GeckoApp is starting up - the intent handling of the GeckoApp + BrowserApp combo requires "nulling" out (by setting it to ACTION_MAIN) the current intent if it's not a fresh intent (e.g. the activity is recreated after having been destroyed or relaunched from the task switcher). For web apps on the other hand we want to keep the intent around even in those cases, as it contains state we need even later on. Additionally, we want to make use of GeckoApp's startup code for either selecting the tab from the intent or loading a new tab. Therefore we save the launch intent and restore it once GeckoApp's onCreate() has run. Note that this solution is not entirely correct either, because with this each onCreate() call will open a new tab, even when this is not necessary when only the activity (but not Firefox and Gecko as a whole) had been destroyed. This behaviour will be fixed as part of bug 1352997. This approach is also a bit different than the one chosen in bug 1351605 for custom tabs, which was independently developed in parallel. Bug 1352997 will unify this, too. MozReview-Commit-ID: 94uZ3c8CUVD
4f2bf073b81130ccffe544c95c6120021f7dd470: Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 01 Apr 2017 17:07:16 +0200 - rev 558936
Push 52992 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:39:26 +0000
Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian This can happen if closing a tab (via the back button) simultaneously also triggered an activity switch (by selecting the parent tab). In that case the tab is closed, but formal selection of the new tab only completes after we've switched activities. At the moment activity switching might trigger an application-background/foreground cycle, which means we could hit the selected tab temporarily being undefined in Gecko. MozReview-Commit-ID: 6p4cOqj29HX
2e6c6a7da582e169eba0c8442d4507cc47f05ddc: Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 05 Apr 2017 21:37:57 +0200 - rev 558935
Push 52992 by mozilla@buttercookie.de at Sat, 08 Apr 2017 18:39:26 +0000
Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian On tab selection, the Tabs instance now checks whether the type of the tab to be selected matches the currently selected activity. If it doesn't, the tab switching is aborted and instead, an intent for the correct activity is sent. When the new activity launches, it finds that the intent also includes a tab ID, which means that instead of opening a new tab we retry the tab selection, which will then succeed now that we're in the correct activity. Because for custom tabs the launch intent can contain all sorts of customisations, we now have to save the intent when a custom tab is opened for the first time, so that later on, when switching e.g. from BrowserApp back to a custom tab we can use the correct intent to launch the custom tab activity. MozReview-Commit-ID: KWdkweKBocz
43a86ee28d1f1dd9ddad8a1ab7fe805b64808e89: Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 15:43:31 +0200 - rev 558934
Push 52991 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:35:18 +0000
Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian Custom and web app tabs behave as any other externally launched URLs, that is pressing the back button closes not only the activity, but the tab as well when reaching the beginning of session history. Therefore, we should finish the activity in this case (just as the CustomTabsActivity already does), so the next launch runs through the onCreate code path and opens a new tab again. MozReview-Commit-ID: 14AhWkmb5O7
78d9af7cfad7d768675a8dfc8b14fb6d4f9fe8c5: Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 18:26:45 +0200 - rev 558933
Push 52991 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:35:18 +0000
Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian Differences to custom tabs: - We don't have to store the full intent, just storing the manifest path is enough. - Akin to the LauncherActivity we have to route the request to the correct WebAppActivity instance depending on the manifest path. We also have to modify the intent handling when GeckoApp is starting up - the intent handling of the GeckoApp + BrowserApp combo requires "nulling" out (by setting it to ACTION_MAIN) the current intent if it's not a fresh intent (e.g. the activity is recreated after having been destroyed or relaunched from the task switcher). For web apps on the other hand we want to keep the intent around even in those cases, as it contains state we need even later on. Additionally, we want to make use of GeckoApp's startup code for either selecting the tab from the intent or loading a new tab. Therefore we save the launch intent and restore it once GeckoApp's onCreate() has run. Note that this solution is not entirely correct either, because with this each onCreate() call will open a new tab, even when this is not necessary when only the activity (but not Firefox and Gecko as a whole) had been destroyed. This behaviour will be fixed as part of bug 1352997. This approach is also a bit different than the one chosen in bug 1351605 for custom tabs, which was independently developed in parallel. Bug 1352997 will unify this, too. MozReview-Commit-ID: 94uZ3c8CUVD
db0d01fe63f83c0166ab6329d0caf7ae6e55d1d2: Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 15:43:31 +0200 - rev 558932
Push 52990 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:31:10 +0000
Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian Custom and web app tabs behave as any other externally launched URLs, that is pressing the back button closes not only the activity, but the tab as well when reaching the beginning of session history. Therefore, we should finish the activity in this case (just as the CustomTabsActivity already does), so the next launch runs through the onCreate code path and opens a new tab again. MozReview-Commit-ID: 14AhWkmb5O7
d653c83e3c175f9e04e4b3da842394ce1a9e4251: Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 18:26:45 +0200 - rev 558931
Push 52990 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:31:10 +0000
Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian Differences to custom tabs: - We don't have to store the full intent, just storing the manifest path is enough. - Akin to the LauncherActivity we have to route the request to the correct WebAppActivity instance depending on the manifest path. We also have to modify the intent handling when GeckoApp is starting up - the intent handling of the GeckoApp + BrowserApp combo requires "nulling" out (by setting it to ACTION_MAIN) the current intent if it's not a fresh intent (e.g. the activity is recreated after having been destroyed or relaunched from the task switcher). For web apps on the other hand we want to keep the intent around even in those cases, as - especially for custom tabs - it contains state we need even later on. Additionally, we want to make use of GeckoApp's startup code for either selecting the tab from the intent or loading a new tab. Therefore we save the launch intent and restore it once GeckoApp's onCreate() has run. Note that this solution is not entirely correct either, because with this each onCreate() call will open a new tab, even when this is not necessary when only the activity (but not Firefox and Gecko as a whole) had been destroyed. This behaviour will be fixed as part of bug 1352997. This approach is also a bit different than the one chosen in bug 1351605 for custom tabs, which was independently developed in parallel. Bug 1352997 will unify this, too. MozReview-Commit-ID: 94uZ3c8CUVD
3e8cf1eed6e061b5346b745a0ef492fcd8a3c5b8: Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 01 Apr 2017 17:07:16 +0200 - rev 558930
Push 52990 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:31:10 +0000
Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian This can happen if closing a tab (via the back button) simultaneously also triggered an activity switch (by selecting the parent tab). In that case the tab is closed, but formal selection of the new tab only completes after we've switched activities. At the moment activity switching might trigger an application-background/foreground cycle, which means we could hit the selected tab temporarily being undefined in Gecko. MozReview-Commit-ID: 6p4cOqj29HX
69b45893e687322938ff6d60754ff68474136900: Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 05 Apr 2017 21:37:57 +0200 - rev 558929
Push 52990 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:31:10 +0000
Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian On tab selection, the Tabs instance now checks whether the type of the tab to be selected matches the currently selected activity. If it doesn't, the tab switching is aborted and instead, an intent for the correct activity is sent. When the new activity launches, it finds that the intent also includes a tab ID, which means that instead of opening a new tab we retry the tab selection, which will then succeed now that we're in the correct activity. Because for custom tabs the launch intent can contain all sorts of customisations, we now have to save the intent when a custom tab is opened for the first time, so that later on, when switching e.g. from BrowserApp back to a custom tab we can use the correct intent to launch the custom tab activity. MozReview-Commit-ID: KWdkweKBocz
99e310c46b91f30de971f335c38d18fa2838eba3: 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 558928
Push 52989 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:21:23 +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, because the ID cannot be affected by tabs earlier in the tabs list being closed. 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
46f6339e9e779a4430513e97d31dcf4eda5800b2: 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 558927
Push 52989 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:21:23 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian MozReview-Commit-ID: BzqieZVi7h4
c4cb581a65be4bb0e474ca32819bef03f743efd6: debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:16:31 +0200 - rev 558926
Push 52989 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:21:23 +0000
debug logging MozReview-Commit-ID: FoUd4cklLKs
eb23d55a20d5780db4c5957aeecf208a52c3c2cf: Bug 1352997 - Part 4 - 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 558925
Push 52989 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:21:23 +0000
Bug 1352997 - Part 4 - 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
e1cd1ad37b1973c22205be83aa3830fd3b353594: Bug 1352997 - Part 3 - 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 558924
Push 52989 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:21:23 +0000
Bug 1352997 - Part 3 - 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, once tab type switching is implemented, taking over an exisiting) 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
9281b94c46d4e6a891bec710682d049fcd933017: 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 19:15:19 +0200 - rev 558923
Push 52989 by mozilla@buttercookie.de at Sat, 08 Apr 2017 17:21:23 +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: 9GwTDbzgWF9
902c4a5c056f364ad0a9786131f34dc0cdd8828c: Bug 1354820 - Idle unloader shim prototype. draft
Andrew McCreight <continuation@gmail.com> - Sat, 08 Apr 2017 08:17:50 -0700 - rev 558922
Push 52988 by bmo:continuation@gmail.com at Sat, 08 Apr 2017 17:10:13 +0000
Bug 1354820 - Idle unloader shim prototype. MozReview-Commit-ID: H68wAplJgQo
2129414210f15de2cb9cc39d73ede4afeb17ceb3: Revert "Bug 1350472 - Log JS stacks for imports. Not for landing." draft
Andrew McCreight <continuation@gmail.com> - Sat, 08 Apr 2017 08:16:42 -0700 - rev 558921
Push 52988 by bmo:continuation@gmail.com at Sat, 08 Apr 2017 17:10:13 +0000
Revert "Bug 1350472 - Log JS stacks for imports. Not for landing." This reverts commit f4bd7853fd56d35d41d1670d6824c6963dde3f49.
387d25ecb3a51bb7bbb3dcd2b600c7ea4bfcea8a: Bug 1354341 - Don't load ConsoleAPI.jsm for passwordmgr logging unless we need it. draft
Andrew McCreight <continuation@gmail.com> - Fri, 07 Apr 2017 15:01:25 -0700 - rev 558920
Push 52988 by bmo:continuation@gmail.com at Sat, 08 Apr 2017 17:10:13 +0000
Bug 1354341 - Don't load ConsoleAPI.jsm for passwordmgr logging unless we need it. MozReview-Commit-ID: IGXWYgawmLl
c38ea0292b169805dac8a2956da484718cd6324a: remove spammy warning draft
Andrew McCreight <continuation@gmail.com> - Fri, 07 Apr 2017 10:35:39 -0700 - rev 558919
Push 52988 by bmo:continuation@gmail.com at Sat, 08 Apr 2017 17:10:13 +0000
remove spammy warning MozReview-Commit-ID: KDz65urrbnI
7515c9d88c806067a8b5a00681d57bb5c0219e58: Revert "add back in unused import" draft
Andrew McCreight <continuation@gmail.com> - Fri, 07 Apr 2017 08:27:09 -0700 - rev 558918
Push 52988 by bmo:continuation@gmail.com at Sat, 08 Apr 2017 17:10:13 +0000
Revert "add back in unused import" This reverts commit 17a14d144a1aaed6f3c4ac5a39d28228c61b0763.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip