Per bug 1363811 comment 1, it's actually a bug that the linter doesn't
complain about it like it did in bug 1358215.
--HG--
extra : rebase_source : 68f0d022fb4f2c4e2de38edbafa314db42b7e103
UAOverridesBootstrapper.js is introduced to delay the initialization of
UserAgentOverrides.jsm until the creation of the first nsHttpChannel.
Uninit will be triggered at profile-change-net-teardown because no network
traffice after this point.
MozReview-Commit-ID: F8Lpn6RyZEm
--HG--
extra : rebase_source : 7c3649b50ad8594dc0968961fbbd2766d0d98b0a
That is if the currently selected tab has a web app or custom tab as its "parent tab", we'll ignore that fact when the tab is closed from the tabs tray, so we don't trigger an activity switch that way.
MozReview-Commit-ID: 7bOi90RQUhA
--HG--
extra : rebase_source : 5c658818bc0cf7b1ace0da7b6d306146ac3cf2b6
robocop_autophone.ini
- it's used to test Adobe Flash issue only
robocop_autophone2.ini
- it's used to test other kinds of Robocop tests
MozReview-Commit-ID: KPniwy7rLJm
--HG--
extra : rebase_source : a82f7845b945a70da11587aec8acf78fc880cc8b
configuration: Nexus 5 + Android Hammerhead 5.1.1 LMY48M
In CustomTabsActivity, the menu reload-button use a LevelListDrawable.
On some configurations, icon's state won't be set to Enabled by system, hence
the color of icon is incorrect. We have to enable it manually.
MozReview-Commit-ID: JB9t35OyatY
--HG--
extra : rebase_source : e0750f6b76ea25a6abcb5d1375aa1468522f0da4
Properly clearing data (history etc.) when shutting down via "Quit" can introduce a possibly noticeable delay (up to the order of a few seconds in bad cases) before the UI actually closes. This patch shows a snackbar for this case, so we don't give users the impression of simply randomly hanging during shutdown.
MozReview-Commit-ID: AqYw8qK8xol
--HG--
extra : rebase_source : 3a1f650dd27ef07ec7eb21dc511decbd94c0a99c
The "platform" chrome flag requires an irrelevant "content" chrome
manifest entry, while it's only used for locales. It only has exactly
one use, which can actually be replaced by uses of the "os" flag.
Note, we're doing something similar with the "os" flag for skins in
e.g. browser/extensions/pocket/jar.mn.
Unfortunately, for determinism reasons, the chrome manifest entries from
jar.mn are sorted (per bug 982075), so keeping global-platform/unix
would leave it appearing after /mac, and would override it on mac
because of the lack of "os" flag on the /unix entry (we can't put "os"
flags on that entry because we can't do something like os!=Darwin &&
os!=WINNT). So we move it to /gtk such that it always comes before /mac.
--HG--
extra : rebase_source : aaace8147ea54f74aef8a7b2314ad022e9f9be23
Remove the addPluginView and removePluginView methods from
GeckoInterface. Instead, move the JNI calls directly to GeckoApp itself.
GeckoApp then uses GeckoActivityMonitor to find the current activity,
instead of using GeckoAppShell.getGeckoInterface().
MozReview-Commit-ID: 7ym8kuElADV
There are two callers of isOfficial() in GeckoThread. For purging the
startup cache, the code to add the extra argument is moved to
GeckoApplication/GeckoApp/GeckoService. For logging the arguments, the
"debug" flag is used instead of the "official" flag.
MozReview-Commit-ID: 9atEWY1MVVt
Use available Context or GeckoActivityMonitor to derive an Activity
instance, instead of using GeckoInterface.getActivity().
MozReview-Commit-ID: GHLMtnQkr2l
Since we only support one profile per process, replace all calls to
GeckoInterface.getProfile() with calls to GeckoThread.getActiveProfile().
MozReview-Commit-ID: 9PZOoBZt7Er
This intentionally allows to set MOZ_INSTALL_TRACKING without
reference to the milestone being release or beta. That is, we
separate the default value (which depends on release or beta) from the
value specified, making life easier for developers.
MozReview-Commit-ID: 3vPF7KO7fEX
--HG--
extra : rebase_source : 8d5764104b5322a32e4a048bfd3222f62fed73bb
This allows us to allocate an Android SurfaceTexture in the compositor process as well
as an accompanying Surface. We can then transfer the Surface back to the content process
via binder, where it can be used for things like WebGL and video decoding.
Each SurfaceTexture/Surface pair has a unique handle. We use this handle in
layer transactions to locate the SurfaceTexture for a given Surface and composite it
appropriately.
MozReview-Commit-ID: 68VSbXdfsMH
After bug1364202, we should use checkIfMediaPlayingSuccess(), checkTabMediaPlayingState()
or checkTabAudioPlayingState to check the tab's state, because these methods use
waitForCondition() instead of the EventExpecter.
If the test file is audible, we could use checkIfMediaPlayingSuccess() because
it would check both "media playing" and "audio playing" states.
If the test file is non-audible, we should use checkTabMediaPlayingState() to
ensure the media started playing successfully.
MozReview-Commit-ID: 6kOiglHBwch
--HG--
extra : rebase_source : 931d0e24ee0946e9e61bd987be06ea7353a1e507
This allows us to allocate an Android SurfaceTexture in the compositor process as well
as an accompanying Surface. We can then transfer the Surface back to the content process
via binder, where it can be used for things like WebGL and video decoding.
Each SurfaceTexture/Surface pair has a unique handle. We use this handle in
layer transactions to locate the SurfaceTexture for a given Surface and composite it
appropriately.
MozReview-Commit-ID: 68VSbXdfsMH
GeckoAppShell.scheduleRestart was called from XPCOM toolkit when we
needed to restart after the Gecko thread exits. But because we made the
"Gecko:Exited" event contain a "restart" flag, we can handle that
entirely in Java now, so we don't need to call
GeckoAppShell.scheduleRestart anymore.
Move the code that actually performs shutdown from BrowserApp to
GeckoApplication, so we can shutdown even without an active BrowserApp.
From inside GeckoApp/BrowserApp, all shutdown now go through
finishAndShutdown(), which destroys the Activity before shutting down.
Add test for handling the cases, media with silent audio track and media without audio track.
MozReview-Commit-ID: 5vV9EjIjHQt
--HG--
extra : rebase_source : 37fccc055479a40fd802107ccdc45d11d11c1852
When a non-restartless add-on is (un)installed or updated, we show a doorhanger prompting the user to restart. Currently, the doorhanger's title is using the default logic for choosing its title, that is using the base domain of the tab the doorhanger is being displayed on.
By chance, when the doorhanger is triggered from about:addons there is no domain to display, so the doorhanger is just displaying the restart notification. If however an add-on is automatically updated while the user is browsing, then the restart prompt will show the domain of the currently open tab in conjunction with the restart message. This can be confusing for the user, as it looks like it was in fact the current page that triggered the restart prompt.
Therefore, we change this behaviour and just show a generic "Add-ons" as title for this case.
MozReview-Commit-ID: 3pMwSiLul99
--HG--
extra : rebase_source : 3c11fe19c5cef42226a849b78d554fa846114bfa
At the moment, our crash loop counter that turns off session restoring when multiple crashes happen in a row is reset only after a successful background-foreground cycle.
Since its purpose is to break out of startup crash loops caused by the currently loaded tab that is automatically loaded after starting the app, it makes sense to also reset it if we didn't crash soon after starting up. Otherwise, if the user remains within Firefox, another crash long after starting would still count towards the crash loop counter.
Desktop already employs a similar logic for deciding whether to automatically enable safe mode or not after a crash. Therefore, we use the same amount of time (30 s) after starting Gecko for resetting the counter.
We also take the opportunity to make our logic a bit more conservative and only turn off session restoring after two successive crashes in a row (desktop uses 3 by default).
MozReview-Commit-ID: CQDutkDgmfc
--HG--
extra : rebase_source : e3100394772bcebb64610dcadfd77676119e1de1
Those settings need to be stored in our shared preferences since they're needed before Gecko is available, however in order to allow them to be easily configured, we also expose them in about:config and sync them to the shared prefs via a change listener.
This however means that changes in the *default* value of those prefs won't be picked up. Therefore we now simply unconditionally copy the setting state into the shared preferences on startup and omit the change listener instead, as they're exposed in about:config only and there is in fact no pressing need for changes there to immediately take effect.
MozReview-Commit-ID: 7c950F1nkdj
--HG--
extra : rebase_source : 4be6e5124294a71b5d214b9ab10ada4e88aee3bb
I observe that sometime it takes longer time for the UI notification changed in
try sever, and it cause the intermittent fail.
Therefore, I would like to increase a little bit time for waiting UI changed.
MozReview-Commit-ID: BnsZq3DObFa
--HG--
extra : rebase_source : 034f38799a2f9722f23bb0a2a139047d21508729
Use notification id to check whether the notification is correct is more stable than just checking the
number of system notification.
MozReview-Commit-ID: BVYdMrBsSLR
--HG--
extra : rebase_source : 9be3ca9a854c25a61bf233a24e7ed7745efacb1a
Since the robocop tests would run on super slow emulator on try, and then we
can't wait the tab's audible state change within the MAX_WAIT_MS time. It might
need more time.
So, we should check the media has been started by waiting the "Tab:MediaPlaybackChange"
event, and then to check other tab's attribute.
In addition, move the tab attribute checking independently into new functions,
so that we would clearly see that we have four things need to check in function
checkIfMediaPlayingSuccess().
- tab's media playing state
- media notification UI
- tab's audio playing state
- audio focus state
MozReview-Commit-ID: 8S0Ems23iPX
--HG--
extra : rebase_source : 9bbe525ba1dcdf8415d034ced39d9a9a4836f1e9
To make sure these functions can be used in robocop test.
MozReview-Commit-ID: KPAKOrg5Ows
--HG--
extra : rebase_source : 8ef6dd7c14e8dc0d3219aed0901793a17f945372
Add check for media notification's small icon, title and content text.
MozReview-Commit-ID: AOhag8gQVqs
--HG--
extra : rebase_source : 8ad1c7fa0e7796a0d873fba432c646846a0742d3
It's easy to know what test tasks we'll run in this test.
MozReview-Commit-ID: DdtFp4pOXlC
--HG--
extra : rebase_source : 5615d2c1169ee0f59c95ab21d3e5e2fd26c99a33
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 : 2b0d7a337c87afd8e844f435f7e605b881f1aa1b
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 : 362f921e68d795f568816b1c0a23c0f50c5d0790
When starting up, ideally we want to only load the foreground tab, with all other tabs being created as delay-loaded "zombie" tabs that occupy minimal resources. To that extent, when restoring the previous session we need to know whether we're planning to open an additional, external tab for a URL received through the launch intent later on. If we do, we don't want to select any tab while restoring the previous session, as that selection is going to be overridden by the external tab anyway. Not selecting a tab from the previous session at this stage means that it can remain as a delay-loaded tab until it is eventually selected by the user.
MozReview-Commit-ID: 1lWnOx0ZuNl
--HG--
extra : rebase_source : 03a286ec3e1c66856d2ffb526cd4277c89b29594
MediaCodec supports async callbacks since Lollipop. Buffer polling is no longer needed.
MozReview-Commit-ID: Iov65JI86i8
--HG--
extra : rebase_source : c3b0ed330e46ee2328de4d031c96f9792895c3b5
This allows us to allocate an Android SurfaceTexture in the compositor process as well
as an accompanying Surface. We can then transfer the Surface back to the content process
via binder, where it can be used for things like WebGL and video decoding.
Each SurfaceTexture/Surface pair has a unique handle. We use this handle in
layer transactions to locate the SurfaceTexture for a given Surface and composite it
appropriately.
MozReview-Commit-ID: 68VSbXdfsMH
Video fails to play on Sony Z3C when the media server is in a state that no hardware codec can be created unless reboot. Fallback to software codec when that happens to workaround the issue.
MozReview-Commit-ID: AaRIw7KPaF3
--HG--
extra : rebase_source : d5106d5c75c4430450a81bbe9cfd536f01ef4df9
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
--HG--
extra : rebase_source : 477ef683f850ff11cfa128e17855666bb7758a7a
For static final fields, generate a getter instead of a literal when
specified. Used to generate bindings for runtime constants whose values
are unknown at compile time.
The Java Addons mechanism never got traction and is not Web Extensions
compatible. Removing it simplifies the product and the build system.
MozReview-Commit-ID: ABUxkqqMISa
--HG--
extra : rebase_source : 346f88882774f072316714cf637a54d771d81a9a
This will avoid conflicts with the ActivityStream helper class.
MozReview-Commit-ID: 5XNmwz4UwJo
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/home/activitystream/ActivityStream.java => mobile/android/base/java/org/mozilla/gecko/home/activitystream/ActivityStreamPanel.java
extra : rebase_source : 23000ae152f776de874053c712fb6e1a4b1ab546
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
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.
Ryan VanderMeulen
Wes Kocher
cnevinc
Mike Hommey
Matthew Wein
Shih-Chiang Chien
maliu
Jan Henning
Sebastian Hengst
Alastor Wu
Iris Hsiao
Jim Chen
Julian_Chu
Michael Kaply
udara
Carsten "Tomcat" Book
Nick Alexander
Ben Kelly
Randall Barker
James Willcox
Honza Bambas
Jonathan Guillotte-Blouin
James Cheng
Ted Mielczarek
Jing-wei Wu
Tom Klein
Mark Banner
Dale Harvey
Gijs Kruitbosch
John Lin
Paolo Amadini
Dylan Roeh
Mats Palmgren
Jonathan Hao
Andrzej Hunt
Edouard Oger
Nevin Chen
Eugen Sawin
Ralph Giles
Geoff Brown
Alexandre Poirot
Andrea Marchesini
Mike Conley