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