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
--HG--
extra : rebase_source : a7409f58b8df1f32f74b137513ece1e162605280
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
--HG--
extra : rebase_source : 184240fc79678a2e78d7052635acc4b836fce400
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
--HG--
extra : rebase_source : d08216a7a73b2f372b2357326e5c9d6de622c4d9
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
--HG--
extra : rebase_source : cfed1b6069409efe2444131c41db1ae2e828c43a
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
--HG--
extra : rebase_source : 4997207d048924518870852d40cfc1fed233fab1
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
--HG--
extra : rebase_source : 81db83e79d31cf6398f449bba14a4fb1bdc97810
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
--HG--
extra : rebase_source : 6487f39a697a500d3a3eda505345f72f755bcbb7
These are potentially untrusted external intents, so we should use SafeIntents for interacting with them.
MozReview-Commit-ID: 3nmjg85wbr1
--HG--
extra : rebase_source : 97c54e1dee8fc132aa3bb1d9c42051a4eb330018
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
--HG--
extra : rebase_source : 5a8fec92cad15db05063dbb940874615c317c768
-1 is probably not all that mysterious as far as magic numbers go, but still...
MozReview-Commit-ID: zK3P6HeWzK
--HG--
extra : rebase_source : 59530eafb11f68fddb29a53775a394fcd1a08d69
We only want to process the AppEntered/Left message if it actually concerns our currently displayed tab.
MozReview-Commit-ID: EJ8RzRzDNAz
--HG--
extra : rebase_source : 2d05c8131a3b25968b36704647a9041b15599668
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
--HG--
extra : rebase_source : 150e61f2a205e6bc6ea6cf346de0ba42b1935d13
Similar to some previous commits, we prefer non-throwing constructors
in order to ensure we never lose a reference to an unclosed stream.
InpuStreamReader(..., Charset) is preferred over InputStreamReader(..., String)
since the latter can throw when the String is not a valid Charset.
(In reality we know that our Charset Strings are correct, but the compiler
isn't able to determine that for itself. Moreover, using the preparsed
Charset is more efficient.)
MozReview-Commit-ID: 9z07G3hqPI3
--HG--
extra : rebase_source : 6ed740bf5a1e5296bd2afe5c58b19a43acab0647
The primary issue is that we use a throwing InputStreamReader
constructor. If it throws, then any nested streams will be lost.
We can fix that by using the non-throwing InputStreamReader
constructor (which uses a Charset as the second parameter,
instead of a String which causes an Exception to be thrown
if it can't be parsed)
We also simplify some nested Stream's a little: most of the
Stream constructors don't throw, so there's no harm in not keeping
individual references to those that don't throw - and that
results in less Stream references for us to handle.
MozReview-Commit-ID: 2hyRFGVmGnU
--HG--
extra : rebase_source : 15dd97d28012a017326b01ae8ddc370c7f1ec484
MergeCursor can handle null cursors (and is lightweight), we
don't need to specifically handle each case - which results in simpler
code.
MozReview-Commit-ID: CGwMi9LKYTj
--HG--
extra : rebase_source : 74c0c83ba4e8ea6ca036c24372ee7ff07a1cbc78
On a CLOSED TREE
Style varies across the tree, and this matters as we transition to
Python and moz.build. AppConstants.jsm already uses #ifdef, so this
is consistent with that.
MozReview-Commit-ID: Bal37lqlvjq
--HG--
extra : source : 41d155de1019c0c6c693e2bf46bd1dd7b91d244a
extra : amend_source : 989f6ba2447a2b40d4bc6604241d7986c0d5dd00
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
We can lower the eslint cyclomatic complexity threshold in some directories without adding eslint suppression comments in any .js source files. We need to specify the complexity rule in accessible/.eslintrc because it doesn't inherit the mozilla/recommended rules. eslint's default complexity threshold is 20.
Also bump the eslint-plugin-mozilla version because we modified the mozilla/recommended rules.
MozReview-Commit-ID: 57T4gAjPH7z
--HG--
extra : rebase_source : 4565abfa722b9459cfb4e006e843da13ed7cffd4
extra : intermediate-source : 658588564c08c9fd5e60633d1457f24087de8570
extra : source : 7e0526e3b943419a80c0cd2fa462cabbf8925eb1
The method Context.getDrawable was introduced in API 21. To be
compatible with Kitkat, should use Resources.getDrawable instead.
MozReview-Commit-ID: 1ZajYWPTVj0
--HG--
extra : rebase_source : d9aa89d3cae5040b861cc6c07f2a2461fab4ce82
This patch replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
This commit adds a robocop test that traverses all the settings
screens except the 'Make default browser' one.
MozReview-Commit-ID: LqWrFL9v877
--HG--
extra : rebase_source : 2e7f5e1887ace438f948b49f6515e1d732ad8aa2
This was just an error that's not obvious on try builds. We were
using local paths ($(DEPTH) expands to ../../../ in
mobile/android/base) and GENERATED_FILES produces targets with
absolute paths.
MozReview-Commit-ID: LDhh6mcgSD6
--HG--
extra : rebase_source : be0cf0c41873871082c640d051ead748746eb78c
Not handling the appropriate configuration changes means that e.g. each rotation destroys and recreates the CustomTabActivity, which'll introduce a slight delay until we eventually repaint the web content.
As for the soft input mode, if we don't specify adjustResize, then the IME might actually simply overlap our window and obscure the end of content if the user has already scrolled down as far as possible.
MozReview-Commit-ID: BzBmIoGbhca
--HG--
extra : rebase_source : 8746621d8fec712e37aac4efdd76da6b0c3b396f
Update tooltool manifests to reference rustc 1.16.0 stable repacks
which include cargo 1.19.0 nightly builds from 2017-04-19 which
support the RUSTC_WRAPPER environment override.
We're shipping with an unstable cargo while this feature makes its
way to release because it is necessary for deploying sccache support
for rust language code in our build and test automation.
MozReview-Commit-ID: Iow2894OPq7
--HG--
extra : rebase_source : f1a8e6cab612714f7b73ca8a14d14cabe9f4aef7
The experiment in Switchboard is "full-bookmark-management", and it's enabled for 100% of the Nightly audience.
MozReview-Commit-ID: EhA0BcouPPn
--HG--
extra : rebase_source : beeddc921a089606d8a752b75c3a0280a1803972
Every single caller of getAppEventDispatcher() and getEventDispatcher()
assumes a non-null return value, so let's make sure we're actually returning
a non-null value. This commit doesn't effectively change runtime behaviour
(any previously NPE crashes will now result in a crash due to IllegalStateException),
however we now at least have an obvious error message in that situation.
In reality, no code should run before onCreate(), so this should realistically
never happen - but we should still check to ensure that is the case.
(This removes 28 infer NULL_DEREFERENCE warnings.)
MozReview-Commit-ID: GhzwKWfkAbD
--HG--
extra : rebase_source : f6b13f590b437ebb63e502f774a70164054ecf7e
Style varies across the tree, and this matters as we transition to
Python and moz.build. AppConstants.jsm already uses #ifdef, so this
is consistent with that.
MozReview-Commit-ID: Bal37lqlvjq
--HG--
extra : rebase_source : 8e4e459a9bdbc3a2cacde728f45e6edecc272e24
That pref isn't set by default, so trying to access it in that case throws a JS error.
MozReview-Commit-ID: 2KIUSztvoXS
--HG--
extra : rebase_source : b2769ba16247db9373c004f152c0e2233fb0652d
Jan Henning
Sebastian Hengst
Wes Kocher
Michael Kaply
Alexandre Poirot
Edouard Oger
Nevin Chen
Andrzej Hunt
Nick Alexander
Andrea Marchesini
James Willcox
Carsten "Tomcat" Book
Randall Barker
Dale Harvey
Mike Conley
Chris Peterson
Iris Hsiao
Julian_Chu
Ehsan Akhgari
Eugen Sawin
brainbreaker
Jing-wei Wu
Ralph Giles
Munro Mengjue Chiang
Tom Klein
Matthew Wein