We're now calling setIntent on the background thread. The onTargetSelected callback expects
to be run on the UI thread, and it looks like Android hangs up when we call UI methods
on the background thread. This in turn means the entire background thread gets locked up
(we execute tasks on the background thread sequentially) and no further background runnables
are executed. This breaks anything else requiring use of the background thread, e.g.
favicon generation, search, permissions doorhangers, etc.
MozReview-Commit-ID: CoYUOMqNX0m
--HG--
extra : rebase_source : 84a4dcc8a8aad590f02ba9f8d8b2564922787d17
In this patch, I move the telemetry server preference from app preferences
to per-profile preferences. We never allowed the user to set the preference
so this should cause no issues.
MozReview-Commit-ID: 7D5y58R2ejd
--HG--
extra : rebase_source : 3b4214968cac48150f6a3f873967cb43c7952b1b
Edge case: the admin profile can disable health report upload for themselves
but (I assume) the new profile won't automatically match these settings. While
I'm not sure if this is even possible, it's outside the scope of this bug.
MozReview-Commit-ID: 1SkXhL7B5xb
--HG--
extra : rebase_source : 95540b8b76f7014544022c7cb0880791ac536721
DB access happens deep in the internals of setting a new Intent for our
ActionProvider. Posting this to a background thread here seems to be the simplest
option to ensure correct threading.
MozReview-Commit-ID: 3iS8w5Cxf02
--HG--
extra : rebase_source : 48c90e5fa47a470d3360dbd44dc97111aac5ff3e
It's possible there are more UI-thread DB accesses lurking. To avoid maintenance burden
we should therefore enable this assert only in debug builds - releases will be
unaffected, but we can still notice incorrect DB access during development.
MozReview-Commit-ID: Kgzf1L3WjIE
--HG--
extra : rebase_source : b1f9f01ea746c005a038693aaa5eddb2bb103a2b
Currently we might have old (aka stale) clients appear on the History panel, which could be confusing.
This patch modifies underlying query to select only those clients whose LAST_MODIFIED timestamp
is newer than three weeks ago.
MozReview-Commit-ID: JsZJwNONDJG
--HG--
extra : rebase_source : 777c077669139e4d163e765dbe344ad8011db88b
For people with customised home panels, we need to explicitly remove the Recent Tabs panel. We also unhide the Combined History panel if it was previously hidden and additionally turn it into the default panel if the Recent Tabs panel was the previous default panel.
MozReview-Commit-ID: 5CSJUTRysQU
--HG--
extra : transplant_source : A.%23%F5%5D%CE%09%E4%F1%BE%24%7E%13Q%1B%0Bx%15e%91
By passing the panel types to be removed/set as new default panel as arguments instead of hard coding them, we can reuse that function for our own home panel config migration.
MozReview-Commit-ID: BsMxcbInRbX
--HG--
extra : transplant_source : %89zh6%85%F9r%D5%BDu%3E%80%86%AB%7C%1D%B6P%8E%0B
I didn't include nalexander's MOZ_INSTALL_TRACKING suggestion because my make
skills are too shaky to make this worthwhile. Specifying a keyfile when
MOZ_INSTALL_TRACKING is disabled isn't harmful afaik (though it's a little
spammy).
Also, added code comment duplicated for emphasis:
# (bug 1277553) In Aurora -> Beta simulation builds, no update channel is
# specified, causing an assertion to throw that MOZ_INSTALL_TRACKING is
# specified but the keyfile is not. In this case, we add a default keyfile.
# This has the disadvantage that if our beta/release checks above ever
# fail, we'll come to this default case and the compile-time check to
# specify a valid keyfile will be broken. I don't have any better
# alternatives.
MozReview-Commit-ID: 7tmemvpDaW8
--HG--
extra : rebase_source : 96930d595ebc22c06dadea1d28782ec6a2c023c2
Additionally, we add this file to the tree so it can be used by bug 1277553.
The following commit will add the docs explaining how to use the file I
added.
The added file contents are slurped directly into
AdjustConstants.MOZ_INSTALL_TRACKING_ADJUST_SDK_APP_TOKEN. We get the sandbox
token from the previously working value in [1].
An alternative solution would be to remove the assertion that
`--with-adjust-sdk-keyfile` is specified and provide a default value if the key
is not specified. However, after investigating bug 1277553, I dislike this
approach because we lose the compile-time checks that a key file is specified,
which is dangerous for release/beta builds where the key file may not be valid,
we push a release, and we don't get the data we expect.
Ideally, we specify `--with-adjust-sdk-keyfile` for non-MOZILLA_OFFICIAL
builds, but I don't know how to do that.
[1]: https://hg.mozilla.org/mozilla-central/rev/ac75f8f4c01d#l1.26
MozReview-Commit-ID: HPNgiwfzU5p
--HG--
extra : rebase_source : 6ee6cf869624b2274338d76b63072d13cc3c8432
We add URL metadata based on the base URL, we should retrieve it this way too.
MozReview-Commit-ID: ICP54V5vRgv
--HG--
extra : rebase_source : 967cf4843572b85b425735486700cd6f6c24887c
extra : source : e994f70de0490e77a2309793852434f2f1641ad7
We already pass the URL inside the JSON object.
MozReview-Commit-ID: J4RjxLAzdI
--HG--
extra : rebase_source : 49932580b5a34032e072b4b4e905ebe6daeb964a
extra : source : f685593ac3cc4ea3b8d6545e42eb7d225095161a
Originally I wanted to keep them as a separate type of icon and store them separately.
But this is much simpler and a big improvement. We wanted to treat touch icons as
better favicons anyways and making them go through the same pipeline gives us exactly
that.
MozReview-Commit-ID: LgEd1Fl6a4t
--HG--
extra : rebase_source : 618c6aa41edb5f3a9ad12ed748714482c0a7eb4c
Enabling rust in Fennec builds appears to switch some floating point operations
from hardware to software and slows down paint operations. Since no rust code
is actually used in Fennec builds, we can disable this until the rust toolchain
has better support for ARM fp hardware.
We hit an issue where adding a new env var, MOZ_DISABLE_TELEMETRY, added env10
and caused crashes. I suspect the issue is that there are is now a double-digit
number of env vars (bug 1277390). Here, we do the quick fix by removing
MOZ_DISABLE_TELEMETRY & repurposing MOZ_DISABLE_SWITCHBOARD to be generic.
While we're at it, we simplify the code by making the setDisabled methods a
strict getter without checking for how many times they're called.
MozReview-Commit-ID: 19DDbVYRZ2
--HG--
extra : rebase_source : 1590ae4f49bf725ab8a3bb26f10dab324903aa8c
In the previous implementation, we'd stop reading when the value would return
null, however, this breaks with SafeIntents where null is returned if a value
throws a runtime exception - i.e. we might stop reading at env2 if it throws
even though env3+ exist.
MozReview-Commit-ID: 7iZgUAjBSmB
--HG--
extra : rebase_source : a7440dd14bb406afcd6ac1ec514bf0b188b5b2b7
I feel this better follows the util class pattern: IntentUtils acts on Intents
as StringUtils would act on Strings.
MozReview-Commit-ID: 7n2B9q1KlSy
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/util/SafeIntent.java => mobile/android/base/java/org/mozilla/gecko/mozglue/SafeIntent.java
extra : rebase_source : ac953ac44f91f1d9b8fa4c0c2a21c539974e9df8
This gets used often enough that it's annoying to do full class name imports.
MozReview-Commit-ID: 7Yhp1NCgwQw
--HG--
extra : rebase_source : 4e4875153d171d8eb4c8ce49f8a6e6170ac5c616
We are doing more than just uploading in the delegate now.
I didn't fix this in the previous commits because version control makes this
non-trivial.
MozReview-Commit-ID: IjXsQC19k2S
--HG--
extra : rebase_source : 710fd827dd1468ca22c6372d101d3541040005ce
The same preferences will be used by the new code & the old code.
MozReview-Commit-ID: BXuSQjhhXQq
--HG--
extra : rebase_source : 8824624c524392c0178535c47bf9657ba9cf9168
This lets us put the two paths of upload code all in the same place.
MozReview-Commit-ID: BUsdyEAcdDO
--HG--
extra : rebase_source : a854facb606afd95764feac19fb5ef64f216addf
loadUncachedFavicon does exactly the same thing.
MozReview-Commit-ID: 58Yi28JZfv4
--HG--
extra : amend_source : 04776f9507d0b17432b4d74913ea20b84db5c012
The previous code checked:
if (env.startsWith("MOZ_DISABLE_SWITCHBOARD=")) {
if (!env.endsWith("=")) {
So it would not pass with the empty String but my previous revision permitted
the empty string.
Practically speaking, I don't think it matters because this is only used in
remoteautomation.py where the value is 1, but better safe than sorry.
MozReview-Commit-ID: DLtmvWlQYs7
--HG--
extra : rebase_source : 3c96cf81f729911bfefcc103f46068bd9b8fb202
After detecting multiple successive crashes in a row, we temporarily switch off automatic session restoring and display the Recent Tabs panel instead. As that panel is going to be removed, we intercept loads of the Recent Tabs panel about:home?panel=... URL and redirect them to the Combined History panel. We also use the facilities provided by bug 1060544 to jump directly to the Recent Tabs folder in that case.
MozReview-Commit-ID: 7dQ7tW2dD1M
--HG--
extra : transplant_source : %AA%1C%F1%2AD%DDR%29%D5%A2%AA%8D%1B%B6%EE%81%BE%A9%0B%CF
This adds telemetry for clicking on a closed tab or the "Open all" button. Methods and extras strings are based on those used for the old Recent Tabs panel.
MozReview-Commit-ID: 1Kc8fACkmIc
--HG--
extra : transplant_source : m%09%FA%DB%8E%E5%DEG%FF%D1%83%AB%EA%D8%3B%10%9E%08%E3%85
Recently closed tabs aren't synced, therefore being able to swipe to refresh within the Recent tabs folder isn't necessary. To avoid triggering a refresh by accident, we restrict swipe to refresh to the Synced devices folder itself.
MozReview-Commit-ID: YwekSwQr2q
--HG--
extra : transplant_source : %BB%AE%CB%A8W%9B%9F%CD%ECM%C5%B1%94u%9A%25%EE%FDN%AD
Sessionstore.bak is only read when we are initialising the home panels, so after clearing all history from the button in the Combined History panel, the "Tabs from last time" section would still linger around until the home panels have been closed and reopened. To prevent this, we now directly notify the RecentTabsAdapter when all history has been deleted, so it can immediately clear its own copy of the last session's tabs.
MozReview-Commit-ID: 3EFY2WbWqzh
--HG--
extra : transplant_source : %C1%3FyzYZ%81F%5E%F9%98%FE%DC%B0%3F%0D%D3%18%7Bt
Depending on the History panel's PanelLevel state, we now dynamically set the panel footer button's text and determine its onClick behaviour.
MozReview-Commit-ID: EjesnHsntyC
--HG--
extra : transplant_source : NCs%94C%DE%F5%FC%E6%D7%EA%F8%05%1E%D4%0E%2B%2B6%02
Clicking a tab in the list of recently closed tabs now sends the appropriate message back to the session store.
MozReview-Commit-ID: KF3UJjq5zQK
--HG--
extra : transplant_source : %3FU%EB%87%1B%C4%13I/a%FB%C5%C2v%06%26V%0C%A0%D8
We need to update the recent tabs count displayed by the smart folder as necessary. To do this, we copy the approach used for updating the synced devices count.
MozReview-Commit-ID: BFwv5bY1DWk
--HG--
extra : transplant_source : %1A%EB%B0g%05%94%F3%E9%26%D8%1F%15%DF7%C3%EB%1E%27%C6_
The recent tabs count might change while the Recent Tabs folder is open, e.g. immediately after startup, once we receive the first "ClosedTabs:Data" message from the session store. Therefore, we need to hide/unhide the empty view as necessary, which is normally handled by the Combined History panel's updateEmptyView() function. Since we aren't using a cursor, we can't hinge calling that on the CursorLoader's onLoadFinished() callback, so instead, we include our own callback to the Combined History panel, modelled after the DeviceUpdateHandler used for updating the count of synced devices.
MozReview-Commit-ID: GLHM9LoWk2h
--HG--
extra : transplant_source : %09E%B2D%DCB%F6%D3%B5%8A%28%DCx%94e%A2%0F%14%A3%96
This fills the new smart folder we've previously added with life and displays the recently closed tabs as we receive them from the session store. If we can find a sessionstore.bak file (previously the "Tabs from last time"), we also add those tabs to the bottom of the list.
Most of the code for communicating with the session store and reading sessionstore.bak is adapted from the original Recent Tabs panel, however unlike the previous implementation, I've opted for a cursor-less approach of storing and retrieving the recent tabs data, since the recent tabs data isn't actually powered by a database anyway. Instead, the RecentTabsAdapter maintains two arrays for storing "Recently closed tabs" (as received through messages from the Gecko session store) and "Tabs from last time" (as read from sessionstore.bak during panel initialisation).
Also, as per the other Combined History panel adapters and because we're now using a RecyclerView instead of a ListView, list item types are now determined on demand through getItemTypeForPosition() instead of precalculating them during a data update and directly storing together with the tab data items in a cursor.
MozReview-Commit-ID: IpoUr9f0JBP
--HG--
extra : transplant_source : %C4%D5%AF%CA%A4_-%85%1AL%1D%9CF%2B%20Lh%7B%02%21
This folder can be opened and closed to get back to the history view, however it doesn't contain any actual content (closed tabs) yet. Its empty view is based on the original empty view of the Recent Tabs panel.
For displaying the recently closed tabs count within the smart folder similarly to how we display the number of synced devices, two new strings need to be added.
MozReview-Commit-ID: IAL0yDrc2Ld
--HG--
extra : transplant_source : %A1%80jZ%1Eg%14p%7D%DD%DD%EA%E8%7E%CA%0E%CD%28%99%3C
Bug 1277277 will track getting this icon used for the search term history, too, so we can remove the old resources (icon_most_recent_empty.png) completely.
MozReview-Commit-ID: GFFovwiRokc
--HG--
extra : transplant_source : %5C%E5%EA%E4%D5%B7%F7%11%8E%DDSG%3C%93%13%DE%18%14%0E%03
OnPanelLevelChangeListener.PanelLevel.CHILD_SYNC really is a mouthful.
MozReview-Commit-ID: 3uEHQjUlTxf
--HG--
extra : transplant_source : %C8%E3%7E%D3%DB%84%92%0DPQ5/a%23%18%8F%8D%FD%BB7
Otherwise, depending on the device's display dimensions, a second smart folder would be overlapped by the empty view message that is displayed when no history is present for the history panel to display.
Once we've updated to a newer version of the support library (see bug 1267884), we should revisit this and see if using "wrap_content" is working properly instead.
MozReview-Commit-ID: 1xBCeiST9n4
--HG--
extra : transplant_source : %E5%A6%C7%DB%8E%DCQ%3D%B29%94%9BZ%EC%0CbJ%0F%08%B0
Because I don't know much about the build system, this may not be an optimal
fix. See the added code comments for more details.
Since this is an annotation processor and they tend to be self-analyzing, my
one concern is that this code uses the classpath in some way to identify which
files need to be kept. That being said:
1) I don't think it makes sense to use the classpath in this way, particularly
when the files we want to operate on are passed as a command line argument.
2) My build did not warn me that the generated JNI wrappers have changed so I
expect no side effects from this change.
MozReview-Commit-ID: 5mm6TClO1Su
--HG--
extra : rebase_source : c1ae4f0e9972f9efd8d6593fcbf27a500a6e0b63
See the added code comments for motivations.
Note that this is a speculative patch - I was unable to reproduce the crash and
thus do not know if it fixes it, however, I did test that the appropriate
toolbar configuration is created on vanilla Android for phone & tablet.
MozReview-Commit-ID: 2v1Ix8X68LH
--HG--
extra : rebase_source : ee32c374d9e2daf1a75975b657cb173dd1432fc3
If we cannot display all search engines then we want to show a smaller number so that the last one is
cut-off (we only display half of it). The previous version did not calculate the next smallest half
correctly: Instead of displaying 3.5 engines if we have space for 3.7 engines, we only displayed 2.5.
MozReview-Commit-ID: KfopL9td3ba
--HG--
extra : rebase_source : 22534e56a0b9668921fc7bc0d5c2f874823645ed
On Android N, the tab button flickers when drawing animations such as the loading progress bar,
or even the tab count increment, over the tabs button. Using hardware layers appears to fix
this. For consistency we could use this across most devices, except those running 4.4 or earlier.
There the button background (light gray) is drawn black with hardware layers, so we should stick
with the default on such devices.
MozReview-Commit-ID: H5VWEkrRbVf
--HG--
extra : amend_source : bf1973e336f9bfc0cdface27b1d2038bf616a45a
We add URL metadata based on the base URL, we should retrieve it this way too.
MozReview-Commit-ID: ICP54V5vRgv
--HG--
extra : rebase_source : ba9444683883f47fe7fa7b5fb7bbca1201ac2f5d
We already pass the URL inside the JSON object.
MozReview-Commit-ID: J4RjxLAzdI
--HG--
extra : rebase_source : 9a4c365fbd2ce4321c84a994db680f8906c13bea
(Backed out changeset 9575e608cabe)
loadUncachedFavicon allows loading favicons from the internet, whereas
getSizedFaviconForPageFromLocal restricts itself to the favicon cache.
(LoadFaviconTask's last parameter is (boolean) onlyFromLocal, which is
set to true in getSizedFaviconForPageFromLocal.
We could probably replace this with an Enum to make the parameter's purpose
more obvious.
MozReview-Commit-ID: C9uwcG0h0N
--HG--
extra : rebase_source : 291dd46988bcbe2dd307bdc3f030daca6bd154bf
Previously the "next" link was hidden on devices such as the Nexus S.
Reducing the size of the top image seems to be the most efficient way
of ensuring that all content fits on screen.
MozReview-Commit-ID: JFCYbXTEKp1
--HG--
extra : rebase_source : 22e0ed9a3a3038a5f8c397a3b575f6aa9449dfdb
extra : histedit_source : 8e66bebb93235670ca0c4262c68d43a19333806d
Apparently this code can crash despite the nullcheck, let's completely
remove it since we don't use the results.
MozReview-Commit-ID: CzHn8kABLYd
--HG--
extra : amend_source : d254ee112a10a115d6a9c44f95a6713931cd4509
By default CalendarView doesn't receive sufficient height on pre-lollipop
devices, in fact the entire dialog won't even appear unless we manually
assign height. This is slightly hacky, but necessary to ensure correct
layouting. (We previously assigned both height and width to the CalendarView,
however that results in all kinds of odd behaviour - this change is necessary
only to have acceptable behaviour on older devices.)
MozReview-Commit-ID: H7wzHsrOJy4
--HG--
extra : rebase_source : 9d3a6c3aab6958b45459a36045ccb8f7f7b165e1
extra : amend_source : 3a7e289e5e237f2cad725b73bd2e5399f5052c70
extra : histedit_source : 03c1b50843e1724058061faad267ce41880123a1
Squashing CalendarView makes it look bad and hard to use - by allowing
it to expand to the dialog width we get a usable CalendarView.
Note that this breaks on Android 4.x. On these devices CalendarView is
implemented using a ListView, which for some reason isn't given
any space during layouting - this results in the actual days in the month
being hidden (we do however see the weekday titles / month title).
MozReview-Commit-ID: wHNx1xG3JK
--HG--
extra : rebase_source : 6eb01c3cd4d9a38d7df516875201ab1eea265828
extra : histedit_source : c99960cd21663875f826894433ba57d99cf0facd
Our current decision criteria is arbitrary: there's no good reason not
to use a CalendarView here. Moreover our previous criteria would result
in small tablets showing different views depending on orientation (Nexus 7:
CalendarView in landscape, pickers in portrait mode).
MozReview-Commit-ID: 8H0HTmCnzfP
--HG--
extra : histedit_source : 70cac01314055881370cf342614c18c2eafceba3
If the src is too long, we crash!
To test this, you can use my test page:
https://people.mozilla.org/~mcomella/test/base64.html
An alternative approach would be to prevent users from sharing base64
images altogether because the experience is slightly jarring (since the
base64 string is copied to the application rather than the image).
MozReview-Commit-ID: AQeQ0Ff6ZMB
--HG--
extra : rebase_source : f265c9c474adaeaef9dd50bde5b9f80c6d5b0f53
On pages that aren't "width=device-width" or similar, Gecko adjusts the resolution when the display dimensions change, e.g. because the device has been rotated. The session store needs to do something similar when restoring a page if the device orientation has changed since the moment the tab state was captured.
Therefore, we now include the width of the browser window in the saved zoom data and use it to scale the zoom level as necessary when restoring a tab.
MozReview-Commit-ID: LBbEquO1bZ9
--HG--
extra : rebase_source : 38465ee3f16dded1d1e953fd3cdbf31b821d4777
Since we're now recording the scroll position in the session data, it makes sense to store the zoom level as well.
To do this, we make use of the new facility introduced in bug 1270019, which allows us to provide a desired initial resolution to the MobileViewportManager. For this to work, we need to send our desired zoom level before the MVM calculates the initial page resolution, i.e. before first paint/page load. Therefore, we now have browser.js notify us of location change events, so we can set the zoom level to restore early enough.
This also means that we can no longer restore the scroll position on load, because the MobileViewportManager applies the resolution we provide it via utils.setRestoreResolution() only after the first paint or page load ( whichever happens earlier). In the latter case, our JS load event handler will run shortly before the MVM has applied the desired zoom level in its own event handling code, which means that any scroll attempt which depends on the page already being zoomed in will fail to apply.
Therefore, the scroll position restoring needs to be moved to a later point in time, i.e. in this case the "pageshow" event.
MozReview-Commit-ID: 6NtYqc8pm3N
--HG--
extra : rebase_source : a6737e5c047ab2327e3a0e52c2a1176e9248a361
This copies the approach we've taken for form data saving and applies it to recording the current scroll position of the page, too.
This means that after receiving a scroll event, we capture the scroll position for the top level document and all direct child frames and include it in the session store data. Because compared to the form data input events the scroll event can fire at a relatively high rate, we throttle the scroll position capturing using timeouts to run at most twice per second.
MozReview-Commit-ID: C0lBxzHav7Z
--HG--
extra : rebase_source : 325c0f92ce003ea9026e3206b4bb101db1f037a7
Parsing the session store JSON data to restore the last session's tabs is both
- computationally relatively expensive
- involving disk I/O
therefore, we shouldn't be doing it on the main thread.
To make sure the session data is actually ready, subsequent code running from a different thread that needs to access it (loading the startup tab, the Recent Tabs panel reading the "Tabs from last time") checks that session store data processing has actually finished and waits if necessary.
MozReview-Commit-ID: EYf1fdglIrA
--HG--
extra : transplant_source : %0D%60F%B0%16%DF%7E%03%CEL%F9%15G%E0%8E%8Fl%21%EEZ
For session data parsing, we need to know whether we were invoked with an external URL or not. Since we want to move session data parsing forward to an earlier point in time, but also continue needing that external URL info during initialize() as well, we'll factor out those calculations into their own functions which can then be called from both places.
MozReview-Commit-ID: HFlT8uxC9yz
--HG--
extra : transplant_source : %A4%AE/%F5%00P%89%95N%033%F3%C6%0E%98%A4%8A%9F%B6%2A
Android Studio doesn't recognise our version guards and is consequentially always showing two errors in GeckoApp, which makes it more difficult to spot when you've introduced an actual error.
MozReview-Commit-ID: LpNIwHOhEWE
--HG--
extra : transplant_source : %22%86%80q%1E%CE%FE%B1%16%BF%40%DF%C0%0F%5D%CB%E0%F8%A0%8A
Delay initialization of PushService and DLC in GeckoApplication to after
the Gecko:Ready message. That way, hopefully they give up some CPU time
to other initialization tasks.
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
