6e944c07851b5977ea0eb7927487c47855a88a3c: Bug 1350638 - Remove sync GetCompositorOptions call in TabChild::InitRenderingState. r?dvander draft
Kartikaya Gupta <kgupta@mozilla.com> - Sun, 09 Apr 2017 12:19:05 -0400 - rev 559327
Push 53056 by kgupta@mozilla.com at Sun, 09 Apr 2017 20:46:31 +0000
Bug 1350638 - Remove sync GetCompositorOptions call in TabChild::InitRenderingState. r?dvander The goal of this patch is to remove the call to the sync IPC GetCompositorOptions message from TabChild::InitRenderingState. In order to this, we have InitRenderingState take the CompositorOptions as an argument instead, and propagate that backwards through the call sites. Eventually we can propagate it back to a set of already-sync IPC messages in PCompositorBridge that are used during layers id registration (NotifyChildCreated, NotifyChildRecretaed, etc.). Therefore this patch effectively piggybacks the CompositorOptions sync IPC onto these pre-existing sync IPC messages. The one exception is when we propagate it back to the AdoptChild call. If this message were sync we could just use it like the others and have it return a CompositorOptions. However, it is async, so instead we add another call to GetCompositorOptions here temporarily. This will be removed in the next patch. MozReview-Commit-ID: 6cZlEvEm4Xg
c6dd79ff61be3c1f1e6a8e4811ed5fc1e884feba: No bug, Automated HPKP preload list update from host bld-linux64-spot-325 - a=hpkp-update
ffxbld - Sun, 09 Apr 2017 08:46:38 -0700 - rev 559326
Push 53056 by kgupta@mozilla.com at Sun, 09 Apr 2017 20:46:31 +0000
No bug, Automated HPKP preload list update from host bld-linux64-spot-325 - a=hpkp-update
0a53c62750fffbbc61bece811c429b8eabed0064: No bug, Automated HSTS preload list update from host bld-linux64-spot-325 - a=hsts-update
ffxbld - Sun, 09 Apr 2017 08:46:35 -0700 - rev 559325
Push 53056 by kgupta@mozilla.com at Sun, 09 Apr 2017 20:46:31 +0000
No bug, Automated HSTS preload list update from host bld-linux64-spot-325 - a=hsts-update
7267adcbaa1c04110fc2b0436b933472c7b57200: 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 559324
Push 53055 by mozilla@buttercookie.de at Sun, 09 Apr 2017 20:38:11 +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
3c7fa0d6ee3e738e38fad38f22eae75a630dadfb: 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 559323
Push 53055 by mozilla@buttercookie.de at Sun, 09 Apr 2017 20:38:11 +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
697b351551479df9d8821c45bf0ac83bfe890a8f: 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 559322
Push 53055 by mozilla@buttercookie.de at Sun, 09 Apr 2017 20:38:11 +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
96c3333bcb6b75c93d85a03fb0eac7dba23b7ba5: 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 559321
Push 53055 by mozilla@buttercookie.de at Sun, 09 Apr 2017 20:38:11 +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 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 caring about the hash 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 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
2fc77aba52828c165a8b41fb05ad280391619e18: 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 559320
Push 53055 by mozilla@buttercookie.de at Sun, 09 Apr 2017 20:38:11 +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
547894d33f6da1ffb0ab46079f907f618848dc61: 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 559319
Push 53055 by mozilla@buttercookie.de at Sun, 09 Apr 2017 20:38:11 +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
cf5fbee90c9464fe7dc3aa01b98c3228d5071aca: Bug 1354820 - Idle unloader shim prototype. draft
Andrew McCreight <continuation@gmail.com> - Sat, 08 Apr 2017 08:17:50 -0700 - rev 559318
Push 53054 by bmo:continuation@gmail.com at Sun, 09 Apr 2017 18:17:02 +0000
Bug 1354820 - Idle unloader shim prototype. MozReview-Commit-ID: H68wAplJgQo
51cdc417d448d6c9a485ac243f1ea60e4185912c: 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 559317
Push 53053 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:51:01 +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
355c36c8718e8979a39a09059b26b53c6480360e: 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 559316
Push 53053 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:51:01 +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
ca96aa99606d3c060440cc8f699e06fd7443dcde: 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 559315
Push 53053 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:51:01 +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
d7f7e91cf86dc5838b2d4d4b88b38e95b0ed8a7a: Bug 1352997 - Part 6 - 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 559314
Push 53052 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:43:38 +0000
Bug 1352997 - Part 6 - 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
d6687dfa2309631f05517f4257c71eaa2642da36: Bug 1352997 - Part 5 - 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 559313
Push 53052 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:43:38 +0000
Bug 1352997 - Part 5 - 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
5ada740a21ffbaca7bb1cb2098217bf84dca5d45: 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 559312
Push 53052 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:43:38 +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
df1d993be4bb6c55fca74c928428b701d6729b04: 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 559311
Push 53052 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:43:38 +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 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 caring about the hash 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 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
d1ecda7ca51eaafccdf962b82cc1586e922dcfaa: Bug 1352997 - Part 6 - 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 559310
Push 53051 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:35:56 +0000
Bug 1352997 - Part 6 - 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
ec7a7bcb41dd1b5b6d748793f0b8b11e708af9c9: Bug 1352997 - Part 5 - 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 559309
Push 53051 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:35:56 +0000
Bug 1352997 - Part 5 - 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
c4cebf4e7451a3d262ffa474d6d912f672924971: 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 559308
Push 53051 by mozilla@buttercookie.de at Sun, 09 Apr 2017 17:35:56 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip