55f52921423e84a642c8f32274f09781f4096ad7: 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 562297
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +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
f16c18406ed3a761abf85bfab91fed27b048c504: 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 562296
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian MozReview-Commit-ID: BzqieZVi7h4
e0051dae1f3921a81e3c1201decc1fad4ce5ae36: BrowserApp startup tab selection debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:59:16 +0200 - rev 562295
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
BrowserApp startup tab selection debug logging MozReview-Commit-ID: 79QnUF1Edg3
d75f3126703735640f033531a87df5d60ed0d1f6: debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:16:31 +0200 - rev 562294
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
debug logging MozReview-Commit-ID: FoUd4cklLKs
f5c7c193a9f64f0d8519dd54022c1374eab59156: Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 562293
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. 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
a0fee3047b1d217217a352d03075876a83a54652: Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:19:32 +0200 - rev 562292
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. 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
238606eb9c117895cb1d03700abbc05d16ff824f: Bug 1352997 - Part 4 - 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 562291
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
Bug 1352997 - Part 4 - 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
1488599b58dbb38abd509eac6d80950410bff8a3: Bug 1352997 - Part 3 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:55:10 +0200 - rev 562290
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
Bug 1352997 - Part 3 - 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 remain unique only within the same application session and are reused if we're terminated and then later restart, we need to take additional precautions to make sure we're really selecting the correct tab object - the savedInstanceState can carry even across (OOM-)kills. Therefore we now additionally also store and compare the current per-session UUID 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 caring about this is less important because on a full startup, the selection 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 breaks 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
f13ad17ae0919a5c9bb13cc93f66328b4d11b5f5: Bug 1352997 - Part 2 - Provide dedicated methods for typical homepage operations. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 09 Apr 2017 19:30:21 +0200 - rev 562289
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
Bug 1352997 - Part 2 - Provide dedicated methods for typical homepage operations. r?sebastian That is figuring out whether a homepage has been set (but not caring about the specific page), or else getting the homepage URL with an automatic fallback (to about:home) if no homepage has been set. MozReview-Commit-ID: D6Uy3A4P4Qc
e7c3f4d060a398a1633ec765ef7b25b5ec768367: Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 11:16:13 +0200 - rev 562288
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +0000
Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r?sebastian For BrowserApp we want to switch the last selected tab tracking to use tab selection events instead, so we need to register the listener earlier in order to catch the initial selection of the startup tab as well. MozReview-Commit-ID: F7luIE6oNK
e7fc867749120e6acad59caeb8b7b04022f4d105: 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 562287
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +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
f1f14e3d37b923b548463f42336406def5bcf034: 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 562286
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +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
89a2f5681a946aed49e777dc1d419065876bd2e9: Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 09 Apr 2017 19:49:02 +0200 - rev 562285
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +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
b04590e5f2c1c460e074e7c54d11ed690b1c8f06: Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 23:10:51 +0200 - rev 562284
Push 54013 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:17:08 +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 running 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
2845dafae994b79bd48f7879e1b2034a7000b6cb: Bug 1354508 - Add filter option for network requests checking for a specific response header. r?ntim draft
Vangelis Katsikaros <vkatsikaros@gmail.com> - Thu, 13 Apr 2017 22:59:21 +0300 - rev 562283
Push 54012 by vkatsikaros@gmail.com at Thu, 13 Apr 2017 20:12:14 +0000
Bug 1354508 - Add filter option for network requests checking for a specific response header. r?ntim MozReview-Commit-ID: E5wm5BgDJNU
3291fb32b800480d505a7965358be5ce4cd22070: 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 562282
Push 54011 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:07:26 +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
9d606c7fe6b3f68b65843cf6ec47b851c6f92c2d: 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 562281
Push 54011 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:07:26 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian MozReview-Commit-ID: BzqieZVi7h4
43eeb11b16f83826bae9dde1bb5d4ae694fa95c4: BrowserApp startup tab selection debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:59:16 +0200 - rev 562280
Push 54011 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:07:26 +0000
BrowserApp startup tab selection debug logging MozReview-Commit-ID: 79QnUF1Edg3
94e90a5303278769539813222acce9e4e98ceb52: debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:16:31 +0200 - rev 562279
Push 54011 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:07:26 +0000
debug logging MozReview-Commit-ID: FoUd4cklLKs
7eaa88b6ba3a86a184d09c26218fc021c1341e1f: Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 562278
Push 54011 by mozilla@buttercookie.de at Thu, 13 Apr 2017 20:07:26 +0000
Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. 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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip