Reasons for replacement:
* The old method was untested
* The Scanner class is supposedly slower than using Streams directly (which
the new methods do)
* If possible, it's generally better not to duplicate solutions - using the
Scanner works around the infrastructure this changeset series built (i.e. using
Streams).
In the edge cases, getFileContents:
* throws NoSuchElementException for empty files. The new behavior is to return
the empty string. Since getFileContents was always wrapped by `new JSONObject`
or similar, and we throw when the file is empty, the behavior should stay the
same.
* throws NoSuchFileException for missing files. This is the same as the
new behavior.
MozReview-Commit-ID: 6ESPss29emU
--HG--
extra : rebase_source : 24af07bddd585b857ebd8eb4eff4c7ac4898ba37
This method duplicates an existing method (readFileContents) which will later
be removed.
MozReview-Commit-ID: 2aVf74KvYyP
--HG--
extra : rebase_source : 3aa814f3e227fba4c5bab9434894aef6178da333
Javadoc in this commit references a method that is not yet added.
MozReview-Commit-ID: Hc0MSLYTQgD
--HG--
extra : rebase_source : bb30eb579fd8450a0b4698d38333b468f3b6e372
I would have separated these methods but version control fail.
MozReview-Commit-ID: 7og2iBKqHiH
--HG--
extra : rebase_source : 62db6247aedfc3683249f093a8d3688e6408ab17
That is, the single caret in cursor mode will always persist on all
platforms as on Firefox Android.
MozReview-Commit-ID: 5MTCf1n2dF3
--HG--
extra : rebase_source : 4062752d7c781acc19088106028e848d1192f880
Showing and hiding the keyboard in onCreatInputConnection avoids a
possible race with resetInput in notifyIMEContext, and it replaces the
"show keyboard on window refocus" hack that we had before.
This provides a basic helper UI that can be customised with images/text.
We need a very similar helper for both reader-view offline bookmarking related
helpers (Bug 1236328 and Bug 1247689), hence it's useful to have a common
class implementing most of the required functionality.
Most of the new helper is borrowed from the existing HomeScreenPrompt. I will
extract the common functionality in a followup Bug.
MozReview-Commit-ID: Byc5VnVFffj
--HG--
extra : rebase_source : 1e20ab501f47dbdfd17d243ce8db4676ac841ab4
extra : source : b52ab3637d1e0eadd3c465a541324a74e6461af3
We're always using this as a String, we might as well make this explicit to avoid having to cast
anywhere. (We very rarely use the parameter, but some new code in the main part of Bug 1263571
would have to cast this to a String. We can avoid that if we just use the correct type.)
MozReview-Commit-ID: H8JdMzQtmRI
--HG--
extra : rebase_source : 4cdad694c54e94fce1c108dadde22d3cd3fc4b60
extra : histedit_source : e094d203b2ba5273cdc219e63d92e2bf2de8603e%2C9cbcd9464c1a19fecbfb1f60daa39b2d53c9da4a
1) Use prepared SQL insert statement for insertions
1.2) Use ON CONFLICT IGNORE for our inserts, to avoid failing on possible data clashes
2) Don't synthesize "visits since last sync" - it's bound to cause problems, for not much benefit
3) Fix up some minor issues, cleanup code and add sanity checks
4) If there's evidence Sync was enabled at some point, mark synthsized visits as remote. Otherwise, as local.
MozReview-Commit-ID: Gd94A6r4rW
--HG--
extra : rebase_source : e4f74e3d1d286e1107e5a1764ae8ea3fd5ff3ff2
See code comment (and related bug) for details.
MozReview-Commit-ID: EDzIBftjJRU
--HG--
extra : rebase_source : 94721323a4372010941dcce034093d3f0d1ac95c
If the URL of new content is already in the user's history then we won't show a notification
for it.
MozReview-Commit-ID: B26SBvXOnxY
--HG--
extra : rebase_source : 5fe3d6ad40939bfe5e842d075c1b0abc1226ac10
Enable sending event response when Gecko state is PROFILE_READY. This
happens when Gecko is loaded in the background and GeckoApp is not
active. This is safe because it's only a response to an event from
Gecko, so there is definitely a listener for the response on the Gecko
side already. r=me for a trivial change.
Note: need to set package name in robolectric.properties so that Robolectric reads correct resources
MozReview-Commit-ID: 6wrh8kzJlXI
--HG--
extra : transplant_source : %86T%8BUB%ABe%0A%DF8%F0%81%0C%ACi%D1Rx%E2%EC
The logging can be enabled by setting "browser.sessionstore.debug_logging" in about:config.
MozReview-Commit-ID: DCJevcsg549
--HG--
extra : transplant_source : %E3%166%F7%0C%29%C0%FB%0A6E%02Sd%10%9D%9A%5DN%7D
I wonder if there is a better solution to guarantee we have the necessary data loaded, however
this seems to be the only special case (i.e. the only place we use TwoLinePageRow without
the DB having been loaded first).
MozReview-Commit-ID: F4iAIpe87IY
--HG--
extra : amend_source : 798700a320878d440bac4a6af7a5438601f3fe36
It is possible and valid to have a null selection. All other manipulations
are null-safe, and we need to be able to handle the null-case when testing for
annotations being part of the selection.
MozReview-Commit-ID: Fpnt2NX1BmV
--HG--
extra : rebase_source : f08a3219e581696594381cbdf10c5dd5d2c8359f
extra : amend_source : d0c9b7050d6792c0923deb9e7896e6839d91b169
Sync is vast and could be strange, so let's allow for some weirdness in numbers and recover gracefully.
MozReview-Commit-ID: 6o6SdcvmK8x
--HG--
extra : amend_source : 89f690a0688e8fcef83839bfc232af2b8763c90f
Enlarge the touch target of the caret to the left, bottom, and right by
59% (13px) per bug 1262755 comment 7.
Since the touch target becomes larger, the carets on the <input> in
previous test might cause the next test to fail on <textarea> because it
will press on the caret when trying to focus on <textarea>. Add two <br>
to testAccessibleCarets.html to separate the <input> and <textarea>.
MozReview-Commit-ID: JIwmuHJ2QsQ
--HG--
extra : rebase_source : 73b662980a5be55a4e3e31506437f2c26f65cd85
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
It turns out that with sync enabled, we do the first load of the database on the UI thread.
The SavedReaderViewHelper (which is initialised during DB load) assumes we're run off the
main thread, we need to disable that assertion until we can ensure that DB loading is done
off the main thread.
MozReview-Commit-ID: AYQewTVjEbA
--HG--
extra : amend_source : 7d479084124b57135f4a97687d43652cf8041960
As best as I can tell, this code runs before Gecko is initialized. via
bug 1255657 comment 8:
To confirm this, GeckoProfile is created before the GeckoThread is
finished launching but it seems almost coincidental:
GeckoApp.onCreate
GeckoThread.launch
GeckoThread.start
...
GeckoThread.run
GeckoThread.getGeckoArgs (notably before GeckoLader.nativeRun)
GeckoThread.addCustomProfileArg
(if GAP.getGeckoInterface != null, which is set earlier in GeckoApp.onCreate)
EITHER
GeckoProfile.getDir() (if in guest mode)
GeckoProfile.forceCreate
GeckoProfile.forceCreate (if not in guest mode)
forceCreate opens the times.json file.
That being said, if this code path changes, forceCreate is also called
when the GeckoView is initialized (which occurs after the GeckoThread.launch
call, but is likely to happen before Gecko finishes launching).
---
If we wanted GeckoProfile initialization timing to be seem less coincidental,
we should consider initializing the profile non-lazily: bug 1262625.
MozReview-Commit-ID: LGluC021CTg
--HG--
extra : rebase_source : 7d1ff8a354accfaae0dc3f2d222ed32f6aa8cbf6
It's an anti-pattern:
https://blog.jooq.org/2014/12/08/dont-be-clever-the-double-curly-braces-anti-pattern/
Mobile-relevant summary:
* It creates new types, bloating our APK
* It can cause memory leaks by keeping a reference to the containing class
MozReview-Commit-ID: 4HQHgenOq92
--HG--
extra : rebase_source : da676dcd95f836b6ef3ba4d8465ecaf74d1e15e8
This restores the functionality to close the menu by pressing the hardware menu key.
MozReview-Commit-ID: EKCeALPvFoB
--HG--
extra : transplant_source : %02%7E%E0%98%40%F3%D1%A4C%FC%CA%7E%CB%96%A2%CC%EDkq%D6
They were previously being set to GONE, causing a measure pass when the
animation started.
MozReview-Commit-ID: FKjB2vJmWkd
--HG--
extra : rebase_source : 25a10f5e8121b48883d8673fa2184ab42a341605
