This patch will create a single Intent action for all content notifications. The intent will be handled by
ContentNotificationsDelegate exclusively.
MozReview-Commit-ID: 5UVVanLLd32
--HG--
extra : rebase_source : 9c6f93aad7f070a847b5f13ff38bbcabef684cf6
We only care about API >= 14, so there's no need for the pre-v11
menu.
MozReview-Commit-ID: 9DdahLRXzpD
--HG--
rename : mobile/android/base/resources/menu-large-v11/browser_app_menu.xml => mobile/android/base/resources/menu-large/browser_app_menu.xml
rename : mobile/android/base/resources/menu-xlarge-v11/browser_app_menu.xml => mobile/android/base/resources/menu-xlarge/browser_app_menu.xml
extra : rebase_source : 2dc4287a5ca8b3b008ae8a2ae962be9d4568f36b
extra : source : a7203a518ca87199bfe729bdbfc6b368d23b8c5f
After this patch, I still occasionally see the toolbar positioned part
way down from the top of the screen. However, this state looks slightly
less janky without the animation I removed and I can't consistently
reproduce it anymore. Given the DynamicToolbar.setVisible calls I make,
I'd guess this is likely to be a bug caused by BrowserApp.onTabChanged
(and thus DynamicToolbar.setVisible) not getting called instantly and
so the DynamicToolbar is initialized to a different location on screen.
I'd guess it's a bug in DynamicToolbar as to why it's positioned partially
off-screen.
There is a little bit of code duplication, but that is because the code
to load a url on a new intent is duplicated (i.e. once from GeckoApp.initialize
- the initial load - and once from GeckoApp.onNewIntent). This could
potentially be cleaned up if we moved the app loading code into onResume,
but that may not be possible since we need to wait for Gecko to start
up.
Additionally, this patch adds a lot of hard-to-follow global state, which is
also not good.
Preferred solution (bug 1269041): show the toolbar each time onStart is
called (i.e. FF is unhidden). This is good for the user - they'll be
more aware which page they're on - but it's janky with the current
implementation, where the page content does not scroll when the toolbar
is shown so previously visible content is hidden. Thus, I went with the
other approach. fwiw, Chrome does this behavior, but scrolls the toolbar
offscreen shortly after it is shown.
This solution is blocked on bug 1245523.
MozReview-Commit-ID: 7JjCrIf4KTm
--HG--
extra : rebase_source : 803cc3e6f940462168a61f0a12b32a0391611caa
This is a temporary fix. The new plugin is able to find more unused resources.
However we are not ready to remove all of them yet. Some of them will be in
use again soon.
This patch will add those files to UnusedResourcesUtil in order to suppress
the lint error.
MozReview-Commit-ID: 7X9Dee6hWDg
--HG--
extra : rebase_source : b4914b322abeba85238d0fe7b4917c7ef4757925
* GeckoActivity, LocaleAwareAppCompatActivity, LocaleAwareFragmentActivity, LocaleAwareActivity:
Those activities are never instantiated directly. Make them abstract.
* CrashReporter: This activity is only registered if MOZ_CRASHREPORTER is set. Supress warning.
Unfortunately I had to downgrade this lint check from "error" to "warning" because the current
gradle plugin doesn't recognize the SupressLint annotation for the "Registered" check:
https://code.google.com/p/android/issues/detail?id=204846
MozReview-Commit-ID: Hy56pZB8ZdB
--HG--
extra : rebase_source : 2f40d84792baaaffd4093e8cb2b17eb1155df5c3
The number of recent successive crashes is now tracked wholly within Java, so we can remove the old Gecko pref and the associated reset code.
MozReview-Commit-ID: 7bR9wqJsLoi
--HG--
extra : transplant_source : %A3%9C%89%87%E9Z%9B%C6%900%23%27%C1%CF%B7%DD1D%DD%FC
Bug 701092 originally implemented some functionality to detect successive crashes and then turn off session restore for the next start, however that functionality got lost when parts of the startup session restore code were moved to Java.
This patch re-implements this functionality within the Java UI. Unlike the previous implementation, we don't reset the crash counter in onPause(), because often enough onPause() will execute even after a crash. Instead, we check in onResume() whether our last foreground activity cycle crashed or not.
To avoid cross-process writes and reads to shared preferences, the crash reporter no longer sets the relevant flags in GeckoApp's shared prefs directly, but instead writes an empty CRASHED file to the Mozilla directory as a flag, which is then checked for by the main process during startup.
Alternative solutions considered were:
- Using Context.MODE_MULTI_PROCESS for accessing the shared prefs. Works, but forces the shared preferences to always be re-read from storage and is also deprecated from API 23 onwards.
- Using a ContentProvider for managing the cross-process shared prefs as suggested in Google's documentation. Seems somewhat over-engineered for this use case.
- Sending a broadcast from the crash reporter to signal the main process, so it can update the relevant shared prefs from the correct process. Doesn't work reliably immediately after crashing - sometimes the broadcast never arrives.
- Setting the crash flags directly in the crash handling functions in GeckoAppShell. Could work even when not building the crash reporter, however doesn't work easily for native crashes, because those are handled internally by Gecko without going through the Java crash handling code.
MozReview-Commit-ID: 6g7AmnJhoQk
--HG--
extra : transplant_source : %C2%F28%D9%8A8%08%C6%9F%A4%03%D7%EC%81F%B9%21%3A%E2x
The crash reporter runs in its own process but uses GeckoApp's shared prefs both to store its own settings and to signal to the main process that it has crashed, which can be somewhat problematic because each process might fail to notice settings changes made by the other process. As the simple solution of enabling Context.MODE_MULTI_PROCESS for accessing the shared prefs is now deprecated, we'll devise an alternative solution instead.
In Part 1 we move the settings that are used exclusively by the crash reporter into a separate shared prefs instance.
MozReview-Commit-ID: 1QWBAL2Xcn2
--HG--
extra : transplant_source : %C4%D2%C0%82%F3%19%E1%19%D9%82%11w%D3%D9%B3%DC%9Be%95%91
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
The token is only used for release and beta builds, so it's better not
to define it inadvertently for all builds.
MozReview-Commit-ID: 3DLem4PhXD7
--HG--
extra : rebase_source : f8f37d2bdfd12fea6403f097ebe5080be562d860
This avoids a problem where a lifecycle method may assume a previous lifecycle
method initialized some values but we returned early (e.g. on a not supported
system) so these values were never initialized and the application may crash.
I tested this patch by forcing HardwareUtils.isSupportedSystem to return either
true or false (but both were in a supported device configuration).
MozReview-Commit-ID: 1WvOId8CLjP
--HG--
extra : rebase_source : 18f79cb938d845131165b40ca7c030d66f5ffbf8
For now we only need to support the bookmarks smartfolder, however
we might want to extend this to support "recent bookmarks" in future.
MozReview-Commit-ID: CvDNyfycWRl
We want to be able to show the numebr of items for certain folders (e.g.
the reading list smartfolder). The previous state list drawable was also
unnecessarily confusing, let's just reference the desired images directly.
We can do this largely by copying the existing TwoLinePageRow, modulo
the unneeded status / switch-to-tab icons.
MozReview-Commit-ID: 3w0Hcj0kIfG
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
Sebastian Kaspari
Grigory Kruglov
Andrzej Hunt
Mouaad Aallam
abdullah
Chenxia Liu
Mike Taylor
Michael Comella
Wes Kocher
Carsten "Tomcat" Book
Victor Ng
Alastor Wu
Chun-Min Chang
Jan Henning
Shatur
dimi
Timothy Guan-tin Chien
Ting-Yu Lin
Andrea Marchesini
Kartikaya Gupta
Mark Capella
Jim Chen
Michael Kaply
Johann Hofmann
Nathan Froyd
Nathan Froyd
Geoff Brown
Kim Moir
James Willcox
Margaret Leibovic
Victor Ng [:vng] [:crankycoder]
Mathieu Leplatre
Randall Barker
Nick Alexander
Ryan VanderMeulen
Andrzej Hunt
Eugen Sawin
Rutuja
Tristan Martin
Gijs Kruitbosch
Ray Lin
Jonas Sicking
Jorick Caberio
William Chen
Mouaad Aallam
bzrd_Sdn