The tabs tray is drawn on top of the tab strip, not instead of it, so the tab
strip needs to be updated after tabs are moved in the tabs tray before the tab
strip becomes user-visible again.
This introduces a slight change in behavior: *if* a move (of a tab matching the
privacy state of the tab strip) occurs while the tabs panel is open, the tab
strip will be scrolled to the currently selected tab when the tabs panel is
closed - previously the tab strip maintained its old scroll position if a tab
wasn't closed or added while the tabs panel was open.
MozReview-Commit-ID: Ipy5huthNYB
--HG--
extra : rebase_source : e7a3432cdad104b3cec45eeb798f239ae08dd9b9
Session store will be notified in the next patch.
MozReview-Commit-ID: APTJykdnMF2
--HG--
extra : rebase_source : f3cdd3e5529f470834c32d6ae2289a6d272cba67
A cache to remember the position of the tab that was just moved will be added in
the next commit.
MozReview-Commit-ID: 5V4FSpcJ69Z
--HG--
extra : rebase_source : b81d9f4de6d72244ec314d8edf27397fbe601668
Future commits will update the tabs lists in Tabs and gecko; for now we're just
updating the TabsLayoutAdapter list.
When considering some of the changes in TabsTouchHelperCallback, note that
TabStripView uses the new drag and drop, but not swipe to close.
MozReview-Commit-ID: EEseqmVIZmY
--HG--
extra : rebase_source : 779b8ac3f0f9b7b57f9932205890b564aea86d9d
extra : source : 54bfd72900af26472346f75f9fe50334ed273481
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
When we detect text being deleted from the URL bar via setComposingText while we're displaying an autocomplete suggestion, we clear the autocomplete text and prevent the keyboard's delete from having any effect on the URL bar by returning false.
Some keyboards might not handle this correctly and assume that they've in fact successfully set the new text, so the next time the user presses a key can lead to weird behaviour. As a workaround, we therefore additionally restart the input for affected keyboards.
MozReview-Commit-ID: DucveafL3AB
--HG--
extra : rebase_source : 3ba1701adf7e4e8a03d263a75c04717aadaab663
This patch has multiple changes folded into:
* Remove old highlights query
* Add new query for retrieving recent history to consider for highlights
* First version of highlights ranking implementation
* Add new loader implementation that will return a list of Highlight objects instead of a Cursor
* Modify UI code to work with Highlight objects instead of a Cursor.
MozReview-Commit-ID: Pdx2YxrZKA
--HG--
extra : rebase_source : 495bd97e40270fb15c05d5b5f511d5dcf89fbd1b
Clearing history purges a tab's session history as well. Normally, we only update the navigation button state in the UI for a location change, so now we need to start listening for the appropriate message as well.
BrowserApp has already registered a background thread listener for "Sanitize:ClearHistory" - since this can be called during shutdown as well and their listener is more important (clearing the history DB), we defer to them and redispatch to the UI thread ourselves, so BrowserApp doesn't have to do this during shutdown.
MozReview-Commit-ID: C83mk6Z56Oq
--HG--
extra : rebase_source : 6dc40b1ff816b373783afa6bd34546a961e75571
Bug 1339685 - 1. Support compiling GeckoView aidl from multiple packages; r=nalexander
Specify a list of AIDL files for GeckoView so we can include AIDLs from
multiple packages, and not just those from the org.mozilla.gecko.process
package.
Bug 1339685 - 2. Add AIDLs for GeckoEditable; r=esawin
Add IGeckoEditableParent.aidl and IGeckoEditableChild.aidl for two-way
communication between the parent, which lives in the main process, and
the child, which lives in the main process or a child content process.
Bug 1339685 - 3. Refactor some GeckoEditable code; r=esawin
Auto-generate native constants for the constants in GeckoEditableClient,
instead of keeping a separate set of constants in native code.
Bug 1339685 - 4. Add GeckoEditableChild; r=esawin
Add the GeckoEditableChild class, which is currently only used in the
main process as the interface between the native nsWindow and
GeckoEditable. Eventually, it will be expanded to child content
processes as the interface between the native PuppetWidget and
main process GeckoEditable.
Bug 1339685 - 5. Use GeckoEditableChild from GeckoEditable; r=esawin
Make calls to GeckoEditableChild from GeckoEditable, and remove code
that exists in GeckoEditableChild from GeckoEditable.
Bug 1339685 - 6. Add GetNativeObject member to proxied native calls; r=snorp
Add a convenience function for getting the C++ object that is the target
of the native call.
Bug 1339685 - 7. Use GeckoEditableChild from native code; r=esawin
Make nsWindow and GeckoEditableSupport use GeckoEditableChild for
communication. nsWindow still keeps a reference to GeckoEditable for
switching views.
Bug 1339685 - 8. Updated generated bindings; r=me
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
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
