To make sure these functions can be used in robocop test.
MozReview-Commit-ID: KPAKOrg5Ows
--HG--
extra : rebase_source : 13632cef16c96457ce77c01bc4330a9793ab83ad
Add check for media notification's small icon, title and content text.
MozReview-Commit-ID: AOhag8gQVqs
--HG--
extra : rebase_source : 2be27f95b2bc48b998734d8e702fc084b5b93683
It's easy to know what test tasks we'll run in this test.
MozReview-Commit-ID: DdtFp4pOXlC
--HG--
extra : rebase_source : 9c986e6104528cb66cc6ca3b468fe49031e637db
Create new test class for reducing the redundant code and can provide more
flexibility for adding new related test in the future.
MozReview-Commit-ID: 2f3O8vfHo12
--HG--
extra : rebase_source : 02e081dbac6e91bcac92bea1dbfc5abf07293e40
Notify observer might cause the method (notifyStoppedPlaying) is called by C++ side,
and we should change our internal state before calling the method.
MozReview-Commit-ID: 5xNXhGmAIrR
--HG--
extra : rebase_source : 23fb8bef4066cad5238f49bb692445d9b684a84e
Otherwise random stuff handled by GeckoApp (e.g. snack bars) won't work inside a WebAppActivity.
MozReview-Commit-ID: ElGOPQcqFJS
--HG--
extra : rebase_source : 71fe7c966513772701cd792c0bec1211c0d9e5e6
When there's no more history to go back in an externally opened tab, we background the activity and close that tab. This means that some other tab gets selected instead, which could in theory trigger an activity switch if that tab is of a different type.
Because we're leaving the app, we don't want to actually launch a new activity, so now the currently selected tab might not match the last active GeckoApp (e.g. closing the last open Web App tab will select a normal tab). Therefore if the same activity is subsequently resumed again, we need to run the restoreLastSelectedTab() even if the "last active GeckoApp"-check doesn't trigger.
For BrowserApp however, this can conflict with session restoring/startup tabs/tabs opened from intents, because in that case we're going to select some other tab, anyway. We already ignore the "last selected tab within this activity" check when doing a full startup, so now we extend this behaviour to cover tabs loaded through onNewIntent() as well.
MozReview-Commit-ID: IDistdhwuZ5
--HG--
extra : rebase_source : d5404326e2cd4ce44a14340883dd338d14a18c05
Looking again, the original motivation for *not* calling finish(), i.e. avoiding Gecko being unloaded from memory, doesn't quite seem to apply and in any case for custom tabs we *have* to finish() the activity, since we're most probably running within another activity's task.
There's also no point in overriding onDone() in SingleTabActivity any more if
- we just do the same thing as GeckoApp's default behaviour, and
- custom tabs now require a different behaviour anyway.
MozReview-Commit-ID: BsP1tMj5DEe
--HG--
extra : rebase_source : bd3dc71ec1a5d4dcbf83e6c00630e0d8ab04f611
I encountered crashes in jitted regexp code in my AArch64 Fennec build.
This patch disables that for now, but obviously we want to look into the
crashes and eventually turn this back on.
Update tooltool manifests for official builds to use repacks
of the upstream rustc 1.17.0 (56124baa9 2017-04-24) stable release.
These repacks include cargo 0.19.0-beta.1 (03efb7fc8 2017-04-23)
to include support for the RUSTC_WRAPPER environment variable
needed for use of sccache with rust code.
MozReview-Commit-ID: L9Nq2iK4GK8
--HG--
extra : rebase_source : 882b201282a0e13ed77ec5876972657eab81a562
Add two tests to testInputConnection that record the sequence of
composition events during editing, and check that the sequence is what
we expected.
The first test makes sure that we reuse the current composition on the
Gecko side when setting composing text; otherwise the Facebook comment
box behaves incorrectly.
The second test makes sure that we can move the cursor inside the
current composition, to fix this particular bug.
* Include the type of the editor (input, textarea, contentEditable,
designMode) in BasicInputConnectionTest, so we can work around the
differences in behavior among the different editor types.
* Add timestamps to key events, because lack of timestamps was
triggering a crash when running testInputConnection.
Update the composition when setting/removing spans, so that we update
the selection/cursor during a composition. However, we must limit any
updating to the current composition only (as indicated by the
keep-current-composition flag), because the Facebook comment box behaves
incorrectly if we repeatedly start and end new compositions.
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 : 4cee7d97a66e4c6f193547df019335db4443f45a
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 : 9d2b25997e0f71089c0ef56c0069cafe068f821e
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
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
--HG--
extra : rebase_source : a535fff92c02ef9d711faf6083e9146ed992fc03
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
--HG--
extra : rebase_source : 3f8cf1e2e96889313ef83ad9ba92b7a36985b82a
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
--HG--
extra : rebase_source : 188fd2275083ddb982af806d4660c02caab85bee
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
--HG--
extra : rebase_source : 6ff06fb1e1405201908ade4b04eba54a1a5aa7d5
Nevin Chen
Alastor Wu
Jan Henning
Jim Chen
Sebastian Hengst
Eugen Sawin
Ralph Giles
Randall Barker
Carsten "Tomcat" Book
Andrzej Hunt
Wes Kocher
Geoff Brown