CreateStyleForWidget() then provides the same behavior with
g_style_context_save() as contexts from widget root style nodes.
MozReview-Commit-ID: 6lRCp3XOoRr
--HG--
extra : rebase_source : ad161eef11e0dc70c8a487c204f109eceac3b1c4
This is necessary to switch from caching GtkWidgets to caching
GtkStyleContexts only.
MozReview-Commit-ID: 6Rwinr4AY8l
--HG--
extra : rebase_source : 930a501b3ecd5f124631e3f96fd6ca7611d078ff
The GtkContainer border-width property defaults to zero. It is not influenced
by theme CSS. While theme engines can theoretically modify default values for
properties of any class, I don't think that is something that needs to be
supported.
Removing this code is necessary to switch from caching GtkWidgets to caching
GtkStyleContexts only.
MozReview-Commit-ID: IxgM8qjfK3a
--HG--
extra : rebase_source : c5c94c19227d7e7d31c4a094bb4fb68f094ddb50
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
Send the size from PMGetAdjustedPaperRect to the child to use as the page size.
Add an Mac implementation of GetEffectivePageSize that returns the adjusted dimensions.
MozReview-Commit-ID: GgTFgBzkxTy
--HG--
extra : rebase_source : 9b6e3200698a695d3ca03f3848060083b8fe4ae6
Currently, when InsertText() which is caused by a key press causes committing composition, it consumes keypress event. However, Korean 2-set IME calls InsertText() two times when there is composition and key press causes inserting another character next to the composition. In this case, current design ignores second InsertText() becuase keypress event is already consumed by the first InsertText() call.
For solving this issue safely, InsertText() should mark current key event as "dispatched composition event". Then, following InsertText() calls should cause composition events instead of keypress events since following event order is too odd:
1. keydown (currently not dispatched by TextEventDisaptcher)
2. compositionupdate
3. compositionend
4. keypress
5. keyup
with the new design this becomes:
1. keydown (currently not dispatched by TextEventDispatcher)
2. compositionupdate
3. compositionend
4. compositionstart
5. compositionupdate
6. compositionend
7. keyup
This is similar to Chromium, although, Chromium includes the second InsertText() call into the first composition, we need to fix it later due to risky.
MozReview-Commit-ID: GL42cU2WIL0
--HG--
extra : rebase_source : 2063c56166f6c9ccee25a74e1d29f94daa6b159c
Bug 1307820 - 1a. Move GeckoApp EventDispatcher to GeckoView; r=snorp
Make it a GeckoView-specific EventDispatcher instead of
GeckoApp-specific, so that GeckoView consumers can benefit from a
per-view EventDispatcher. In addition, a few events like Gecko:Ready are
moved back to the global EventDispatcher because that makes more sense.
Bug 1307820 - 1b. Don't use GeckoApp EventDispatcher during inflation; r=snorp
During layout inflation, we don't yet have GeckoView and therefore the
GeckoView EventDispatcher, so we should not register events until later,
typically during onAttachedToWindow.
Bug 1307820 - 2. Introduce GeckoBundle; r=snorp
The Android Bundle class has several disadvantages when used for holding
structured data from JS.
The most obvious one is the differentiation between int and double,
which doesn't exist in JS. So when a JS number is converted to either a
Bundle int or double, we run the risk of making a wrong conversion,
resulting in a type mismatch exception when Java uses the Bundle. This
extends to number arrays from JS.
There is one more gotcha when using arrays. When we receive an empty
array from JS, there is no way for us to determine the type of the
array, because even empty arrays in Java have types. We are forced to
pick an arbitrary type like boolean[], which can easily result in a type
mismatch exception when using the array on the Java side.
In addition, Bundle is fairly cumbersome, and we cannot access the inner
structures of Bundle from Java or JNI, making it harder to use.
With these factors in mind, this patch introduces GeckoBundle as a
better choice for Gecko/Java communication. It is almost fully
API-compatible with the Android Bundle; only the Bundle array methods
are different. It resolves the numbers problem by performing conversions
if necessary, and it is a lot more lightweight than Bundle.
Bug 1307820 - 3. Convert BundleEventListener to use GeckoBundle; r=snorp
Convert BundleEventListener from using Bundle to using GeckoBundle.
Because NativeJSContainer still only supports Bundle, we do an extra
conversion when sending Bundle messages, but eventually, as we eliminate
the use of NativeJSContainer, that will go away as well.
Bug 1307820 - 4. Introduce EventDispatcher interfaces; r=snorp
Introduce several new XPCOM interfaces for the new EventDispatcher API,
these interfaces are mostly mirrored after their Java counterparts.
* nsIAndroidEventDispatcher is the main interface for
registering/unregistering listeners and for dispatching events from
JS/C++.
* nsIAndroidEventListener is the interface that JS/C++ clients implement
to receive events.
* nsIAndroidEventCallback is the interface that JS/C++ clients implement
to receive responses from dispatched events.
* nsIAndroidView is the new interface that every window receives
that is specific to the window/GeckoView pair. It is passed to chrome
scripts through window arguments.
Bug 1307820 - 5. Remove EventDispatcher references from gfx code; r=snorp
EventDispatcher was used for JPZC, but NPZC doesn't use it anymore.
Bug 1307820 - 6. General JNI template improvements; r=snorp
This patch includes several improvements to the JNI templates.
* Context::RawClassRef is removed to avoid misuse, as Context::ClassRef
should be used instead.
* Fix a compile error, in certain usages, in the DisposeNative overload
in NativeStub.
* Add Ref::IsInstanceOf and Context::IsInstanceOf to mirror the
JNIEnv::IsInstanceOf call.
* Add Ref::operator* and Context::operator* to provide an easy way to
get a Context object.
* Add built-in declarations for boxed Java objects (e.g. Boolean,
Integer, etc).
* Add ObjectArray::New for creating new object arrays of specific types.
* Add lvalue qualifiers to LocalRef::operator= and GlobalRef::operator=,
to prevent accidentally assigning to rvalues. (e.g.
`objectArray->GetElement(0) = newObject;`, which won't work as intended.)
Bug 1307820 - 7. Support ownership through RefPtr for native JNI objects; r=snorp
In addition to direct ownership and weak pointer ownership, add a third
ownership model where a native JNI object owns a RefPtr that holds a
strong reference to the actual C++ object. This ownership model works
well with ref-counted objects such as XPCOM objects, and is activated
through the presence of public members AddRef() and Release() in the C++
object.
Bug 1307820 - 8. Implement Gecko-side EventDispatcher; r=snorp
Add a skeletal implementation of EventDispatcher on the Gecko side.
Each widget::EventDispatcher will be associated with a Java
EventDispatcher, so events can be dispatched from Gecko to Java and vice
versa. AndroidBridge and nsWindow will implement
nsIAndroidEventDispatcher through widget::EventDispatcher.
Other patches will add more complete functionality such as
GeckoBundle/JSObject translation and support for callbacks.
Bug 1307820 - 9. Implement dispatching between Gecko/Java; r=snorp
Implement translation between JSObject and GeckoBundle, and use that for
dispatching events from Gecko to Java and vice versa.
Bug 1307820 - 10. Implement callback support; r=snorp
Implement callback support for both Gecko-to-Java events and
Java-to-Gecko events.
For Gecko-to-Java, we translate nsIAndroidEventCallback to a Java
EventCallback through NativeCallbackDelegate and pass it to the Java
listener.
For Java-to-Gecko, we translate EventCallback to a
nsIAndroidEventCallback through JavaCallbackDelegate and pass it to the
Gecko listener. There is another JavaCallbackDelegate on the Java side
that redirects the callback to a particular thread. For example, if the
event was dispatched from the UI thread, we make sure the callback
happens on the UI thread as well.
Bug 1307820 - 11. Add BundleEventListener support for Gecko thread; r=snorp
Add support for BundleEventListener on the Gecko thread, so that we can
use it to replace any existing GeckoEventListener or NativeEventListener
implementations that require the listener be run synchronously on the
Gecko thread.
Bug 1307820 - 12. Add global EventDispatcher in AndroidBridge; r=snorp
Add an instance of EventDispatcher to AndroidBridge to act as a global
event dispatcher.
Bug 1307820 - 13. Add per-nsWindow EventDispatcher; r=snorp
Add an instance of EventDispatcher to each nsWindow through an
AndroidView object, which implements nsIAndroidView. The nsIAndroidView
is passed to the chrome script through the window argument when opening
the window.
Bug 1307820 - 14. Update auto-generated bindings; r=me
Bug 1307820 - 15. Update testEventDispatcher; r=snorp
Update testEventDispatcher to include new functionalities in
EventDisptcher.
* Add tests for dispatching events to UI/background thread through
nsIAndroidEventDispatcher::dispatch.
* Add tests for dispatching events to UI/background thread through
EventDispatcher.dispatch.
* Add tests for dispatching events to Gecko thread through
EventDispatcher.dispatch.
Each kind of test exercises both the global EventDispatcher through
EventDispatcher.getInstance() and the per-GeckoView EventDispatcher
through GeckoApp.getEventDispatcher().
This was needed in GTK2 to get the style of the widget, but styles are almost
independent of widgets with GTK3, where realizing is not necessary to get the
style context.
MozReview-Commit-ID: GtL2FLDl9uA
--HG--
extra : rebase_source : 926e6b7fee9a15fe5c86be7327c60b146db11316
Adds serialization of native print settings values so
that correct page size, scaling, orientation are sent
to the child after the print dialog is displayed.
Changes the Mac print dialog code to load native
print settings from the "print.macosx.pagesetup-2"
pref and ignore what is passed in.
Overwrites the scaling percentage specified in
the print dialog when "Ignore Scaling and Shrink to
Fit Page Width" is checked.
Scaling on Nightly (remote printing) needs more work
to be done in a follow up bug.
MozReview-Commit-ID: B12ZeHuiYFJ
--HG--
extra : rebase_source : baa2a5865b29db8914fca1242af59674f9630c8e
Currently, KeyboardLayout doesn't support chained dead keys because probably, the initial developer didn't expect there are such keyboard layout. Additionally, if we'd try to handle them with KeyboardLayout, it'd need to create too big and too complicated table at loading such keyboard layout. It's really nightmare. Therefore, this patch takes different approach.
Currently, when WM_(SYS)KEYDOWN is received, KeyboardLayout (and NativeKey) respects following WM_(SYS)CHAR. Similarly, this patch makes KeyboardLayout respect WM_(SYS)DEADCHAR when it handles dead key. If WM_(SYS)KEYDOWN is followed by WM_DEADCHAR, that means that the key press is in a dead key sequence and not finishing the existing dead key sequence. Therefore, when WM_(SYS)KEYDOWN is followed by WM_(SYS)DEADCHAR, KeyboardLayout activates dead key sequence.
For supporting dead key chain, this patch makes KeyboardLayout::mActiveDeadKey and KeyboardLayout::mDeadKeyShiftState arrays. When dead keydown message is received, KeyboardLayout appends an item to each of them. (I.e., when the array is not empty, it's in a dead key sequence.)
When WM_(SYS)KEYUP is received, KeyboardLayout checks if it's in mActiveDeadKey. If it's included in the array, it initializes NativeKey as a dead keyup event.
Otherwise, when non-printable key (probably) is received in a dead key sequence, KeyboardLayout doesn't handle it as a part of the dead key sequence. For example, a modifier key may be pressed for next key. (Even if the keyboard layout maps text input to a non-printable key, we can ignore them because such key's KeyboardEvent.key value should be decided only with the virtual keyboard.)
MozReview-Commit-ID: 9n8B0YYuKCO
--HG--
extra : rebase_source : d18ca896829274d35cc8b7744c5e1645a9e78784
Tooltip widget is made in GTK3 as following tree:
* Tooltip window
* Horizontal Box
* Icon (not supported by Firefox)
* Label
Each element can be fully styled by CSS of GTK theme so we have to draw all
elements with appropriate offset and full box model.
MozReview-Commit-ID: E9yYd5UWBu4
--HG--
extra : amend_source : 99539e914e8d3fa07f6bed8a315e40c7d593f277
Vietnamese Telex perhaps referes this result and change its behavior. When typying something, Telex starts composition on Chrome but may not behave so on Gecko.
Fortunately, Chromium just returns some attributes when validAttributesForMarkedText: of NSTextInputClient [1] but it doesn't return these styles when attributedSubstringForProposedRange: of NSTextInputClient is called (always returns non-styled plain text) [2]. Therefore, this patch does not touch IMEInputHandler::GetAttributedSubstringFromRange().
*1 <7d85f23cb0/content/browser/renderer_host/render_widget_host_view_mac.mm (2936)>
*2 <7d85f23cb0/content/browser/renderer_host/render_widget_host_view_mac.mm (3036)>
MozReview-Commit-ID: 1gPIiu4Qbud
--HG--
extra : rebase_source : 5336eea303ee157959941dcc4bda2a0931f1f532
Vietnamese Telex IME handles Backspace key immediately after inputting a word even when there is no marked text. At this time, it tries to replace the word with specific string. In such case, our editor shouldn't remove anything at handling the Backspace keypress event.
For avoiding this issue, InserText() should dispatch a set of composition for inserting the specified text into the range. Then, editor won't perform any action of the key.
Additionally, when a Backspace keydown tries to remove the last character of the word, Telex removes it with a composition. At this time, it creates dummy marked text "a" and make it empty later. So, in this case, InsertText() won't be called, therefore, we need to consume the Backspace keypress when SetMarkedText() is called for preventing removing the previous character of the word.
MozReview-Commit-ID: LfeEHDWn0cZ
--HG--
extra : rebase_source : 4753262ef16bc3875754ae38e966d8512947ad89
This is the first step in using these functions without having a
LayerManagerComposite at all.
MozReview-Commit-ID: 2zkuB7Ox4Ut
--HG--
extra : rebase_source : b23988275f5851a2fd30bd3e8a9931107a224c66
Blink and webkit launch focusin after focus and focusout after blur. Despite
this contradiction with the spec, it is best to mirror this new way, as there
is little guidance or existing code to clarify implementation amiguities that
can arise from the spec.
If focus/blur is fired on a window or document, or the event triggers a change
of focus, do not fire the corresponding focusin/focusout. Otherwise, always
fire the corresponding event.
Additionally, add a mochitest and a w3c-platform-test.
MozReview-Commit-ID: AgQ8JBxKIqK
widget/cocoa/nsAppShell.mm:113:47 [-Wmismatched-parameter-types] conflicting parameter types in implementation of 'nextEventMatchingMask:untilDate:inMode:dequeue:': 'NSEventMask' (aka 'unsigned long long') vs 'NSUInteger' (aka 'unsigned long')
NSWindow's nextEventMatchingMask method expects a parameter of type NSEventMask, not NSUInteger, when building x86_64 with SDK 10.12:
https://developer.apple.com/reference/appkit/nswindow/1419304-nexteventmatchingmask
When using the InjectTouchInput API on Windows, the API requires that the caller
keep providing input frames (by calling the API function) at least every 100ms.
If the caller fails to do so, Windows can return an ERROR_TIMEOUT and throw
away the touch sequence. In some tests, it is hard for us to make this guarantee,
because we need to wait for other events between the touchdown and touchup. For
these tests, we can use the widget-level touch injection code that we have as
a fallback for the OS-level touch injection code. The widget-level touch
injection is less representative of real-world usage but allows us to bypass
the timeout problem.
MozReview-Commit-ID: EoVUSZmERUw
--HG--
extra : rebase_source : 4f7ca1a1e6da4479d51526e8f132f5cb23fceb49
When PC supports table mode, TextInputFramme.dll is loaded and it can be used for TIP.
When creating new TextStore object, selection might be nothing yet on e10s. At this time, GetSelection will return E_FAIL since selection data isn't received yet. If GetSelection returns error during SetFocus, TextInputFrame.dll will crash.
So we set temporary selection to avoid crash.
MozReview-Commit-ID: HyVSwvhXGJh
--HG--
extra : rebase_source : 9e4838ffc5c8d8cf0e67685c6c1da09ecba6c7a9
extra : amend_source : dda79c9380ee34c82a611fc6a6691cbe63aec63c
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 transitionstart and transitionrun event is defined in
editor's draft of CSS Transition Level 2.
https://drafts.csswg.org/css-transitions-2/#transition-events
MozReview-Commit-ID: 6c0GqlaOOPZ
--HG--
extra : rebase_source : 9d16572634a388da25e16096f06087e808ec57ae
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.
Change only right arrows to left arrows when direction is RTL
MozReview-Commit-ID: 3mMCAGCIUYP
--HG--
extra : rebase_source : 54fb3bc6455f2117cb0ddae06c4f895f58204d0f
extra : amend_source : 1398b66e4184c71755801c94ecdc2c22ab961ec0
extra : histedit_source : c17fae6ae45191a685af4274d5a6789fb040d691
The cause of bug 1309515 is, HandleKeyDownEvent() dispatches eKeyPress events even after InsertText() dispatches composition events via InsertTextAsCommittingComposition().
Therefore, this patch consumes the current key event after dispatching composition events.
Note that for consistency with Windows, InsertText() should use eKeyPress events rather than composition events at least in this case. However, changing the behavior has some risk. So, we should fix this bug with the safest hack for uplift.
MozReview-Commit-ID: 7FYR5N2lATe
--HG--
extra : rebase_source : 4485bd76a68567e8c20a84c2fbca78c626f592c5
When ContentCacheInParent receives eCompositionStart, it temporarily sets mCompositionStart to selection start offset. However, if there is a composition in the remote process, the selection start is caret position in the composition string. Therefore, it's not useful information. Instead, the composition start offset should be used because around there are a lot of information.
For that, ContentCacheInParent should always store compostion start offset in the remote process with mCompositionStartInChild even if mWidgetHasComposition is false. And when it receives eCompositionStart, mCompositionStart should be set to mCompositionStartInChild.
MozReview-Commit-ID: DksPNEsi6Ec
--HG--
extra : rebase_source : bcf2946273d24a4c37c33fa18a321660115e3fb6
ContentCacheInParent::mCompositionStart was set to ContentCacheInChild::mCompositionStart without any check. However, that's clearly wrong approach. For example, when the remote process handles some composition events after eCompositionCommit(AsIs) in the parent process, mCompositionStart is valid offset even after mWidgetHasComposition is set to false. Similarly, even after parent process sends eCompositionStart, the remote process may send invalid offset for mCompositionStart due to no composition in it.
For solving this issue, ContentCacheInParent should check mWidgetHasComposition.
If it's true and coming offset is valid, let's use it (even if mPendingCompositionCount is 2 or bigger since widget shouldn't use WidgetQueryContentEvent when there are some pending events).
If the coming offset is invalid but mWidgetHasComposition is false, let's use selection start instead because HandleQueryContentEvent() can work around selection start offset only.
Otherwise, i.e., mWidgetHasComposition is false, we should always set mCompositionStart to invalid offset.
MozReview-Commit-ID: IONU0Cbhpil
--HG--
extra : rebase_source : 05ae9eb0e7a0bb63b65be7a54103eb798274c8ff
When ContentCacheInParent receives content information from the remote process, it notifies TextComposition of the latest composition start offset in the remote process. However, the information may be older composition's, i.e., the composition was already committed in the process but is still being handled by the remote process. TextComposition shouldn't work with such obsolete information.
Note that TextComposition instance is created and destroyed when WidgetCompostionEvent is handled by IMEStateManager. Then, TextComposition instance guarantees that all following composition events for a composition are sent to same EventTarget (including TabParent). So, TextComposition is always synced with a composition in widget.
MozReview-Commit-ID: 78NuvpE2rPx
--HG--
extra : rebase_source : 3ffbf2513750f4b940bfedd19a8b191f28611115
If the remote process is busy or user restarts composition too quickly, there could be 2 or more compositions in ContentCache. For managing such case, ContentCacheInParent should manage the pending composition count which is increased at dispatching eCompositionStart event to the remote process and decreased at receiving eCompositionCommit(AsIs) event from the remote process.
MozReview-Commit-ID: KbTsK20NEZD
--HG--
extra : rebase_source : 428b14646ccde190b446b5c820e0e84866a855f2
For making the meaning of ContentCacheInParent::mIsComposing clearer, let's rename it to mWidgetHasComposition. It becomes true when the parent process sends eCompositionStart to the remote process and false when the parent process sends eCompositionCommit(AsIs). So, it represents if the widget (i.e., the native IME handler in the chrome process) has composition.
MozReview-Commit-ID: 5k05IXMgJxw
--HG--
extra : rebase_source : 69be70f22fb9b9dd6125ce390026b0740bd6de8f
Using direction-changed signal, we detect keyboard change for bidi.
When system uses fcitx's IM and ibus's arabic keyboard layout, this signal might fire often when switching layout and gdk_keymap_get_direction might return invalid bidi information. But I think that this is rare issue. Most users don't use Firefox Arabic version (it means that bidi.browser.ui = true) with ibus Arabic layout and fcitx CJK IM. Since there is no GTK3 API to get current IM module, I cannot find workaround for this.
MozReview-Commit-ID: DL8uUXJFWYz
--HG--
extra : rebase_source : a93e8969b878d01048726e03b24f362ead7e2059
Similarly, NativeKey is a stack class and mFollowingCharMsgs which stores following char messages of WM_(SYS)KEYDOWN should be AutoTArray for preventing to use heap at handling inputs with usual keyboard layout.
5 is enough size for handling usual keyboard layout because we support only 5 or less characters per dead key sequence.
MozReview-Commit-ID: IphcIOmPW0C
--HG--
extra : rebase_source : 74ce6f9fef73df4b9bbccbbdd713470ff7357889
Fortunately, UniCharsAndModifiers instances are only in stack. Therefore, we can make it a stack class and use nsAutoString and AutoTArray for not using heap at handling inputs from usual keyboard layouts.
MozReview-Commit-ID: 9ZPbdjGst64
--HG--
extra : rebase_source : 06a21c20575747591c6bf1a55dff7e6e38884333
Now, we have an security issue. mCommittedCharsAndModifiers may be initialized with multiple WM_(SYS)CHAR messages. However, if it's generated by odd (or malicious) middleware, mCommittedCharsAndModifiers may be overflown because it has only fixed array. For fixing this issue, first, we should hide the members for making the users not depend on the design of UniCharsAndModifiers.
This patch changes UniCharsAndModifiers to a class and hiding mChars and adding |CharAt() const|.
MozReview-Commit-ID: 5EjrIhmCdE4
--HG--
extra : rebase_source : a3dc68998f5f177582addd8587c4da86b2d17b3b
Now, NativeKey respects following WM_CHAR message. Therefore, we can create a test for bug 1293505 which a function key causes a printable character.
Additionally, bug 1307703 is now fixed by the previous patch. So, let's add automated test for it too.
Finally, now, I found a way to test with some keyboard layouts which are not available on old Windows. Therefore, we should add automated tests for bug 1297985 too.
MozReview-Commit-ID: IqCEPbPYrcQ
--HG--
extra : rebase_source : 451d0264f1180cae7d7035a498f1c13416d53246
This patch creates NativeKey::DispatchKeyPressEventsWithRetrievedCharMessages() for dispatching eKeyPress event with mCommittedCharsAndModifiers when it stores following printable WM_(SYS)CHAR messages.
Using loop for dispatching eKeyPress event for every WM_(SYS)CHAR message is wrong because WidgetKeyboardEvent::mKeyValue is initialized with mCommittedCharsAndModifiers and it causes TextEventDispatcher dispatching multiple eKeyPress events at every call of MaybeDispatchKeypressEvents(). Therefore, if mKeyValue is "^^", eKeyPress event is dispatched 4 times --for the first message, eKeyPress events are fired for each "^" and for the second message, eKeyPress events are fired again for each "^"--. Therefore, when it handles WM_(SYS)KEYDOWN and it causes inputting one or more printable characters, it's the easiest way not to use HandleCharMessage().
The new method calls TextEventDispatcher::MaybeDispatchKeypressEvents() only once and it requests to call the callback method with new argument of MaybeDispatchKeypressEvents() when it needs to dispatch 2 or more eKeyPress events. Then, NativeKey::WillDispatchKeyboardEvent() can set each eKeyPress event to raw information of the message and proper modifier state.
With this change, we can dispatch multiple eKeyPress events with retrieved WM_(SYS)CHAR message information rather than retrieved information from active keyboard layout. Therefore, NeedsToHandleWithoutFollowingCharMessages() doesn't return true even when mCommittedCharsAndModifiers stores two or more characters.
FYI: there is a bug in test_keycodes.xul. That is, Alt+'A' of Greek keyboard layout should cause WM_SYSCHAR with a corresponding Greek character but ASCII characters are specified. Therefore, this patch includes the fix of these bugs
MozReview-Commit-ID: JVm7ZJVug0O
--HG--
extra : rebase_source : 414ecbe2c01c53f294d1346414b1a289aa0abfe8
First, mCommittedCharsAndModifiers should be initialized with following char messages because the messages could be different from the information of current keyboard layout.
So, this patch guarantees that mCommittedCharsAndModifiers are same as the user expected when there is one or more WM_CHAR or WM_SYSCHAR messages.
MozReview-Commit-ID: I5Ack0xccoL
--HG--
extra : rebase_source : e4c7af75fd200f30ec52b53dc05f49ae8887c6f0
Karl Tomlinson
Kan-Ru Chen
Stone Shih
Kilik Kuo
Haik Aftandilian
Masayuki Nakano
Randall Barker
David Anderson
James Willcox
Jim Chen
Sylvestre Ledru
Wes Kocher
Carsten "Tomcat" Book
Jan Horak
Petr Sumbera
Jonathan Watt
George Wright
Masatoshi Kimura
Kartikaya Gupta
James Cheng
Sebastian Hengst
Phil Ringnalda
Lee Salzman
Kevin Wern
Chris Peterson
Ryan Hunt
bechen
Dylan Roeh
Adam Velebil
Makoto Kato
Ryan Hunt
Mantaroh Yoshinaga
Dão Gottwald
Neil Deakin
Michelangelo De Simone
KuoE0
Mason Chang
Martin Stransky
stefanh@inbox.com
Markus Stange
Kevin Chen
John Lin
Eric Rahm
Ehsan Akhgari
William Chen
Marcos Caceres
Edwin Flores