Restoring a tab from the Recent Tabs panel, which goes via the session store's _restoreTabs() function and ultimately via BrowserApp.addTab() and a Tab:Added message back to the Java UI requires the value for isPrivate to be present in the session store data for the respective tab - if it isn't, we end up sending isPrivate as "undefined", which breaks the process of adding the new tab in our UI.
When the session store collects the full tab data for a browser, it always includes the values for isPrivate and desktopMode, therefore we now include those values in the basic session store data we use in initialising a new tab object, too.
MozReview-Commit-ID: 5BZ9PL7xDWA
--HG--
extra : transplant_source : %01%8B%E7%1Asg%FF%D8%DC%07%21Ly%F4%9A9Q%B9%00O
As seen in bug 1274273, the build system is running adb uselessly.
Moreover, on automation, adb doesn't even run, because it requires a
more recent glibc than available, adding confusing error messages to the
logs.
Note: this is currently an experiment, which was previousl de-facto disabled.
MozReview-Commit-ID: 3BfyMD6E3b3
--HG--
extra : rebase_source : 60513a9e78ab88c51f5c28f6ac8d26d0c52b72b7
extra : histedit_source : ff3c66aa8740df5c0fc873f60adb16819265a431
Switchboard might not have any data during onCreate, instead we should query
switchboard when actually deciding whether to show the prompt.
MozReview-Commit-ID: DdulFoWHiF9
--HG--
extra : rebase_source : 0f47a6ae7bccbe0b6ccd88396aa6467df9945ba6
extra : histedit_source : 092b80cf6b096b5b175c24f5d35377aecceaf168
The concept of "background data" (as it exists in the Android options menu)
doesn't exist in the Android APIs - I think it should be covered under
isConnected. Thus, I removed our `isBackgroundDataEnabled` method.
One other network consideration, however: we may want to consider stopping
uploads on roaming.
In the previous implementation, we did not queue the ping for upload if
the network was not connected (in order to conserve disk space). However,
this doesn't allow us to see all of the days the user interacted with
the device (e.g. for engagement) so in this implementation, we always
queue the ping and stop in the UploadService if we're not connected.
MozReview-Commit-ID: 1mjnHq3l7Jj
--HG--
extra : rebase_source : 4640aad21783f8e8edc568ea341a6e910a066d01
These values are what are actually used UI telemetry (perhaps because the enums were added after the strings?). They're also a little less obnoxious than the enum names.
MozReview-Commit-ID: K5i2Hr4DR4J
--HG--
extra : rebase_source : 5750fe71960616ad8014b473c6a5d99c2d3b2dc3
For pending push messages, we used to check for correct profile when the
message is received, but it's better to check for correct profile when
the message is delivered to Gecko.
This fixes a crash in headless mode that the previous patches
introduced.
This patch restores the previous behavior of restoring to guest mode if
Fennec is killed during a guest session. Instead of using a separate
lock file or an Intent argument, this patch uses shared prefs to keep
the guest mode setting.
The patch also introduces the behavior that, for headless mode, the
profile must agree with the guest mode setting. For example, in guest
mode, push messages under a regular profile will not be processed; this
is necessary to avoid profile mismatches.
Treat the guest profile as a custom profile with a special profile
directory. This lets us get rid of a lot of the guest profile handling
code. This patch does not attempt to restore to guest mode if Fennec is
killed during a guest session. A later patch will fix that behavior.
Patch renames GeckoProfile.getFromArgs to GeckoProfile.initFromArgs,
because the method now has possible side-effects (i.e. deleting stale
guest profiles). The new name also differentiates the method from the
GeckoProfile.get family of methods. initFromArgs now always returns a
profile (using the default profile if necessary), to make it easier for
its callers.
When getting a profile with a specific profile directory, we used to
require the directory to already exist. This patch makes sure the
directory is created if necessary. It lets us treat the guest profile as
an ordinary custom profile at a specific location.
This does a few things. First, it makes non-official builds use the
Adjust sandbox. Second, I observe that the fake sandbox key no longer
sends anything, so it's no longer valuable; this patch instead
requires an Adjust token if install tracking is enabled, since we
can't provide a default any more. Third, it removes a spurious
default in configure.in; without this default, builders can easily
enable Adjust locally using the following in their mozconfig:
ac_add_options --with-adjust-sdk-keyfile=/path/to/adjust-sdk.keyfile
export MOZ_INSTALL_TRACKING=1
With the default, the "export" had no impact, because it was
overwritten immediately.
MozReview-Commit-ID: Cn62fmrgwJL
--HG--
extra : rebase_source : 3b817c815043e0339e65125f6d6963ddd3f4570e
This patch changes two things:
* Check if the URL is http/https after stripping the about:reader URL.
* Always call updateAndColorTitleFromFullURL() as fallback for URL formatting (like in previous versions)
MozReview-Commit-ID: 1Zgf12FsOQe
--HG--
extra : rebase_source : d23c2d2d2392be9ae6e9fdaf8d560d5af07f387d
We were experimenting with this on phones, however we decided this
was unnecessary.
MozReview-Commit-ID: LSJILxFO3a
--HG--
rename : mobile/android/base/resources/drawable-hdpi/ic_menu_share_icon.png => mobile/android/base/resources/drawable-hdpi/ic_menu_share.png
rename : mobile/android/base/resources/drawable-xhdpi/ic_menu_share_icon.png => mobile/android/base/resources/drawable-xhdpi/ic_menu_share.png
rename : mobile/android/base/resources/drawable-xxhdpi/ic_menu_share_icon.png => mobile/android/base/resources/drawable-xxhdpi/ic_menu_share.png
extra : rebase_source : a889bf9e1faf5c3c894c28950e8ef7654f38fbb1
extra : amend_source : 130383a287249d0b67701b7d6a1815c7c88fbc5c
For privacy, custom search engines are "other".
MozReview-Commit-ID: GTM7d9k8JFZ
--HG--
extra : rebase_source : c7a1f8ba5694bb05680ea768110eb346dae91be0
This tells the app chooser dialog that appears when downloading a file to use the "Just once" button when two successive taps in a row on the same app have been detected.
MozReview-Commit-ID: Iejs1ROvt6n
--HG--
extra : transplant_source : %D3Y%C4%5D%DB%BC%26%C1Tr%8D%82%1Cmy%A5B%08g%D8
extra : histedit_source : e0e0eb9e7d0a64d86384515c2d93ac527d45e967
On newer Android versions, double tapping an entry in the app chooser is equivalent to tapping it once and selecting "Just once". To enable this functionality for our own app chooser when downloading a file, this patch enables passing a button index to the prompt dialog which will be chosen by default if a double tap has been detected.
To do this, we track the input value we receive in onChange. If we receive the same value twice in a row and a button has been configured, we close the dialogue and pass the result with that button back to the caller.
MozReview-Commit-ID: EVs2x3OtHmB
--HG--
extra : transplant_source : %85Td%83%0D%DD%D0%1D%F48a%5D%A0%CF%B4%A5%CE%5E%22%7E
extra : histedit_source : 190cf52e481b637172ea3b49ccec606f31dc86cf
Carsten "Tomcat" Book
Jan Henning
Bhavin Dave
Andrzej Hunt
Ray Lin
James Willcox
Mike Hommey
Michael Comella
Jim Chen
Cesar Valiente
guillaume
Victor Ng
Nick Alexander
Sebastian Kaspari
billel
Grigory Kruglov
Wes Kocher
Ryan VanderMeulen
bzrd_Sdn