Bug 1319660 - 1. Don't take shortcut if old replacement ranges don't match; r=esawin
The block at [1] is a shortcut we take when we reconcile Java text
changes with Gecko text changes. However, we only checked that the new
ranges are the same, i.e. that the new Gecko text is the same as the new
Java text. We should also be checking that the old ranges are the same,
i.e. that the replaced Gecko text is the same as the replaced Java text.
[1] https://dxr.mozilla.org/mozilla-central/rev/bbbd2f7539f224a482cc6d2dd10e6a5f31c8baf3/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoEditable.java#1233
Bug 1319660 - 2. Use previous node instead of sibling when adjusting last node; r=masayuki r=smaug
nsContentIterator in pre mode adjusts its last node if the node is a
childless node like <br>. However, right now it's using GetPrevSibling,
which can lead to error in some edge cases such as:
<p></p><div><br></div>
In this case, if the last node is <br> with offset 0, GetPrevSibling
will return <p> because <p> is <br>'s parent's previous sibling, and the
last node will be set to <p>. However, the correct last node in this
case is <div>, because <br> with offset 0 refers to the position to the
left of <br>, which is <div> with offset 0. In this case, PrevNode
returns the correct <div> value, so we should set the last node to the
result of PrevNode.
For the first node, for a childless node in pre mode, GetNextSibling and
NextNode are the same, so there is no bug in this case. Nevertheless,
this patch changes the call to NextNode to be consistent with calling
PrevNode for the last node.
Bug 1319660 - 3. Add test for correctly adjusting last node in content iterator; r=masayuki
Add a test for the previous patch that makes sure querying selected text
in an edge case works correctly.
Bug 1319660 - 4. Add test for start node regression; r=me
Add a new test case for the NextNode() regression. r=me for trivial
test-only patch.
Bug 1319660 - 5. Restore GetNextSibling call for first node of pre-content-iterator; r=smaug
The last patch changed the `GetNextSibling()` call to `NextNode()`
because I assumed they're equivalent in this case. That turned out to
not be the case because we can reach this line even if the node has
children -- the index just has to be after the last child. So this patch
restores the `GetNextSibling` call to restore the correct behavior.
I also added some comment to clarify that we can reach this line due to
one of two conditions: 1) the node has no children; 2) the node has
children but the index is after the last child.
This patch also replaces the `HasChildren()` check when setting
`cChild`. If the index is after the last child (i.e. index ==
childCount), `GetChildAt()` fails and we erroneously log an assertion
warning, even though the input was valid. The new check handles all
cases whether start node has children or not.
Doing QI from nsIEditor to nsIEditorIMESupport doesn't make sense because editor should always support all methods and attributes of nsIEditorIMESupport (it does NOT mean that all nsIEditor implementation need to support IME).
This patch moves all of them to nsIEditor for avoiding redundant QIs.
MozReview-Commit-ID: DzIKuGHG4iy
--HG--
extra : rebase_source : cc5e9a6ae4572ebe461d9770ffa5c23d33dc8526
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
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
This patch makes NativeKey::HandleCharMessage() stop dispatching eKeyPress event when the message is inputting a control character. NativeKey::HandleCharMessage() runs following cases:
1. WM_KEYDOWN followed by a WM_CHAR message whose wParam is not a control character causes inputting printable characters.
2. WM_CHAR message is received without WM_KEYDOWN message.
So, when HandleCharMessage() is called for a control character, it's unusual case. E.g., another application sends only WM_CHAR message with a control character.
On the other hand, Gecko is the only browser which dispatches "keypress" event even if pressed printable key doesn't cause inputting any characters. And such "keypress" event is used for shortcut key handling and some default action handling. So, even if we stop dispatching eKeyPress event from HandleCharMessage(), it shouldn't affect most users.
Note that this patch does NOT change the behavior when the user inputs a control character with usual keyboard layout such as Ctrl+A of en-US keyboard layout because DispatchKeyPressEventsWithoutCharMessage() dispatches eKeyPress event in such cases.
This patch also adds a lot of tests with Ctrl or Alt state for detecting regressions.
MozReview-Commit-ID: KUNqTp7RDSc
--HG--
extra : rebase_source : f91e37b0b82a8e8a95444a08f6d3101f14fadc50
Currently, Enter and Backspace keys are handled without following WM_(SYS)CHAR message. However, older code needs hack for them for avoiding conflict with Ctrl+J vs. Ctrl+Enter, etc.
So, we can get rid of them now. And when a keydown causes inputting a control character, NativeKey should handle it with keyboard layout (i.e., without following char message(s)).
MozReview-Commit-ID: 6bVuK0BzFbx
--HG--
extra : rebase_source : 08ff45c1990ef8f3ed7703c69b2dc22e5f1dd6f5
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 197b249740056e5c4b7c6f3b556f91f50a838d52
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 8215e56ba1ed9fc54c04eb7ca037b12c3ced5c1b
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 37f78552a1ebba6f61c38add0138b84ddef36c3e
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 0f4bb9193aa06cd7985590636b77a6e2a71ac2e4
eQueryTextRect is used by widget and eQueryTextRectArray is used by ContentCacheInChild. So, matching their result guarantees that widget can get same result both in non-e10s mode and e10s mode. So, the matching should be tested.
MozReview-Commit-ID: 6GfbyvZ9X7H
--HG--
extra : rebase_source : 12511d84cbd94b3f4edf42367a84ee45abc66d9e
There are 2 bugs and this patch fixes them once.
First, NativeKey::WillDispatchKeyboardEvent() is used to setting alternative charCode values for every eKeyPress event. However, for supporting "reserved" shortcut keys, now, it sets alternative charCode values to eKeyDown too. However, they are really different. eKeyPress events are fired for every character to be inputted by a key press sequence. On the other hand, eKeyDown event is fired only once for a key sequence. Therefore, now, NativeKey::WillDispatchKeyboardEvent() needs to set alternative charCode values for all characters inputted by the key sequence to eKeyDown event.
The other is not a new bug. NativeKey::WillDispatchKeyboardEvent() sets the last eKeyPress event's special alternative charCode values, such as unshifted Latin character, shifted Latin character and some character which can be computed from virtual keycode. This is performed when given index is the last index of the longest input string of the key. However, the value includes different shift key state. I.e., when different shift key causes longer text input, NativeKey::WillDispatchKeyboardEvent() won't set the special alternative charCode values to any eKeyPress events. For example, when Ctrl+T is pressed with Arabic keyboard layout, its unshifted input string length is 1 but shifted input string length is 2. Then, eKeyPress event is fired only once, but NativeKey::WillDispatchKeyboardEvent() waits second eKeyPress event.
Therefore, this patch makes the method append alternative charCodes for all remaining characters and detect the last event correctly with mCommittedCharsAndModifiers (it's used for KeyboardEvent.key value of eKeyDown event and the count of eKeyPress events is same as the value's length).
MozReview-Commit-ID: 6adUnmi5KYy
--HG--
extra : rebase_source : 8c04a3a155f2fcb9a5a8b3e9e0a176c678dc6265
Some tests in test_keycodes.xul emulate native key event with printable character even when Ctrl or Alt key is pressed.
With en-US keyboard layout, Ctrl+[A-Z] causes a control character's WM_CHAR message. However, the other OEM keys and numeric keys don't cause WM_CHAR message when Ctrl is pressed. So, we need to fix some wrong emulations in it now.
MozReview-Commit-ID: bhF5XeClnd
--HG--
extra : rebase_source : 16b7c1e725cf8877b2b44f8d7f52e129889ed25f
Since TestWinTSF.cpp isn't available for long time, we should remove it.
Although, we need to create automated tests for native IME handlers, but we should do it in another bug and new frame works should be writable by JS for easier to write tests.
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
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
The scrollbar changes when the test wraps, and so an operation that deletes text until the end of line deletes a different amount of text, and thus affects where the end of line is after the delete.
