I would have done this sooner but it's a version control nightmare.
I made the change because it's harder to grep for logs when the logtag doesn't
include "Telemetry".
MozReview-Commit-ID: GD8Cb8D5CRy
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/telemetry/stores/JSONFilePingStore.java => mobile/android/base/java/org/mozilla/gecko/telemetry/stores/TelemetryJSONFilePingStore.java
rename : mobile/android/tests/background/junit4/src/org/mozilla/gecko/telemetry/stores/TestJSONFilePingStore.java => mobile/android/tests/background/junit4/src/org/mozilla/gecko/telemetry/stores/TestTelemetryJSONFilePingStore.java
extra : rebase_source : 754912d199c84ab166b58a3ddd7c4f0e8d80bde3
There is less to store on disk and it's probably more correct.
MozReview-Commit-ID: KAJAE1M7Fzv
--HG--
extra : rebase_source : ef226ea7b7d0ce03e216eb640dff30245551cc55
Note: this is the first commit expected to compile.
MozReview-Commit-ID: Fc8uRkJAXgB
--HG--
extra : rebase_source : c34096f6123fa898b3b3553b2914122f4ff92143
Thoughts:
* An alternative design put this code in a CorePingUtil but I decided these
methods are tied closely to the TelemetryCorePingBuilder.
* Adding these methods makes it less clear what the class is about (without
filtering on public methods that is).
I'm not sure what the best trade-off is.
Note: this is not yet expected to compile.
MozReview-Commit-ID: FQYFP3ioewN
--HG--
extra : rebase_source : 660c66cb5bb38928b9e532e1861ff7c8c3169187
Note: for version control and review simplicity, this does not yet compile.
MozReview-Commit-ID: EvccGtseOKT
--HG--
extra : rebase_source : 9572d2df3a306ca4b51b1af464a21161db66ba78
I'm thinking it's better to have constants with the classes they're most
closely associated with rather than one giant constants file because it becomes
hard to find anything in a large constants file.
MozReview-Commit-ID: D3SCkW3vbRM
--HG--
extra : rebase_source : 37611c82f84ba011c763554c6793bef63c093faa
Since the history restore code now apparently supports restoring subframes, too, we should let the mobile session store capture frameset navigation as well, so we can preserve the full browsing history.
MozReview-Commit-ID: 5SM8eMTfgIH
--HG--
extra : transplant_source : IO%1Bz%CA_%14%D0D%F9Q%FBA%E5S7%85%90%AE%C0
We do this by showing history items in the "share" menu item, and
removing the existing "quickshare" item that showed history items.
We also need to shuffle our icon sizes around: our xhdpi icon size matches
the hdpi icon sizes of the other icons in the top bar (modulo padding, which
we need to add as part of this commit), similarly our xxhdpi icon is shifted to
xhdpi. We don't supply an xxhdpi icon at all for any of the icons in the top bar
of the menu, hence that size is removed (and reused for the xhdpi icon, see above).
MozReview-Commit-ID: 7fabPQ5Tyst
--HG--
extra : rebase_source : 5ef599a8a8a2d2a34555169ab0f56d98f0bc1ab6
extra : amend_source : 620947076e7bf4b02a5c3566240a28dc5d9de2c5
extra : source : e6d92ec5cc178d771a0ef2350a653795cdd198e1
This patch adds a "Read now" action to content notifications. Clicking the button
will behave like clicking the notification. However it will send a different telemetry
extra ("content_update_read_now" instead of "content_update").
MozReview-Commit-ID: 4O24xBhjVF4
--HG--
extra : rebase_source : 4bfb9b714b42f0a0259770e054701a3d4592aa87
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
