Turns out the Facebook comment box doesn't work well if we send
compositions alongside set/remove span events. This patch adds back the
update composition flag, but only sends composition when necessary,
which is only right before we send key events.
Because onImeUpdateComposition is no longer associated with a separate
action, it no longer sends back a reply using AutoIMESynchronize.
When a Gecko text change spans larger than our original request, we have
to do the replacement in parts in order to preserve any spans from the
original request. There was a bug where the selection is moved to the
wrong offset after the three replacements. This patch switches the order
of the two replacements and manually fixes up the selection.
For any text changes that originated on the Gecko side, this patch also
splits the replacement into two parts (delete + insert), so that old
composing spans are properly cleared first. This new behavior changes
the expected result for the test added by bug 1051556, so the test is
changed as well.. I think this new behavior is more correct, but if it
results in regressions, we can reevaluate.
Right now we send a "process-gecko-events" message to
GeckoInputConnection in order to wait on Gecko during testing. However,
now we have GeckoThread.waitOnGecko() to do that, so we can just use
that directly.
Under asynchronous IME, when we check text/selection for correctness, we
have to wait for the IC thread to sync the shadow text first. In order
to do that inside the assert methods, we have to move them to inside
InputConnectionTest, so that they can call processGeckoEvents() and
processInputConnectionEvents().
Also, ignore a single newline character, if present, at the end of the
actual text, because it's a side effect of some editing operations in
Gecko (e.g. clearing all text in an HTML editor).
When switching the IC thread from one thread to another, we can no
longer block on the old IC thread waiting for the Gecko thread. However,
we still block on the new IC thread, waiting for the old IC thread to
finish processing any old events.
Sync the shadow text to the current text when the selection or text
changes on the Gecko side, provided we are not in batch mode and if we
don't have pending actions. Otherwise, remember the skipped sync and
re-sync when we exit batch mode and/or finish all pending actions.
We used to flush the Java side text upon receiving the acknowledge-focus
event, at which point the Java side is waiting on the Gecko side.
Because of the async IME refactoring, we can no longer wait on the Java
side, so we have to flush the text early, before sending the first focus
notification. Also, the acknowledge-focus event is no longer needed as a
result.
Our call to InputMethodManager to restart input also has to changed due
to the change in calling sequence between notifyIME and
notifyIMEContext.
Due to async IME refactoring, we no longer need the blocking mechanism
in ActionQueue. As a result of the simplified code, we can remove
ActionQueue entirely and move its code to under GeckoEditable.
ActionQueue.offer() is now icOfferAction().
This patch also makes mText an instance of AsyncText, and change all
accesses to mText to reflect the new async interface, i.e. accesses on
the Gecko thread go through getCurrentText() and the current*** methods,
and accesses on the IC thread go through getShadowText() and the
shadow*** methods.
AsyncText keeps two copies of the text - the current copy on the Gecko
thread that is the authoritative version of the text, and the shadow
copy on the IC thread that reflects what we think the current text is.
When editing the text on the IC thread, the shadow copy is modified
directly, and then the modification is sent to the Gecko thread, which
modifies the current copy concurrently. Depending on what Gecko does to
the text, the current copy may diverge from the shadow copy, but
periodically, the shadow copy is synced to the current copy through
AsyncText.syncShadowText() to make the two copies identical again.
As part of async IME refactoring, we will no longer send composition
updates separately. Instead, composition updates will be integrated into
the set-span and remove-span events, similar to what we already do for
replace-text events.
GeckoEditable implemented GeckoEditableListener because GeckoAppShell
called its methods through GeckoEditableListener, but now we use JNI to
call GeckoEditable methods directly, so GeckoEditable no longer has to
implement GeckoEditableListener.
This change also lets us simplify GeckoEditableListener by making
onTextChange and onSelectionChange no longer have any parameters.
Currently, clearSpans calls are carried out immediately, but that makes
it out of order in relation to other calls, which have to go through
Gecko. This patch fixes this issue.
This will be needed for opening background/private tabs from the highlights menu.
MozReview-Commit-ID: 8wvFuTgl2SP
--HG--
extra : histedit_source : de4024ee986c5a48d9da4206160cf960b1d7bc3c
This flag seems to no longer be needed, and prevents the use of switch statements for resource ID's. It was first introduced for mach based geckoview builds, however geckoview now seems to be built using gradle which is able to invoke aapt to produce better R.java's, resulting in constant Resource ID's in Fennec.
MozReview-Commit-ID: EjWCX4nvlht
--HG--
extra : rebase_source : 3eb30debbc76c39bd8e367bf8709eaaf1592f42a
In the pageAction and browserAction schemas, several methods are
declared with `"async": true` but without a specified callback in the
`"parameters"` object, so callbacks are not allowed. However, when a
callback is proxied, the `ParentAPIManager` will mirror the call by
passing in an extra callback to the proxied API - and break.
This patch fixes the issue by removing uses of async:true. Also for
consistency between the browserAction and pageAction methods, the
methods that were not declared as async have also been marked as async.
MozReview-Commit-ID: JQqzmTUAotB
--HG--
extra : rebase_source : 62d1cbc4843dd6c792318337158e4311f8df94a4
This ensures no white borders around the favicons when on Android 4, no changes
on Android 5. Read FilledCardView for the full background on the border/corner
issue that happens on Android <= 4.
MozReview-Commit-ID: IsBcp7xxwjn
--HG--
extra : rebase_source : c37fbfe63eba9d8af4bc0c7b4d4535a380b6d3bd
Okay, this patch is much bigger than I anticipated. However at this point it is impossible
to separate all the interweaved changes.
* Update sizes and colors
* Use a dynamic number of top sites tiles to adjust to the screen size
* Do not keep references (to possible outdated) Cursors from every top sites page
* Remove unused bottom panel
* Add menu button to highlights items
MozReview-Commit-ID: 2CeEGCOXBKl
--HG--
extra : rebase_source : a780ec20fa6f87520c3418403ae4fe259ff39d69
Update path can be null. In this case we fallback to using the last saved path. However
if this doesn't exist either then we just continue with a null path and eventually crash
the service.
MozReview-Commit-ID: Kuihp496TEo
--HG--
extra : rebase_source : 96e2182571f4b2235b3fea25f449b2dbb3e17bb8
The Android version of TouchDelegate never resets the value of its
mDelegateTargeted, which means that once an event is delegated, future events
can get delegated as well, regardless of whether the event occurs within the
TouchDelegate's bounds. Because of the geometry this is more of an issue with
the (future RecyclerView version of) TabsGridLayout, but it can occur on
TabsLinearLayout as well where we use a TouchDelegate to increase the hit size
of the close button on a tab - once a close button is hit by delegation and the
tab is closed, the next time that tab is recycled it will continue to delegate
ACTION_UP events to the close button (in which case they're silently dropped)
even if the ACTION_DOWN was not in the close button's delegation area.
This commit introduces TouchDelegateWithReset, which is simply an override copy
of TouchDelegate with one extra block (commented in the new class) to reset
mDelegateTargeted on each new gesture received.
MozReview-Commit-ID: 5xrPBAdAK6D
--HG--
extra : rebase_source : d1b9c7a443b0590c63433ea6855c8a1ae0662455
extra : source : 0c267676cb0824d916f398155b0d5b7dec6f346c
Use the index in TabsLayout to specify where a tab was inserted instead of just
replacing the entire tabs list on a tab add.
MozReview-Commit-ID: Feft0RlN97r
--HG--
extra : rebase_source : 1ff47946d9e94d08dfcee34364c65ae7f8c02e7a