Commit Graph

159 Commits

Author SHA1 Message Date
Masayuki Nakano
2d19d947df Bug 1502795 - Set keyCode or charCode of keypress event whose value is zero to the other's non-zero value by default again unless dispatched on known broken web apps r=smaug
This patch re-enables the new behavior of bug 1479964, to set keyCode or
charCode of keypress event whose value is zero to the other's non-zero value.

However, some web apps are still broken with the new behavior.  Therefore,
this patch adds a blacklist to keep using our legacy behavior in some specific
web apps.

Note that Google Docs, Gmail and Remember The Milk are reported as broken.
However, I don't see any broken shortcut with Gmail.  Therefore, this patch
adds only Google Docs and Remeber The Milk into the blacklist.

Differential Revision: https://phabricator.services.mozilla.com/D10322

--HG--
extra : moz-landing-system : lando
2018-11-07 06:39:10 +00:00
Gijs Kruitbosch
861a81e403 Bug 1358813 - avoid flushing layout when notifying IME of focus events, r=masayuki
Differential Revision: https://phabricator.services.mozilla.com/D8007

--HG--
extra : moz-landing-system : lando
2018-10-11 13:06:52 +00:00
Masayuki Nakano
339308fcab Bug 1343955 - part 4: Implement static API to synthesize keyboard events into FuzzingFunctions r=smaug
Synthesizing keyboard events is dangerous and such API is requested only by
fuzzing test.  So, we should add it into FuzzingFunctions which is built
only when |ac_add_options --enable-fuzzing| is specified and enabled by
the pref.

This patch implements the API as synthesizing keyboard events in the focused
widget and the synthesized events are propagated as native key events except
APZ (because keyboard events are synthesized only in the process).  This
behavior allows to test including any default action handlers such as
EventStateManager and setting WidgetGUIEvent::mWidget since some C++ handler
checks if it's nullptr.

Differential Revision: https://phabricator.services.mozilla.com/D5516

--HG--
extra : moz-landing-system : lando
2018-10-02 12:16:45 +00:00
Masayuki Nakano
eb2efb612f Bug 1343955 - part 2: Implement _guessCodeFromKeyName() in EventUtils.js with C++ and make it accessible with nsITextInputProcessor for EventUtils.js r=smaug
We need to port synthesizeKey() of EventUtils.js to FuzzingFunctions.  So,
its helper function, _guessCodeFromKeyName() in EventUtils.js needs to be
accessible from FuzzingFunctions.  Therefore, we need to reimplement it
with C++ and make it accessible via nsITextInputProcessor for EventUtils.js
for making easier to maintain.

This patch moves _guessCodeFromKeyName() into TextInputProcessor and
WidgetKeyboardEvent.  Non-printable key part of _guessCodeFromKeyName() is
moved to WidgetKeyboardEvent::ComputeCodeNameIndexFromKeyNameIndex() because
of not depending on active keyboard layout.  On the other hand, printable
key part needs to assume that active keyboard layout is en-US keyboard layout.
Therefore, it's moved to
TextInputProcessor::GuessCodeValueOfPrintableKeyInUSEnglishKeyboardLayout()
because any Core code shouldn't refer it as utility method for keeping that
we're i18n-aware.

Differential Revision: https://phabricator.services.mozilla.com/D5514

--HG--
extra : moz-landing-system : lando
2018-10-03 09:21:47 +00:00
Jeff Gilbert
5b753da289 Bug 1470325 - s/FooBinding/Foo_Binding/g - r=qdot
MozReview-Commit-ID: JtTcLL5OPF0
2018-06-26 17:05:01 -07:00
Andi-Bogdan Postelnicu
8cc8f8b517 Bug 1453795 - Widget - Initialize member fields in classes/ structures. r=jimm
--HG--
extra : rebase_source : 594fe9396c450401fab4c17e81a3333124f27f58
2018-06-15 17:48:51 +03:00
Masayuki Nakano
a20855c9f5 Bug 1441821 - NativeKey shouldn't mark eKeyDown and eKeyPress as "skippable in remote process" if message is not caused by physical key press r=m_kato,smaug
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process.  However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.

So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat.  For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.

On Windows, there are two ways to generate keyboard input messages.  One is
using SendMessage() or PostMessage().  The other is SendInput() API.  In both
ways, utils can make their input as repeated key messages.

The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.

On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags.  Otherwise, only first call is
treated as non-repeated event.

So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.

MozReview-Commit-ID: 3rinrOjx8Tf

--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
2018-06-06 23:35:16 +09:00
Masayuki Nakano
80b5c54449 Bug 1464016 - TextInputHandler should not clear alt/ctrl/meta modifiers of eKeyPress event before sending TextEventDispatcher r=m_kato
If a key combination causes text input, we need to dispatch keypress
events without alt/ctrl/meta modifiers since TextEditor won't handle
keyepress events whose altKey, ctrlKey or metaKey is true as inputting
text.

Currently, TextEventDispatcher sets mCharCode of eKeyPress event from
mKeyValue.  Then, when altKey, ctrlKey or metaKey is true, it'll call
WillDispatchKeyboardEvent() and then, TextInputHandler needs to reset
the charCode value from native event information.

However, the problem is, TextInputHandler::InsertText() is called
with control character when control key is pressed and InsertText()
clears the modifier information before sending eKeyPress event to
TextEvenDispatcher so that TextEventDispatcher won't call
WillDispatchKeyboardEvent() even though control key is actually
pressed.  Therefore, TextInputHandler cannot adjust charCode value
and modifier flags in some cases such as control + option + 'a'.

This patch makes InsertText() stop clearing the modifiers and
makes WillDispatchKeyboardEvent() do it instead.  This procedure
is expected by TextEventDispatcher.

MozReview-Commit-ID: Ig6qgRBeQDh

--HG--
extra : rebase_source : 446e8af0e921946f3409d26ede70446248317673
2018-05-24 20:59:48 +09:00
Masayuki Nakano
1d38d6b282 Bug 1458845 - Make TextEventDispatcher dispatch keypress event even if altKey is true on macOS r=smaug
On macOS, option key is mapped to alt key, and it works like AltGr key on
the other platforms.  Since our editor doesn't accept keypress events as
typing printable character if one of altKey, ctrlKey and metaKey of the
events is true, widget for macOS sets those attributes to false when an
editor has focus.  On the other hand, if no editor has focus, our widget
does not do this hack so that altKey and ctrlKey values of keypress events
are always same as actual user operation and this is same behavior as the
other browsers.  Therefore, we need to keep setting altKey of keypress
events to true if no editor has focus but we need to dispatch keypress
events even on content unless the charCode is 0.

So, only on macOS, WidgetKeyboardEvent::IsInputtingText() does not need
to check altKey state.

MozReview-Commit-ID: 4DMgdOfLqvQ

--HG--
extra : rebase_source : 18db91c0d77c6910a206e6c767e6f3b5cfd1c2ab
2018-05-23 22:27:17 +09:00
Sebastian Hengst
0819f35e51 Backed out 4 changesets (bug 525063) on request from Andi. a=backout
Backed out changeset 516c4fb1e4b8 (bug 525063)
Backed out changeset 6ff8aaef2866 (bug 525063)
Backed out changeset bf13e4103150 (bug 525063)
Backed out changeset d7d2f08e051c (bug 525063)
2018-04-13 16:01:28 +03:00
Tristan Bourvon
a3a77c0312 Bug 525063 - Initialize uninitialized class attributes in m-c. r=ehsan 2018-04-10 21:11:02 +02:00
Masayuki Nakano
ed18f14624 Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable.  However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.

However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code.  So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.

This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0.  This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux.  In other words, we cannot improve
compatibility with web applications which don't support Firefox  by this patch
since our keyCode values are really different from Chrome's.  So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.

Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode.  This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.

MozReview-Commit-ID: As289r9wp6i

--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
2018-02-16 15:54:07 +09:00
Masayuki Nakano
2a6bd77194 Bug 1438133 - Ctrl + Enter should cause keypress event even though the key combination doesn't input any character r=smaug
Currently, we dispatch keypress event when Enter is pressed without modifiers
or only with Shift key.  However, the other browsers dispatch keypress event
for Ctrl + Enter in any platforms even if it doesn't cause any text input.
So, we should fire keypress event for Ctrl + Enter even in strict keypress
dispatching mode.

Note that with other modifiers, it depends on browser and/or platform.
So, anyway, web developers shouldn't use keypress event to catch
Alt + Enter, Meta + Enter and two or more modifiers + Enter.

MozReview-Commit-ID: 3uUMkhL5VfJ

--HG--
extra : rebase_source : 8149acd958b238c8216f683a42fa05c3cf24570a
2018-02-14 21:21:18 +09:00
Boris Zbarsky
53daea632f Bug 1436508 part 9. Remove nsIDOMKeyEvent::DOM_KEY* constants. r=masayuki
MozReview-Commit-ID: JXCCrbaMcn
2018-02-09 11:17:09 -05:00
Masayuki Nakano
e43e597a9e Bug 1433101 - part 2: Treat Enter and Shift+Enter as printable key r=smaug
Chromium dispatches a keypress event when pressing Enter or Shift+Enter.
Actually, when user press them in <pre> element of HTML editor, ツ・n is inserted.
It makes sense to treat the key combinations as inputting text.

MozReview-Commit-ID: Hvx87MZtZkn

--HG--
extra : rebase_source : 196b63843ebcb6e4b398f6b21a4f5f1d020b8db3
2018-01-25 23:59:20 +09:00
Masayuki Nakano
082c64aa0c Bug 1433101 - part 1: Add new pref which disables keypress event for non-printable keys only for the default event group in web content r=smaug
UI Events declares that keypress event should be fired when the keypress event
causes some text input.  However, we're keeping our traditional behavior for
historical reasons because our internal event handlers (including event
handlers of Thunderbird) handles keypress events for any keys.  Therefore,
for minimizing the side effect, we should stop kicking keypress event handlers
in the default event group in web content.

This patch adds new pref for enabling the standard behavior in web content.

Additionally, creates WidgetKeyboardEvent::IsInputtingText() for sharing the
check logic between TextEventDispatcher and TextEditor/HTMLEditor.

MozReview-Commit-ID: 3rtXdLBPeVC

--HG--
extra : rebase_source : 2fc3c9a09840d0d03800c9a42bb83ca76a8db2d5
2018-01-25 23:27:07 +09:00
Eric Rahm
07c97a5afe Bug 1423773 - Part 1: Remove usage of nsStringGlue.h. r=glandium
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.

--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
2017-12-06 16:52:51 -08:00
Brendan Dahl
c161ff02d7 Bug 1409580 - Support edit command mapping in headless MacOS. r=masayuki
Extracts out the creation of an NSEvent from a WidgetKeyEvent in
TextInputHandler.mm into generic helper method. The helper is used by headless
to create a fake NSEvent to then build edit commands from key events.

Fixes:
- test_selectevents.html
- test_bug756984.html
- test_movement_by_characters.html
- test_movement_by_words.html
- test_backspace_vs.html
- test_bug1094000.html
- ... many key event tests

MozReview-Commit-ID: 1Jur5MHOrkp

--HG--
extra : rebase_source : fbe320aff8fd2e1b36f3b46e02336e9fc89c48d0
2017-10-13 17:40:27 -07:00
Masayuki Nakano
44d5a33919 Bug 1333459 - part2-2: EventStateManager should check if it needs to wait reply from remote content before handling access keys r=smaug
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager.  So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.

When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget.  However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet.  Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed.  When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed.  So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.

This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey.  If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.

Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.

MozReview-Commit-ID: KsOkakaIVzb

--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
2017-07-22 10:50:41 +09:00
Masayuki Nakano
6c68caecd7 Bug 1333459 - part1: Move methods of EventStateManager which check modifiers of access key to WidgetKeyboardEvent r=smaug
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.

MozReview-Commit-ID: 23NUQ51lJ1M

--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26
2017-07-06 17:36:19 +09:00
Masayuki Nakano
57f359b0de Bug 1377653 - part2: Add helper methods to WidgetEvent and BaseEventFlags to manage propagation state between parent process and remote process r=smaug
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process.  However, it's really complicated.  Actually, setting these flags and referring the flags is usually follow explanation.

So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.

This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome.  That allows us to manage the cross process event propagation state in same place.

MozReview-Commit-ID: IXEDQJ4GpAZ

--HG--
extra : rebase_source : 5b63ac4f1d15e40e8bfc88423e336de28caa8ab6
2017-07-05 13:58:41 +09:00
Masayuki Nakano
f51d22ebb9 Bug 1377653 - part1: Get rid of WidgetKeyboardEvent::mInputMethodAppState r=smaug
WidgetKeyboardEvent::mInputMethodAppState was used by B2G for managing keyboard event propagation state between chrome process and IME process.  Therefore, we can remove it now.

MozReview-Commit-ID: 7BwvzE8VjIR

--HG--
extra : rebase_source : 99e19fee6af0be1de19bd6c23e57e7dbf83a4a9c
2017-07-01 16:19:40 +09:00
Ryan Hunt
710c2e9481 Bug 1351783 part 4 - Add a KeyboardShortcut type. r=kats,masayuki
Keyboard scrolling works by first dispatching a key event to the focused element
of the page. It is then caught by a XBL binding put on the chrome event handler of
every window. The XBL binding searches through all of its handlers to find one
that can handle the keyboard event. The matching binding has a command string
which is dispatched to the nsGlobalWindowCommands which dispatches to PresShell
which does the actual scrolling.

To do this asynchronously, we need a representation of the XBL handlers that can
be applied to a KeyboardInput to get a KeyboardAction.

This commit adds KeyboardShortcut for this purpose. KeyboardShortcut is designed
to be compatible with nsXBLPrototypeHandler and to only handle the specific cases
we care about for keyboard scrolling. If a XBL handler runs javascript or does
anything else we cannot handle in an OMT situation, then we create a
dispatch-to-content KeyboardShortcut.

MozReview-Commit-ID: 1qzywS3QHVp

--HG--
extra : rebase_source : 8ea4f85c02d04ce5e0fa6e430c44ac920269dd9f
2017-06-05 18:24:35 -05:00
Ryan Hunt
e747db20e3 Bug 1351783 part 2 - Add a KeyboardInput type. r=kats
Every event type handled by APZ needs to have a InputData type. This commit
adds a new KeyboardInput type that stores the minimum fields needed to match
keyboard shortcuts.

MozReview-Commit-ID: 3KUnH4sWrST

--HG--
extra : rebase_source : 710274199a1ced0716abe02e9d6aaea0d31c9498
2017-06-05 18:09:40 -05:00
Ehsan Akhgari
4eac977034 Bug 1373857 - Part 3: Optimize the PostHandleEvent() events that we dispatch for checkboxes and radiocontrols when they get toggled in order to make it use direct WidgetEvent dispatch; r=smaug 2017-06-20 13:59:52 -04:00
Masayuki Nakano
85a1d561a2 Bug 1339543 part 6 PBrowser::RequestNativeKeyBindings() should retrieves edit commands only for specified type r=smaug
PBrowser::RequestNativeKeyBindings() is used only when somebody tries to
execute native key bindings for synthesized keyboard events.  Therefore, it
doesn't need to retrieve edit commands for all editor types.  Instead, it
should take the editor type and just return the edit commands for it.

MozReview-Commit-ID: HF4Gz99SBQP

--HG--
extra : rebase_source : e332d2ef5ae36949a9a362d8f95c5d427c9812e7
2017-05-19 18:46:02 +09:00
Masayuki Nakano
872f694c63 Bug 1339543 part 4 Change nsIWidget::ExecuteNativeKeyBinding() to nsIWidget::GetEditCommands() which just retrieves edit commands for the type r=smaug
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands.  Instead, they need array of edit commands for the key
combination.  So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.

MozReview-Commit-ID: 4G0B1lJ8Lbe

--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
2017-05-19 17:49:41 +09:00
Masayuki Nakano
730193bdb6 Bug 1339543 part 2 eKeyPress event should have edit commands for all editor types when it's dispatched to a remote process r=smaug
When eKeyPress event is dispatched from TabParent to a remote process, it
should store edit command for all editor types.  Then, copied
WidgetKeyboardEvent in the remote process doesn't need to request the edit
commands when its ExecuteEditCommands() is called.

Note that this patch also changes a automated test, browser_bug1316330.js,
that uses nsIDOMWindowUtils.dispatchDOMEventViaPresShell() to dispatch
repeated keyboard events in the tab.  However, it should use synthesizeKey()
to emulate everything of native keyboard events and the API can dispatch
repeated keyboard events too.  (And the test has a bug.  It tries to wait 0.5
sec when every keydown or keypress event.  However, it fails since startTime
is never initialized.  This patch fixes this bug too.)

MozReview-Commit-ID: IYhyxqH3Ch8

--HG--
extra : rebase_source : 0db911e8e6ea7fc537bda76f4cc0f8952cc13dd2
2017-05-19 17:24:20 +09:00
Masayuki Nakano
6d8d004613 Bug 1339543 part 1 Wrap nsIWidget::ExecuteNativeKeyBinding() with a WidgetKeyboardEvent method and users of the method should use it r=smaug
Currently, edit commands for native key bindings are stored in widget.  This is
stateful and really complicated in content process because it needs to cache
them.

We can make this simpler if we make WidgetKeyboardEvent store edit commands for
the key combination.  Then, child process can handle it even if it's delayed
event or it's a nested event.

This patch adds arrays to WidgetKeyboardEvent to store edit commands which are
initialized with nsIWidget::ExecuteNativeKeyBinding() and adds
WidgetKeyboardEvent::ExecuteEditCommands() to execute stored edit commands as
same as nsIWidget::ExecutenativeKeyBinding().

MozReview-Commit-ID: BGRvBrLz5lp

--HG--
extra : rebase_source : b7ecd704d9c331ca1e0aedc66f230114015b853b
2017-05-19 16:50:30 +09:00
Stephen A Pohl
99336e02ef Bug 429824: Properly forward native OSX events to the native menu bar if they haven't been handled by the child process in e10s. r=mstange,masayuki 2017-05-15 22:59:35 -04:00
Masayuki Nakano
87d8470a52 Bug 1347073 Get rid of UIEvent.isChar since it's not initialized properly on most platforms and the other browsers don't support this r=smaug
UIEvent.isChar is not supported by the other browsers and the value isn't initialized any platforms except on macOS. So, the value isn't useful and we have no reason to keep it.

MozReview-Commit-ID: 4BLpo88gSZj

--HG--
extra : rebase_source : ca950f8cb618a0cadc99ba4c80b5a8df94a20f27
2017-03-14 18:29:39 +09:00
Masayuki Nakano
5442d350f3 Bug 1337739 Create an enum eKeyLocation* for avoiding to use nsIDOMKeyEvent::DOM_KEY_LOCATION_* r=smaug
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode.  Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*.  Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.

MozReview-Commit-ID: 5cs4zQ061Lc

--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
2017-02-08 21:04:22 +09:00
Masayuki Nakano
e0dcff15d2 Bug 1322736 part.3 Remove dom::BeforeAfterKeyboardEvent and InternalBeforeAfterKeyboardEvent r=smaug
MozReview-Commit-ID: Eyz2HjIdQEW

--HG--
extra : rebase_source : 182f4f8236dcfb83f8725a9c66cc46dedbb14f2c
2016-12-16 16:25:22 +09:00
Masayuki Nakano
d48cef4255 Bug 1322736 part.2 Remove "after keydown" and "after keyup" events r=smaug
MozReview-Commit-ID: ICFPyDhgfh7

--HG--
extra : rebase_source : 6d3a9d227ac99710ac2daa036e1e169d31ae9e6a
2016-12-16 16:01:51 +09:00
Masayuki Nakano
abc299239b Bug 1322736 part.1 Remove "before keydown" and "before keyup" events r=smaug
MozReview-Commit-ID: 3umPBwTowLc

--HG--
extra : rebase_source : c77a7f4b9334f261623d655edb3bf50377d1804d
2016-12-16 15:59:25 +09:00
Masayuki Nakano
06d6d7a752 Bug 1304620 part.2 ContentCacheInParent should manage if there is pending composition in the remote process r=m_kato
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
2016-10-12 17:09:02 +09:00
Masayuki Nakano
97735168f1 Bug 1297013 part.2 Implement some helper methods to log constants related to event handling r=smaug
This patch implements some helper methods to log constants related to event handling.

ToString(KeyNameIndex) and ToString(CodeNameIndex) converts the enum itmes to human readable string.  They use WidgetKeyboardEvent's helper class which returns Unicode text.  Therefore, this need to convert from UTF16 to UTF8.  That's the reason why these methods don't return |const char*|.

GetDOMKeyCodeName(uint32_t) returns DOM keycode name if it's defined.  Otherwise, returns hexadecimal value.  For generating switch-case statement, VirtualKeyCodeList.h shouldn't include ",".  Therefore, this patch removes "," from VirtualKeyCodeList.h and append it at defining NS_DEFINE_VK.  Additionally, the last item of enum and array should not end with ",".  Therefore, this adds dummy last item at each of them.  Finally, some of the keyCode values are shared between 2 keys.  Therefore, it needs to support NS_DISALLOW_SAME_KEYCODE for switch-case generator.  See the comment in the file for more detail.

GetModifiersName(Modifiers) returns all modifier names included in the given value.

MozReview-Commit-ID: 9i2ftFOTpDn

--HG--
extra : rebase_source : 458a4d28624dc10dd4454f2e7708d746d1fcb045
2016-09-15 00:48:47 +09:00
Masayuki Nakano
d170e03f6c Bug 1286464 part.6 ContentEventHandler::OnQueryCaretRect() should use eQueryTextRect event when it needs to guess the caret rect r=smaug
ContentEventHandler::OnQueryTextRect() is now too complicated. So, we shouldn't duplicate similar code in OnQueryCaretRect(). When it needs to guess a caret rect from a character rect, we shouldn't compute character rect by itself.

MozReview-Commit-ID: 5G4MzQJzmoV

--HG--
extra : rebase_source : 31f2ec578eeb2af82b8af2d938448eb42afd50ea
2016-07-29 00:37:09 +09:00
isangelawu
5362a0f92e Bug 1275473 - Implement CompositionEvent.ranges. r=masayuki, r=smaug 2016-07-26 12:09:07 +02:00
Makoto Kato
689ca97c17 Bug 1203871 - Part 2. Implement eQueryTextRectArray. r=masayuki
It will use on ContentCache.  Also, SetRangeFromFlatTextOffset issue will hanle on another bug.

MozReview-Commit-ID: 9Yu8bLlcZS5

--HG--
extra : rebase_source : c8eba70bdedf303b0fa649c1a609fe6120983e65
extra : histedit_source : 4189807b57ede13c1546e95052fcc298c8581d06
2016-06-23 10:40:04 +01:00
Masayuki Nakano
60bb642e47 Bug 1275528 part.1 Support a way to query content relative to insertion point r=smaug
Native IME handler may want to query content relative to start of selection (or composition if there is it). Additionally, in e10s mode, insertion point in actual content may be different from the cache in parent.  Therefore, in some cases, it does make sense to query content with offset relative to start of selection or composition.

This patch implements it simply and only in non-e10s mode.

Additionally, this fixes a bug of nsQueryContentEventResult::GetOffset() which hasn't been accepted its calls even if the event message is valid (eQueryTextContent, eQueryTextRect and eQueryCaretRect).

MozReview-Commit-ID: 34I7vyTUAgO

--HG--
extra : rebase_source : d79ba0dc3e002f7691495ee1ff8bdb3854d8f6fe
2016-06-16 14:10:49 +09:00
Masayuki Nakano
4e5c167f73 Bug 1275914 part.5 Support special selections at handling eQuerySelectedText r=smaug
TextComposition needs to query first IME selection.  Therefore, we need to add support to query special selection range with eQuerySelectedText.

First, WidgetQueryContentEvent::mInput should have mSelectionType which should be initialized with InitForQuerySelectedText() but unfortunately, there is no method for eQuerySelectedText.  Therefore, this patch initializes WidgetQueryContentEvent::mInit::mSelectionType with SelectionType::eNormal in its constructor.

Next, ContentEventHandler needs to support to handle eQuerySelectedText with special selection types.  However, we need to create 2 paths in some cases, one is for normal selection and the other is for special selections because there are no selection ranges may be usual case for special selections but not so for normal selection.  Therefore, ContentEventHandler::InitCommon() becomes a little bit more complicated.  ContentEventHandler::mSelection and ContentEventHandler::mFirstSelectedRange is initialized with the specified selection type but normal selection type is also necessary to compute the selection root since the selection root is computed from the first selected range which may not be anywhere if its selection type is not normal.

Finally, ContentEventHandler::OnQuerySelectedText() returns "there are no selections" as succeeded case in special selection type cases.

MozReview-Commit-ID: 9WzUx8b5piw

--HG--
extra : rebase_source : fb07b40748b594d36315f1fc21c0a02ff9f668bb
2016-06-21 13:13:11 +09:00
Masayuki Nakano
0e98199ee6 Bug 1254755 part.6 Reorder the members of WidgetKeyboardEvent for reducing its instance size r=smaug
For reducing the instance size of WidgetKeyboardEvent, this patch also explicitly defines the type of KeyNameIndex and CodeNameIndex.

MozReview-Commit-ID: 8Iw2e8ZFOpe

--HG--
extra : rebase_source : 8123d19c30cf525643e7f442013c506de8b67543
2016-05-12 19:18:36 +09:00
Masayuki Nakano
1252a7bf75 Bug 1254755 part.5 Rename WidgetKeyboardEvent::isChar to WidgetKeyboardEvent::mIsChar r=smaug
MozReview-Commit-ID: 58mri5IP3dV

--HG--
extra : rebase_source : fadfc0eb40c2ea9a3a60ba54b0ae7c5cae94f96e
2016-05-12 18:31:05 +09:00
Masayuki Nakano
e2fb1c839c Bug 1254755 part.4 Rename WidgetKeyboardEvent::location to WidgetKeyboardEvent::mLocation r=smaug
MozReview-Commit-ID: CjT7izri6Vq

--HG--
extra : rebase_source : 1e82d581b8bf1cce3d3154402f3bb435f7a004f6
2016-05-12 18:17:22 +09:00
Masayuki Nakano
7bfa8a21fa Bug 1254755 part.3 Rename WidgetKeyboardEvent::alternativeCharCodes to WidgetKeyboardEvent::mAlternativeCharCodes r=smaug
MozReview-Commit-ID: 26K8ZxzavfB

--HG--
extra : rebase_source : 5f74e58a784bae2ed626c0c9f7c992228dcff1be
2016-05-12 17:57:21 +09:00
Masayuki Nakano
8a70a17c6a Bug 1254755 part.2 Rename WidgetKeyboardEvent::charCode to WidgetKeyboardEvent::mCharCode r=smaug
And mCharCode shouldn't be compared with NS_VK_*, nsIDOMKeyEvent::DOM_VK_*. Additionally, when it's compared with a character constant, cast isn't necessary.

MozReview-Commit-ID: JMT614copjG

--HG--
extra : rebase_source : 69ee3c589e5a71c814ec9a40ac3aab39c789c11d
2016-05-13 16:06:18 +09:00
Masayuki Nakano
3359bad586 Bug 1254755 part.1 Rename WidgetKeyboardEvent::keyCode to WidgetKeyboardEvent::mKeyCode r=smaug
And also WidgetKeyboardEvent::mKeyCode should be compared with NS_VK_* rather than nsIDOMKeyEvent::DOM_VK_*.

MozReview-Commit-ID: IKjQ1nr8XYe

--HG--
extra : rebase_source : 83125cd2523f6b70759f621470aad23b00aae8ae
2016-05-12 17:13:49 +09:00
Neil Deakin
405358d4b3 Bug 1101975, handle access keys in content process before menus, r=masayuki 2016-05-11 08:56:42 -04:00
Stone Shih
547b61eae3 Bug 386743 - Set default event bubbling/cancelable flags in the WidgetEvent constructor. r=smaug 2016-04-13 14:16:42 +08:00