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
Session store will be notified in the next patch.
MozReview-Commit-ID: APTJykdnMF2
--HG--
extra : rebase_source : f3cdd3e5529f470834c32d6ae2289a6d272cba67
Every way I've tried to move a browser in the deck results in the browser being
reset (it loses its docShell and contentDocument). So now we treat
deck.children as a set of browsers instead of a list, and make BrowserApp._tabs
the sole keeper of the user visible tabs list order. That means
deck.selectedIndex should no longer be used to get the user visible index of the
currently selected tab (deck.selectedPanel is still valid), and that all
additions to deck can be appends.
Note if this gets reverted at some later date: there's currently a bug, which
this change renders moot, where we reinsert a close-undo tab correctly in the
_tabs list, but incorrectly append it to the deck instead of inserting it.
MozReview-Commit-ID: Id7FR1p1nfN
--HG--
extra : rebase_source : 1506f513e653c67d066601fb9038bee098be9479
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
The session store keeps a serialised copy of a tab's session history around so that the gathering of the data (which can be somewhat expensive) can be decoupled from writing it to disk.
When the user clears Firefox's history, we therefore need to discard this data as well (except for the currently open entry), so it doesn't stick around until the next time some navigation/history change occurs in that tab. Otherwise, if Firefox or just the tab is closed before the purged state has been re-collected by the session store, the supposedly purged session history will resurface when the tab is restored again.
Bug 1337940 means that we'll now catch the history notifications caused by the session history being purged, however
- we still need to handle zombified tabs separately, since as far as the rest of Gecko is concerned, those simply consist of a plain "about:blank" browser with the true state being stashed away in the session store data, so the purging of the live session history data won't have any real effect
- the history purging on the tab happens after the session store receives the "browser:purge-session-history" notification, meaning that these changes received through the regular history notifications won't get written to disk immediately
Therefore we now explicitly purge the session history data of all tabs in our notification handler, so this state can then immediately be saved to disk.
MozReview-Commit-ID: KkR0Tif9BBk
--HG--
extra : rebase_source : 5744c88e2871cd873e2484e9688deb53bf8d44f2
It's easy to get a tab's browser, but going the other way round requires always calling getTabForBrowser(), which then additionally has to search each open tab in turn to find the tab with the matching browser.
Also, the browser won't survive tab zombification, so for Part 3 we'll have to start keeping a reference to the tab object anyway.
MozReview-Commit-ID: B2aC7vB0cuj
--HG--
extra : rebase_source : 233b6deec58c0c47640e8a0b597d77324ce66963
Delay-loaded tabs all have browsers pointing to about:blank, so there's not much sense in querying browser.currentURI for them. Instead we read their session data to determine the correct URL, which allows selectOrAddTab to successfully detect duplicate tabs even when they are zombified.
MozReview-Commit-ID: JZ179Y85Ehe
--HG--
extra : rebase_source : bc34d34d501a994ce989c27858cc529b78b5ae3d
Fennec's session store code was forked from Desktop a few years ago. Since then, the Desktop session store code has been refactored and modularised, which allows us to pull in again the bits the are compatible with our session store architecture and don't require any mobile-specific handling.
The handling of session history is such a case - with the exception of the "wyciwyg" filtering, any differences between SessionHistory.jsm and our equivalent in sessionstore.js seems to stem from Desktop bugfixes that were never ported over to our copy of the code.
Switching Fennec's session store over to use SessionHistory.jsm will prevent those sort of errors from occurring again in the future and hopefully simplify the maintenance of the session history code going forward.
MozReview-Commit-ID: Hm0TWTwtPsI
--HG--
extra : rebase_source : 5935c7baeefbd2c75754fe609b684aaf40ee85e9
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
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
BrowserApp's sanitize() function assumed that the Sanitizer would return promises for each sanitization handler, so it could wait for them to resolve before proceeding with shutdown (which was also the assumption behind the patch for bug 1266594). In fact even the Sanitizer expected to do this is well, since it wrapped each of its handling functions within a promise/task/sendRequestForResult. However it turns out that Sanitizer's clearItem function then failed to actually return this promise - apparently ever since this was implemented.
MozReview-Commit-ID: 6hN3UTXUIuV
--HG--
extra : rebase_source : 4971bc02962c817037a565595d3c1cedb0532d76
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
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
Bug 1137567 - 1. Allow dispatching key events during composition; r=esawin
We potentially dispatch key events during composition to provide
compatibility for pages that only listen to key events.
Bug 1137567 - 2. Allow keyboard events in DispatchInputEvent when not on APZ thread; r=rbarker
We use nsIWidget::DispatchInputEvent to dispatch our keyboard events on
the Gecko thread, which on Android is not the APZ controller thread. We
should allow these events to pass instead of crashing.
Bug 1137567 - 3. Add GeckoEditableSupport class to support TextEventDispatcher; r=masayuki
Add a separate GeckoEditableSupport class, which implements
TextEventDispatcherListener and uses TextEventDispatcher for IME
operations. The new class is entirely separate from nsWindow to allow it
to be independently used in content processes as well.
Most of the code is copied from nsWindow::GeckoViewSupport, and adapted
to use TextEventDispatcher.
Bug 1137567 - 4. Make nsWindow::WindowPtr available for outside classes; r=snorp
Make nsWindow::WindowPtr available not just for classes inside nsWindow
but for outside classes as well. Also, add support for RefPtr native
objects to nsWindow::NativePtr.
Bug 1137567 - 5. Use GeckoEditableSupport in nsWindow; r=esawin
Use the new GeckoEditableSupport class in nsWindow to replace the
previous code in nsWindow::GeckoViewSupport. GeckoEditable native
methods now go to GeckoEditableSupport instead of GeckoViewSupport.
Several native methods in GeckoEditable are changed from
dispatchTo="proxy" to dispatchTo="gecko", because we no longer need the
special nsWindow::WindowEvent wrapper for our native calls.
Bug 1137567 - 6. Use pushPrefEnv in test_assign_event_data.html; r=masayuki
setAndObserveCompositionPref in test_assign_event_data.html does not
invoke the callback if the pref is already set. This patch changes it to
use SpecialPowers.pushPrefEnv so the callback is always invoked.
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
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
We don't update ToolbarDisplayLayout when it's not ready (i.e. when it's
not attached to a window yet), but when it does become ready, we should
update it to the selected tab, if any.
Changes in the BrowserDB, e.g. because of sync or when opening a link (in a new tab) will trigger the BookmarksLoader's onContentChanged() method, which will trigger a new load reusing the current loader. This means that currently, the code for setting the scroll position in onLoadFinished() gets to run again in that case.
We only want to set the scroll position when the user has navigated to a different folder. Folder navigation will always create a fresh loader, therefore we now keep track whether we've already seen a particular loader in onLoadFinished() and only set the scroll position if we're encountering this particular BookmarksLoader instance for the first time.
MozReview-Commit-ID: Ln8yeUEoEfr
--HG--
extra : rebase_source : a32c33080f56071059898127c19c75e3d32b3a3b
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
Collecting data for history changes causes an additional session store data update for that tab when navigating back, which needs to be accounted for in this test. Therefore we now also wait for DOMTitleChanged before assuming that the tab has navigated to its intended location.
MozReview-Commit-ID: FDNQednXPWh
--HG--
extra : rebase_source : c38b4085eac914bb9a3aa4f0e2b1e04eb3cf1ce3
So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available.
However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state.
To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab.
Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state.
MozReview-Commit-ID: LgHer940QwT
--HG--
extra : rebase_source : a9634be57f3f43e30f42431e8a28846d958534ee
Since we don't want to show the media control for the short sound, so we added the duration checking.
And this checking only needs to be run when the media is active, we don't need to check the inactive media.
MozReview-Commit-ID: AaVGi77nXJ1
--HG--
extra : rebase_source : c565fe64ec4030f0519eb0a8cfe493e95bae4fe4
Since BBC website puts their audio in another iframe, we can't get the media
element to check its duration, so we always return false.
The ideal way to fix it is to get every iframe and check its element, but I think
it's not very easy to do considering the flexibility of using iframe and the cost time.
First, if we want to get the information inside iframe, we need to listen the
onload event, but it's async operation. If there are lots iframe, we need to spend
lots time to wait every iframe. The worst situation is we got the nested iframe,
it would need lots time and effect to wait every iframe loaded and get the element we want.
Therefore, I would prefer the workaround which is to reverse the checking condition,
that is we only check duration for the main window.
MozReview-Commit-ID: F93BjbzRMXO
--HG--
extra : rebase_source : 9409649db241b466967ab1e7f467e177c06c728f
Currently, Recently Closed is displaying the last available history entry for each closed tab instead of the history entry that was actually being shown at the time the tab was closed.
The Java session parser that is responsible for displaying the last session's tabs when not automatically restoring is already doing the correct thing and therefore doesn't need changing.
MozReview-Commit-ID: DGaD52SzdpP
--HG--
extra : rebase_source : 0f11b32d3d8f1061681706272b62dfb090e8e598
Previous state:
- Two threads were racing to get to batchMeta - one to reset its state, and the other to
read its internal state to construct a network request, and then to update its internal state.
- This resulted in data corruption when payloads had to be split into multiple batches.
A core problem was that there is a lot of state shared across thread boundaries. Specifically,
BatchMeta is being written and read both by record consumer threads running off of a thread pool,
and by the network worker thread(s).
This patch refactors BatchMeta and scheduling of network runnables to ensure that cross-thread access
is minimized, and "who owns/accesses what" is explicit.
- PayloadDispatcher owns scheduling payload runnables and any data they need to share between each other.
- UploaderMeta owns information that's necessary to process incoming records.
MozReview-Commit-ID: 9hFs3fXGaGM
--HG--
rename : mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/uploaders/BatchMeta.java => mobile/android/services/src/main/java/org/mozilla/gecko/sync/repositories/uploaders/UploaderMeta.java
rename : mobile/android/tests/background/junit4/src/org/mozilla/gecko/sync/repositories/uploaders/BatchMetaTest.java => mobile/android/tests/background/junit4/src/org/mozilla/gecko/sync/repositories/uploaders/UploaderMetaTest.java
extra : rebase_source : f0f1a05f19f40a6514d4f0dac9d531b086c3f3ed
In phoneRegex, replace '\\s ' (matching a whitespace character) with ' '
since phone number won't contain something like new line or tab.
Also, consider it done if selected text is not changed after calling
Modify().
MozReview-Commit-ID: 2lB9w2gYCOD
--HG--
extra : rebase_source : f2ea498bbd17c1876a9b7f769cbe93cef84520bb
I don't think we ever check this attribute in our code and rely on the presence of "__SS_restore" instead, but we should fix this for consistency and any add-ons or future code that might depend on this.
MozReview-Commit-ID: JwB6kpiKsaR
--HG--
extra : rebase_source : a3c98f4c76a67a8c1a42e1740cf09ab121f8f5b5
By default RecyclerView assumes any item change *might* need animation. It then
creates a new copy of the item that has changed, and interpolates between the two
to "animate" the change. We don't need that for topsites (the RecyclerView's we use
inside each TopSitePanel already animate changes, the overall size doesn't change -
moreover ViewPager state gets lost if you create a new panel), so we override
this behaviour to retain the existing panel. This stops the previously visible
horrible flickering.
(Every time history changes, which can happen if sync is working, or even if a page
finishes loading in the background, the DB is changed, and a reload is triggered.
Prior to this commit, topsites would flicker horribly, and would reset back to the first
topsites page. After this commit the page is retained, and the visible topsites
are rearranged by the inner RecyclerView's animations. You can test this by pinning a
site on the first page, the pinned site will shift to the front, the other sites smoothly
move to the right.)
MozReview-Commit-ID: CnocNfdQ2FS
--HG--
extra : rebase_source : 3a4e1d86c786126aee1e08ab020b855056e4f921
If we clear and recreate pages every time the cursor changes, we'll (A) lose
the current page position and (B) create a new RecyclerView per page, resulting
in flickering. We also need to make sure positioning is correctly handled (i.e. pages
never move, they only get added or removed).
We also switch to an ArrayList: the number of pages will be fixed for most users,
and searching an ArrayList could potentially be slightly faster than with the LinkedList.
There's little advantage to a LinkedList here.
MozReview-Commit-ID: 6NIfc2otQMV
--HG--
extra : rebase_source : 86b51be92c18e791f8049b5c90441370c6bace9a
Use the GeckoService load-libs action to load and extract new libraries
when we receive the update broadcast. This makes us not block the UI
thread to extract libs, and lets Fennec run normally if the user
launches Fennec right after updating.
When GeckoThread is launched without being initialized, it will load all
Gecko libs and then wait until it is initialized, before calling the
Gecko entry point. This allows us to preload Gecko libs without actually
running Gecko.
Some x86 devices set the CPU ABI to ARM (and even change /proc/cpuinfo)
as part of emulating ARM. In that case, we check the kernel release
string find out whether it's really x86 or not.
Compound drawables shift the point where text is "centered". This hack dynamically adds
equivalent padding on the opposite side from a compound drawable, to force the text
to be centered again. (We can't set this padding under all circumstances, it's unneeded
when the text is longer than the available space, i.e. when we wrap text we might
as well use the full width without fake padding.)
MozReview-Commit-ID: 8WDXCNOs2DX
--HG--
extra : rebase_source : d844e71587a7bd78233d88ea209b157a43004e09
Text is currently pushed directly against the pin in those cases
where the entire width is filled with text - this spacing
is needed to separate the pin, and text.
MozReview-Commit-ID: HOVH1SgcrLY
--HG--
extra : rebase_source : cfa33274601c419a39622c081c3e19298d5ff44f
Even if we do the rest of our location change processing only for top level location changes, we still need to update the state of the back and forward buttons even on subframe navigation, so they can become enabled/disabled as necessary.
MozReview-Commit-ID: 2wuFZMKtTfj
--HG--
extra : rebase_source : 6085fee3818b0ce610f2ddca3f8be0657f355916
We used to need these for the back button long press history menu, but now we no longer do.
MozReview-Commit-ID: LAZYffLODN3
--HG--
extra : rebase_source : b6c10e3dc785230d247587b1a34c3b819424db9c
This should be more foolproof than having to remember to use the dedicated setParentId() function when writing to that variable from outside of the tab constructor.
MozReview-Commit-ID: 1KlXf60VsoF
--HG--
extra : rebase_source : 3ae5234a0113b6077a91e873c7a5e5919b162af3
Fix copy & paste error made when creating the new test file.
MozReview-Commit-ID: F0NbwipkX9P
--HG--
extra : rebase_source : 877c2c867235750972ee7865d52376636b0448f6
During a cold startup, depending how this exactly plays out we might receive an application-foreground notification before the browser window is ready. Since the code to restore the selected tab if it has been left zombified while in background is only relevant if Gecko was already running and backgrounded, we can simply add a null check for the window before accessing it.
MozReview-Commit-ID: Ahp5NAODKRF
--HG--
extra : rebase_source : bede266e13f48fbc2f7efd40bb9277be6d2bd3bf
We've been displaying the URL in place of the page title in the toolbar for quite some time now, but still had the old logic in place whereby only title changes would trigger an update of the displayed text. Most of the time this works fine, because
- page navigation usually goes hand in hand with a DOMTitleChanged event, and
- when our loading progress bar stops, we update the displayed text anyway
however a page doing its navigation in-place using some fancy JS logic and the corresponding history APIs etc. can bypass both of these provisions, since it might trigger neither a title change nor a full browser-side page load.
MozReview-Commit-ID: KRrTSmz1xxi
--HG--
extra : rebase_source : ef3c96334ebb44320ffc7f77db0754f78ce0625a
Added support for changing default browser by opening settings screen in API Levels >=24.
MozReview-Commit-ID: 5rxJm6hQQ4A
--HG--
extra : rebase_source : e8fc23bc658e216c04c27e10067c16abf2b0cd5c
There are a number of ways in which we could supply favicons for the default suggested
sites. Reusing the touch tiles has the advantage that it works for both our own suggested
sites, and also distribution-supplied suggested sites. If we were to add yet another
icon source, distribution supplied sites would end up having no nice icon in AS topsites.
The priority ordering of the SuggestedSitePreparer means icons will be overriden as soon
as a site-supplied favicon is available - these icons will only be used up until the point
where a site has been visited.
MozReview-Commit-ID: CHsinHHpfnw
--HG--
extra : rebase_source : a162f5b15e968f382b43505290b0633cbe6e2c7a
In order to allow for a background which merges into a favicon, we
need to allow for solid (non faded) colours. It is simplest to do this
by letting the colour generator (i.e. either the colour extractor,
or the favicon generator) fade the dominant colour as it wishes.
That also means the colour generator can in future choose to
not fade the colour if appropriate.
MozReview-Commit-ID: LsI8PlZsaGn
--HG--
extra : rebase_source : 757f10613a201475edb81afc094f32d5a714ade2
onTabLoad() means we've potentially navigated to a new page, in which case any auxiliary tab data we keep around for the currently loaded page only (form input data, scroll position) would be invalidated and shouldn't be preserved.
Since onTabLoad() can however also be triggered if e.g. just the tab title changed (an additional DOMTitleChanged event), we shouldn't throw away the old data without replacing it with the current state, though. We already do this for the form input data - we need to do it for the scroll position as well.
MozReview-Commit-ID: HG7g6L7htDG
--HG--
extra : rebase_source : 1f7aab26002ee71237dd0a48b872298b39ca7f13
Andrea Marchesini
Dylan Roeh
Carsten "Tomcat" Book
Luca Greco
Jim Chen
Phil Ringnalda
Eugen Sawin
Florian Quèze
John Lin
Randall Barker
Wes Kocher
Mike Conley
suman
Tom Klein
Sebastian Hengst
Jan Henning
Tushar Saini (:shatur)
Sebastian Kaspari
Ben Kelly
Zibi Braniecki
Nevin Chen
Alfredo.Yang
Kris Maglione
Krishna
maliu
Michael Kaply
Jing-wei Wu
Masatoshi Kimura
Grisha Kruglov
Dave Townsend
Andrzej Hunt
Jeff Gilbert
Iris Hsiao
James Cheng
cnevinc
George Wright
Alastor Wu
Himanshi Jain
Xidorn Quan
Ting-Yu Lin
Dale Harvey
Jean-Yves Avenard
Aki Sasaki
Kartikaya Gupta
brainbreaker
Edouard Oger
Christoph Kerschbaumer