Additionally this patch:
* unifies the telemetry for declining the prompt to always be: (cancel,back,'home_screen_promotion')
* moves saving the rejection in the database to a background thread
MozReview-Commit-ID: HywutUDtGcY
--HG--
extra : rebase_source : 107b398a84a2eed231bcf86f5075b997bf98e5ff
This approach is extensible and would allow easy addition of special icons for e.g. the
screenshots folder.
MozReview-Commit-ID: 44yWq85x2HG
--HG--
extra : rebase_source : be15df11f474f4db5546b823ca4040bdb2a63b6f
extra : amend_source : be16d760fa2c32cce3af7b2985d3549f9993664b
Make sure that the app menu can be opened and closed via the hardware menu key.
MozReview-Commit-ID: 3E459eCRneY
--HG--
extra : transplant_source : %81%BB%C1%EB2%9A%2C%FDG%F4vwMw%19%D4%C6%EF%7C%F5
Our theming inheritance around Preferences still seems quite messy, however given we'll
need to uplift this I'm planning to tackle this in a separate bug.
We add the LocaleAwareAppCompatActivity in order to avoid affecting other consumers
of LocaleAwareFragementActivity (primarily the SearchActivity). We will investigate
those separately.
MozReview-Commit-ID: KVEZbDdza1s
--HG--
extra : amend_source : 3b296714b2f1d1aa2fd09f4ea8ee7641d0bb36fb
I added some log statements to ensure this worked correctly locally - on a new
profile:
* Log statements were printed listed the two files I expected to be deleted
and their paths
* The log statements did not appear after closing and reopened fennec,
meaning the process short-circuited as expected.
Ideally, I'd test that a profile that currently has these files actually gets
them deleted, but it's not easy to create profiles.
The previous patches also contributed unit tests.
MozReview-Commit-ID: 1FOZraATc6x
--HG--
extra : rebase_source : f6481569ce478b64571997c7ec44ad59ea0f9d93
This controller is under-featured (e.g. it's not scheduling cleanups for future
dates and it doesn't cache files it already deleted) in favor of simplicity.
MozReview-Commit-ID: KJqKV0OH2ID
--HG--
extra : rebase_source : 370794e6a2ef93e11d28cc1b2d835027ba382516
This is intentionally kept minimal to ensure simplicity.
MozReview-Commit-ID: IJRxrTbWN2P
--HG--
extra : rebase_source : 13f9b1ef67eaa83bed64c28e1315b15e56a55a46
This should help make the Builders more discoverable when looking at the
TelemetryPing class.
MozReview-Commit-ID: K1OiSuKW5fO
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/telemetry/TelemetryCorePingBuilder.java => mobile/android/base/java/org/mozilla/gecko/telemetry/pings/TelemetryCorePingBuilder.java
rename : mobile/android/base/java/org/mozilla/gecko/telemetry/TelemetryPing.java => mobile/android/base/java/org/mozilla/gecko/telemetry/pings/TelemetryPing.java
rename : mobile/android/base/java/org/mozilla/gecko/telemetry/TelemetryPingBuilder.java => mobile/android/base/java/org/mozilla/gecko/telemetry/pings/TelemetryPingBuilder.java
extra : rebase_source : 0e9165b9230f4cc91066460cc72d12f36efe9a91
The Builder pattern has the following benefits:
* Encapsulate identifying optional arguments
* Encapsulate parameter validation
* More fluent parameter insertion (e.g. instead as unnamed arguments to a
function)
* My implementation makes it fairly straight-forward to construct new
telemetry pings.
MozReview-Commit-ID: EpcW3N57HJj
--HG--
extra : rebase_source : a33ef584ed47b36910417854208fa02438556467
If tab data is initially null then we disable the bookmark star. We need to explicitly
reenable it when we load an actual page. All other menu items seem to be explicitly
enabled as needed below, only bookmarks was omitted (since it's expected to be enabled
~all the time) - but we still could have disabled it previously.
MozReview-Commit-ID: GpVJu4Rw2dN
--HG--
extra : rebase_source : 6f4428e4273efe8f5639c36a1cfea9c7de6db135
extra : amend_source : c9f3c560f24bd878914ffd78829d3354349319a3
Our other home-panels have a white background. This panel was created as a copy
of one of the onboarding screens, which have a grey-ish background, and that
attribute wasn't removed.
MozReview-Commit-ID: 2tN5ySUlxex
--HG--
extra : amend_source : 18514684b3ad0e10e6e1aaaade4bc8435166c6d8
Taking over this bug as nalexander is not available.
MozReview-Commit-ID: 2Vkv4U6anyD
--HG--
extra : rebase_source : 1f75a3057f8f2d9559577a2628ce6df86108fc05
extra : histedit_source : 580ec2f6de51b7872f1b400d3cb0f4a37c2600ec
None of these were run in automation anyway. I elected to hg rm,
rather than try to hg mv, since I reworked the tests a little for
Robolectric, including merging two into one. The history isn't
particularly valuable here.
MozReview-Commit-ID: 47eDYvS3l1y
--HG--
extra : rebase_source : 67594b884b62081475deb7691b47b7862950a99f
extra : histedit_source : 59020ff5f6b983868143ee317dc3ce745e8f77f9
Notes:
* Setting the package name in robolectric.properties lets us read
resources. If we don't, Robolectric tries to read from
org.mozilla.fennec_$USER or similar.
* We need DelegatingTestContentProvider not for isolation but to
append "test=1" to all URIs. Robolectric provides isolation by
starting each test in a clean environment, but if we don't tell the
CP to run in test mode, it tries to write into DBs that Robolectric
doesn't like.
* Robolectric needs manual "shimming", i.e. the test must tell the
ShadowContentResolver how to resolve. We also need to handle
shutdown() ourselves. Basically, Robolectric doesn't try to
duplicate the entire Android ContentProvider lifecycle.
* We might grow a "ContentProviderTest" base class to handle the
registration and shutdown in the future. I find such base classes
frustrating and limiting in our Robocop tests, so I'd like to try to
avoid them in our unit tests for as long as possible.
MozReview-Commit-ID: A0paQXA2uoy
--HG--
extra : rebase_source : 85867a460cd076bb5e77a6e40b2d8bcb7fe45f67
extra : histedit_source : e2c6e56193c96fcf42e848d636328e03c405c7dd
