Use a separate delete command for deleting text, because using regular
composition events for deleting text doesn't seem to work well in
Facebook comment boxes.
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.
Expand RemoveIMEComposition with a flag to allow canceling the
composition. Also, remove the "ideographic space" hack from before
because it's no longer applicable (the test remains so we can catch
any regressions).
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.
This follows the same approach of considering block flow for all widgets
(in addition to resizers) as done for other toolkits in
https://hg.mozilla.org/mozilla-central/rev/4a65cacf8a37#l3.10
MozReview-Commit-ID: Ca3SMs1k2Tj
--HG--
extra : rebase_source : 9845e676aa2db5eecd222b7e8a678b2aecca659e
Since aUri is nullptr, Firefox will crash on shutdown.
MozReview-Commit-ID: E5ENWsjK7Px
--HG--
extra : rebase_source : d52a301ec0d313f303a98f1d463f9f1120ea44c8
TextInputHandler::InsertText() dispatches a set of composition events when a key press causes 2 or more characters (Note that InsertText() is typically called only when IME is available because it's called via [NSResponder interpretKeyEvents]). However, this is different from the behavior of Windows. On Windows, NativeKey dispatches two ore more eKeyPress events in this case.
So, for consistency between platforms, TextInputHandler should dispatch eKeyPress events in such case.
MozReview-Commit-ID: EMvaL7sklKf
--HG--
extra : rebase_source : 0309d32d692a2394f53cd59216c6e774068e452b
This converts |nsITransferable.flavorsTransferableCanExport| and
|nsITransferable.flavorsTransferableCanImport| to return a |nsIArray|.
|nsIFormatConverter.getInputDataFlavors| and
|nsIFormatConverter.getOutputDataFlavors| are updated as well.
The Gtk 3.20 scrollbars has moved towards usual box model. The scrollbar,
trough,thumb and scrollbar button can now have margin, padding and border set,
different for each direction (ie. left, right, bottom, top). The scrollbar
metrics become ignored in Gtk 3.20 and later.
* Draw scrollbar element [for GTK 3.20+]
* The border for scrollbar, trough, thumb and scrollbar buttons is newly
calculated as margin+padding+border [for GTK 3.20+].
* The margin is subtracted for scrollbar, trough and sb buttons during paint
function [for GTK 3.6+]
* All scrollbar widget's borders transfered from
nsNativeThemeGTK::GetWidgetBorder to the moz_gtk_get_widget_border.
* Added helper function NativeThemeToGtkTheme for mapping mozilla's widget type
to the gtk widget type.
* Scrollbar troughs are now drawn even when there is not enough room for
the thumb [GTK 3.20+]
MozReview-Commit-ID: jd2q67gKM1
--HG--
extra : rebase_source : ecc8b85401845113d84c6c5a48219a0c3d4f8de3
This just swaps out the usage nsISupportsArray with nsIArray when opening a
window. |nsIWindowWatcher.OpenWindow| supports both interfaces, so no changes
are needed there.
