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
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
Wes Kocher
Andrea Marchesini
Dylan Roeh
Carsten "Tomcat" Book
Luca Greco
Jim Chen
Phil Ringnalda
Eugen Sawin
Florian Quèze
John Lin
Randall Barker
Mike Conley
suman
Sebastian Hengst
Jan Henning
Tushar Saini (:shatur)
Sebastian Kaspari
Ben Kelly
Zibi Braniecki
Nevin Chen
Alfredo.Yang