50de746d569e9ca6b4eaa24dcbd44e0401377bd6: Bug 1351808 - Part 1 - Replace some magic numbers in session store. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 14:18:23 +0200 - rev 569840
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r=sebastian MozReview-Commit-ID: BzqieZVi7h4
7e3ac5b323e74f3a3acc56718812f1eef0548306: Bug 1352997 - Part 7 - Don't switch activities if we're closing a tab while exiting the activity. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 14 Apr 2017 19:58:09 +0200 - rev 569839
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1352997 - Part 7 - Don't switch activities if we're closing a tab while exiting the activity. r=sebastian,walkingice Closing the currently selected tab will select another tab, which can trigger an activity switch if the tab types differ. We don't want that if we're about to close the activity, as that'll bring that activity into the foreground instead of simply walking back along the activity history stack. To give an example: Without this patch, closing the last custom tab will select a normal browsing tab, which will trigger an activity switch, so instead of returning to the user's previous activity, pressing back will send us to BrowserApp. There's one additional catch: If we change our onDone() behaviour and no longer finish() the SingleTabActivity when exiting (in order to avoid a costly restart of Gecko should the user return to us soon), this means that the activity that has just been exited could be brought back into the foreground via the onResume() codepath. In that case the mLastActiveGeckoApp-check won't be triggered if no other GeckoApp-based activity was active in the meantime, so we wouldn't reselect/reopen the activity's desired tab, but instead display the tab that was selected when closing the previous tab. Therefore, we track this via an additional flag that is set for this case. MozReview-Commit-ID: 3jOvBXQUrfo
a977e2d9610eba8b5cfd5b6bfd6e0a5f007d2985: Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 569838
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r=sebastian,walkingice 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
86c1de1e154e4613fea830a60c3dd9e4239021a2: Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:19:32 +0200 - rev 569837
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. r=sebastian,walkingice 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. This also means that we no longer have to finish() the activity on closing so the activity state (finished) matches the tab (closed), which means that we no longer have to prematurely kill Gecko as a side effect of that. MozReview-Commit-ID: KjFz1qrqWLy
5e3f399d311eba9ee492d2e5310792042071d1fd: Bug 1352997 - Part 4 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:15:19 +0200 - rev 569836
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1352997 - Part 4 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r=sebastian,walkingice 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
674241dce78bb84e5b07849f2be78a8705a92e27: Bug 1352997 - Part 3 - Re-implement tracking of last selected tab for BrowserApp. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:55:10 +0200 - rev 569835
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1352997 - Part 3 - Re-implement tracking of last selected tab for BrowserApp. r=sebastian,walkingice 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
49f48bd6b958ee159030067990eaa8eb804e892f: Bug 1352997 - Part 2 - Provide dedicated methods for typical homepage operations. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 09 Apr 2017 19:30:21 +0200 - rev 569834
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1352997 - Part 2 - Provide dedicated methods for typical homepage operations. r=sebastian,walkingice 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
29dc2947feaf37346d10b26be0e62121932a8d96: Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 11:16:13 +0200 - rev 569833
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r=sebastian,walkingice 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
f4258202a88d49a37a5ba22f2e5f36b4ca4396b1: Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 15:43:31 +0200 - rev 569832
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r=sebastian,walkingice 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
2b2265a57f4c7c2d19ca5cc720620c95ef94b87b: Bug 1351739 - Part 5 - Implement activity switching for web apps. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 18:26:45 +0200 - rev 569831
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part 5 - Implement activity switching for web apps. r=sebastian,walkingice 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
d8afa0011e06be5eaf50c3bbb9064172bb5f934f: Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 09 Apr 2017 19:49:02 +0200 - rev 569830
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r=sebastian,walkingice 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
6881d81cd2a3695c9f8eb7f3c92ac257f5afaa31: Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 23:10:51 +0200 - rev 569829
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r=sebastian,walkingice 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
cec16c86471f5d7519ad5b7acdd2472c65a5dfb7: Bug 1351739 - Part 2 - Convert CustomTabsActivity to SafeIntents. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 14:09:36 +0200 - rev 569828
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part 2 - Convert CustomTabsActivity to SafeIntents. r=sebastian,walkingice These are potentially untrusted external intents, so we should use SafeIntents for interacting with them. MozReview-Commit-ID: 3nmjg85wbr1
3d9e6fe1d43a1fcc94d0c414c432e91d221f5666: Bug 1351739 - Part 1 - Track the currently active activity. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 11:22:12 +0200 - rev 569827
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part 1 - Track the currently active activity. r=sebastian,walkingice Required because later on, we'll need to know if we're in the correct activity for a tab or need to switch activities. As a follow-up, we can later also hook up our current manual activity tracking from GeckoApplication to this (we most probably won't be able to get rid of the GeckoActivityStatus shenanigans, though). MozReview-Commit-ID: 5lZrAMsB9Gy
732aac065f98d46bf9a515cb447b826aeaa7fc03: Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 06 Apr 2017 21:30:55 +0200 - rev 569826
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r=sebastian,walkingice -1 is probably not all that mysterious as far as magic numbers go, but still... MozReview-Commit-ID: zK3P6HeWzK
afc8f75142512920c5a3d22de6e13b8c8f790f06: Bug 1351739 - Part -1 - Housekeeping. r=sebastian,walkingice
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 07 Apr 2017 20:51:41 +0200 - rev 569825
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1351739 - Part -1 - Housekeeping. r=sebastian,walkingice MozReview-Commit-ID: Ev6jl4N3K0g
5a2d5f57d4538291ba3be13fde54b3cb629cf596: Bug 1360152 - null-check correct value in ToDisassemblySource; r=froydnj
Tom Tromey <tom@tromey.com> - Thu, 27 Apr 2017 07:29:09 -0600 - rev 569824
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1360152 - null-check correct value in ToDisassemblySource; r=froydnj MozReview-Commit-ID: 3HR4ZofDlyW
36591b6a2827066ef80351bb3176de7eb8bea52f: servo: Merge #16635 - Too many revalidation selectors (from bholley:too_many_revalidation_selectors); r=emilio
Bobby Holley <bobbyholley@gmail.com> - Thu, 27 Apr 2017 13:14:01 -0500 - rev 569823
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
servo: Merge #16635 - Too many revalidation selectors (from bholley:too_many_revalidation_selectors); r=emilio https://bugzilla.mozilla.org/show_bug.cgi?id=1358693 Source-Repo: https://github.com/servo/servo Source-Revision: 2c445169ad7ccf0e4b2be8f1eee2e198c54ee666
dd7a3a0608d7882a03ace1c8d245c0a95fd04c41: Bug 1359704 - "page" context items should not appear in "tab" context r=mixedpuppy
Tomislav Jovanovic <tomica@gmail.com> - Thu, 27 Apr 2017 15:59:32 +0200 - rev 569822
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1359704 - "page" context items should not appear in "tab" context r=mixedpuppy MozReview-Commit-ID: 9Lz8ZzzbNhq
cd0632c4d21fd3d9513f1007e7df0bb8dd6a20a3: Bug 1357846 - Remove some dead code which triggers errors at sandbox level 3 r=baku
Alex Gaynor <agaynor@mozilla.com> - Thu, 27 Apr 2017 10:30:30 -0400 - rev 569821
Push 56287 by hikezoe@mozilla.com at Thu, 27 Apr 2017 23:13:58 +0000
Bug 1357846 - Remove some dead code which triggers errors at sandbox level 3 r=baku This code only became dead very recently; in the first patch improving this issue (which fixed an underlying issue with the code, but not the tests). r=baku MozReview-Commit-ID: 3QP5LrNPstJ
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip