(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
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
