We used to scroll in addTab to make sure a new tab created by a close-tab-undo
at the start or the end of the list was made visible instead of staying where it
was created off the edge. We're now taking care of that in selectTab (where it
should have stayed in the first place), where the select in that case occurs
between the time when the new tab is added to the adapter and when the layout
gets updated. In the case where the new tab is at the start, that means the
check 'position < layoutManager.findFirstCompletelyVisibleItemPosition()' in
selectTab reads '0 < 0', which fails (which is why we need the new check for
'position == 0'), but the check 'position >
layoutManager.findLastCompletelyVisibleItemPosition()' for a tab added at the
end reads 'new_lengh -1 > old_length - 1' which already passes, so we don't need
a special case for undo-tab-close adds at the end in selectTab. Tabs added at
the end by a normal "create new tab" still scroll for the same reason.
Robotium was confused by the duplicate 'add_tab' ids from the tab strip and the
tabs panel, so I renamed one of them. Also note that the 'getTabId' added to
TabStripItemView for testing already exists on TabLayoutItemView, but the two
classes don't share a common base.
MozReview-Commit-ID: BzG2r8BSs90
--HG--
rename : mobile/android/tests/browser/robocop/src/org/mozilla/gecko/tests/testTabStripPrivacyMode.java => mobile/android/tests/browser/robocop/src/org/mozilla/gecko/tests/testTabStrip.java
extra : rebase_source : b2859647d9e26cdca24e1b03065d3c62e20f7b1b
extra : source : 119ee2655404e277c13d0e436fba1cad1272797e
For a fresh profile it is expected that there are no session files to restore from, however afterwards we should normally always have a valid - if possibly empty - session file available. We try excluding the first run case by checking the first run pref used by Telemetry so far and see whether we get any reasonable results out of this...
MozReview-Commit-ID: 2ZxmLqwhk32
--HG--
extra : rebase_source : 6e76cad14017aced2e4b5f00b8c385dc544529bf
This pref could be useful for things outside of the TelemetryCorePingDelegate as well, so we have it live in GeckoApp now.
MozReview-Commit-ID: 2JZ3vNqSzcl
--HG--
extra : rebase_source : 0cf6d4f799a705d4e47be89de409925079bf661b
We need this for more than one test, let's have one copy we can call
from wherever it's needed.
MozReview-Commit-ID: Bd0o38KcqQc
--HG--
extra : rebase_source : 3421bc7bf5bd24ce3cec38c9ba198f01e4978575
All TabsLayouts are RecyclerViews now.
* Orientation on a RecyclerView is set on the LayoutManager, not the
RecyclerView;
* android:listSelector doesn't apply to RecyclerView;
* android:choiceMode doesn't apply to RecyclerView.
This patch also fixes bug 1337699 when it removes the old
android:scrollbars="horizontal" in values-land/styles.xml from back when the
tabs tray scrolled horizontally in landscape mode.
MozReview-Commit-ID: 97el99fSi5o
--HG--
extra : rebase_source : 6d5c41be3b217abbd5524f1901193cdca0fc939c
If the user has deactivated search suggestions (either live suggestions from the search engine or those coming from our history), we shouldn't even bother to restart the corresponding loader in that case, so as to avoid
- wasting processing and network resources
- and perhaps more importantly, not leaking the user's search terms to the default search engine if the user doesn't want that kind of suggestions.
At the moment we only exit early from filterSuggestions() when in private mode or if both kinds of search suggestions have been deactivated, but we don't properly handle the case where only one kind of search suggestions has been deactivated.
This should also improve the display of search history results if the user has deactivated the display of live search suggestions, since currently duplicates between the fresh suggestions and the search history are always removed from the latter even when we're not displaying the former.
MozReview-Commit-ID: IOTMLRaZeyP
--HG--
extra : rebase_source : 331c00c83b18c8e9de3cbb00b92df489c04d7bc0
More JPZ leftovers, I presume. In any case what's left doesn't do anything really useful and a DXR search didn't reveal any remaining users, so this can be thrown out.
MozReview-Commit-ID: 9dN6Jifpbvw
--HG--
extra : rebase_source : 04614d729a55e00c5331ecc321ca2ef5b5e73747
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
BatchingDownloader uses provided RepositoryStateProvider instance in order to track
offset and high water mark as it performs batching.
The state holder objects are initialized by individual ServerSyncStages, and prefixes are used to ensure keys
won't clash.
Two RepositoryStateProvider implementations are used: persistent and non-persistent. Non-persistent
state provider does not allow for resuming after a sync restart, while persistent one does.
Persistent state provider is used by the history stage. It is fetched oldest-first, and records are applied
to live storage as they're downloaded. These conditions let use resume downloads. It's also possible to
resume downloads for stages which use a persistent buffer, but currently we do not have any.
Offset value and its context is reset if we hit a 412 error; it is maintained if we hit a sync deadline, allowing us to
minimize number of records we'll redownload. BatchingDownloaderController owns resuming and context checking logic.
High water mark (h.w.m.) is maintained across syncs and used instead of stage's "last-synced" timestamp if said stage is
set to fetch oldest-first and explicitely allows use of a h.w.m. Server15RepositorySession provides correct timestamp
to RecordsChannel, decoupling BatchingDownloader from this logic.
MozReview-Commit-ID: IH28YrDU4vW
--HG--
extra : rebase_source : 63bd7daaa1fd2a63e10289d6d4cd198aaf81498b
Stage re-sync is requested if:
- We hit a 412 either during batching download or batching upload
- We hit a sync deadline either during batching download or when merging records from the buffer
SessionStoreDelegate interface was expanded with onStoreFailed,
indicating that not just a particular record failed, but the whole operation did.
onFetchFailed is used to inform delegates of 412/deadline failures during downloads.
Three new exception types were added, to facilitated messaging between different layers.
MozReview-Commit-ID: Ltdi5noEvdV
--HG--
extra : rebase_source : 9d4af039198b9bc92fbbf25cf8e3d32375a2ab26
This commit does two things:
1) It simplifies history insertion logic, which wrongly assumed that history which was
being inserted might be not new. As such, it was necessary to check for collisions of
visit inserts, record number of visits actually inserted, and update remote visit counts
correspondingly in a separate step, making history insert a three step operation (insert
history record, insert its visits, update history record with a count). However, bulkInsert
runs only for records which were determined to be entirely new, so it's possible to drop
the third step.
2) Makes all of the insertions (history records and their visits) run in one transaction.
Prepared statements for both history and visit inserts are used are used as a
performance optimization measure.
MozReview-Commit-ID: 48T4G5IsQNS
--HG--
extra : rebase_source : 280d468ef9b57163a178e42707aee610977625c4
We're at Sync 1.5 now, so might as well rename the files.
Also, renamed the ConstrainedRepository... to a name that's more reflective
of that session's role after the changes.
MozReview-Commit-ID: 96XCzoBzD5D
--HG--
rename : mobile/android/services/src/main/java/org/mozilla/gecko/sync/Server11PreviousPostFailedException.java => mobile/android/services/src/main/java/org/mozilla/gecko/sync/Server15PreviousPostFailedException.java
rename : mobile/android/services/src/main/java/org/mozilla/gecko/sync/Server11RecordPostFailedException.java => mobile/android/services/src/main/java/org/mozilla/gecko/sync/Server15RecordPostFailedException.java
rename : mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/ConstrainedServer11Repository.java => mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/ConfigurableServer15Repository.java
rename : mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/Server11Repository.java => mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/Server15Repository.java
rename : mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/Server11RepositorySession.java => mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/Server15RepositorySession.java
rename : mobile/android/tests/background/junit4/src/org/mozilla/android/sync/net/test/TestServer11Repository.java => mobile/android/tests/background/junit4/src/org/mozilla/android/sync/net/test/TestServer15Repository.java
rename : mobile/android/tests/background/junit4/src/org/mozilla/android/sync/test/TestServer11RepositorySession.java => mobile/android/tests/background/junit4/src/org/mozilla/android/sync/test/TestServer15RepositorySession.java
extra : rebase_source : 96f7211951611ce7785edbef9dce412accb2878d
Recent history stage will only run if full history stage did not complete yet.
Bug 1316110 tracks follow up work to make this more efficient.
MozReview-Commit-ID: 7dtbfEFUMGB
--HG--
extra : rebase_source : 94a3e652d9dcf7996e14b96aee28810baee078ea
History stage does not wrap history respository in a buffer, because we'd like to
use a high-water-mark and offset resuming later on, and using a persistent buffer
for this stage does not make sense.
MozReview-Commit-ID: FS1swml2bIC
--HG--
extra : rebase_source : be197e0459d86a320076174936cea8ee76e1dbed
Intended to signal that a group of records have been fetched, and more are
to come after a pause.
MozReview-Commit-ID: 8ozZTc6aNdA
--HG--
extra : rebase_source : e2fdf70d6db6e242e65b788dcb6a09f975b5124b
Otherwise we often end up with delegate meaning both fetch delegate and store delegate
in extending classes, which gets a little confusing.
MozReview-Commit-ID: L4Sd79jLr88
--HG--
extra : rebase_source : c8df4e2ea373dd415e1c113ccf37c09e392a5302
