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
This is a simple mistake and blocks following patchs' automated tests.
For example, when Alt+Shift+foo doesn't cause text, this returns false even though it should return true.
MozReview-Commit-ID: 91L33vZhouT
--HG--
extra : rebase_source : be7d4e7ad670c1b03e6497c1c313c187ece80c1c
The change from ok() to is() in tests is so that the failure message is
more informative -- it now tells you the returned exception.
This commit omits test_contenteditable_text_input_handling.html because of test
failures that I haven't figured out.
MozReview-Commit-ID: 37cYlQlJZm7
Now, NativeKey::HandleCharMessage() has almost same code, one is for dispatching eKeyPress event for non-printable keys or printable keys when one of Alt or Ctrl key is pressed, the other is for printable keys when Alt or Ctrl key is pressed.
The difference of them is, the former block removes Alt state and Ctrl state for handling AltGr key. When AltGr key is pressed, both Alt and Ctrl state are true. However, EditorBase treas keypress events whose altKey or ctrlKey is true as non-printable key event. Therefore, we need to set these modifier state to false when AltGr key is pressed and the key causes some text.
Note that as far as we know, when a key press with AltGr doesn't cause any characters, WM_CHAR isn't generated. Therefore, we don't need to check with complicated logic if the key event is actually inputting a character.
MozReview-Commit-ID: BRNWfICvkSm
--HG--
extra : rebase_source : 3b8a2aaeb4c53be1567f7a8d17dfef1af90406dd
Current shortcut key handling is really difference from what we did before struggling with "key hell". Therefore, remaining hacks for charCode in NativeKey::HandleCharMessage() are not necessary because they are for old code.
MozReview-Commit-ID: 3hvsBOiJ6VV
--HG--
extra : rebase_source : 7387fc89930f9b15d5d01612eb4a7a5726924bcd
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
Currently, NativeKey::HandleCharMessage() is only a public method and it takes any char message. However, when it's called outside of NativeKey, it should work only with NativeKey::mMsg.
Therefore, we should make current HandleCharMessage() a private method and create new overload method which doesn't take MSG as an argument.
MozReview-Commit-ID: LowV2FUmR3U
--HG--
extra : rebase_source : 271c61515752cf1ea56cf12c4f7ef6f1a90c9cac
NativeKey shouldn't include characters which are provided by WM_SYSCHAR message or WM_DEADCHAR message into mCommittedCharsAndModifiers.
MozReview-Commit-ID: Ax1BmO5wTy0
--HG--
extra : rebase_source : 5d7d1735a783213f7c6a47cca0cadb1d4c5104c0
For consistency with IsPrintableCharMessage(), IsFollowedByNonControlCharMessage() should be renamed to IsFollowedByPrintableCharMessage().
MozReview-Commit-ID: CBJFPO4FZej
--HG--
extra : rebase_source : f5d677743be35a3bb5fca35e7658e907aa46dbcb
Currently, NativeKey::IsFollowedByNonControlCharMessage() returns true only when the first char message is a printable char message. Although, I don't know actual cases coming printable WM_CHAR message after non-printable char message, i.e.,
1. WM_SYSCHAR or WM_DEADCHAR
2. WM_CHAR for a printable character
or
1. WM_CHAR with a non-printable character (a control character)
2. WM_CHAR with a printable character
, we should make it return true because when one or more characters are being inputted, we should ignore non-printable char messages and handle printable char messages in the path handling text input.
MozReview-Commit-ID: 1v7v5mCRFCP
--HG--
extra : rebase_source : f82f7b77376450168bad34be031164ecf7338621
Currently, NativeKey::IsPrintableCharMessage() returns true if given message is WM_CHAR or WM_SYSCHAR. However, WM_SYSCHAR never causes inputting any character and even if WM_CHAR has a control character (i.e., non-printable character), it returns true.
MozReview-Commit-ID: IoU5F06WImz
--HG--
extra : rebase_source : c48f424f3d2960e6e9ceaa6d2fb09952ca634c3f
This guarantees that the runnable will be processed before shutdown leak checking.
MozReview-Commit-ID: B89AcDUWb3y
--HG--
extra : rebase_source : bfbd311fba367c1856cc5d972e6e999ccd4de1ac
Bug 1305498 - 1. Remove NotificationClient task queue; r=sebastian
Not sure why we needed a task queue for NotificationClient actions. The
actions all go through IPC and are non-blocking, so it's perfectly fine
to perform them off of whatever thread we're on.
Bug 1305498 - 2. Integrate NotificationHandler et al into NotificationCllient; r=sebastian
There's no reason to have NotificationHandler, AppNotificationClient,
and ServiceNotificationClient all separate from the base
NotificationClient class. This patch adds the functionality of
those three classes to NotificationClient.
The notifications hash map is changed from a ConcurrentHashMap to a
regular HashMap with synchronization because I think the use case here
doesn't warrant the added performance and overhead of ConcurrentHashMap.
NotificationService is changed to match the new NotificationClient. Now
the only job for NotificationService is to set a notification as
foreground, rather than to manage all notifications like before.
NotificationHandler, AppNotificationClient, and
ServiceNotificationClient will be removed in a later patch.
Bug 1305498 - 3. Set NotificationListener in GeckoApplication; r=sebastian
Set NotificationListener once in GeckoApplication.onCreate, instead of
spreading it out in GeckoApp, BrowserApp, and GeckoService. This is
possible because there's no longer a distinction between
AppNotificationClient and ServiceNotificationClient in the new,
consolidated NotificationClient.
Bug 1305498 - 4. Remove obsolete notification classes; r=sebastian
Remove AppNotificationClient, ServiceNotificationClient, and
NotificationHandler, now that they've all been replaced by the new,
consolidated NotificationClient.
Bug 1305498 - 5. Use NotificationReceiver for web notification callbacks; r=sebastian
Previously, web notification callbacks went to GeckoApp directly, but
that presented some problems such as not being able to implement the
on-close callback, because we don't want to launch GeckoApp when the
notification is closed by swiping. This patch makes us use
NotificationReceiver for callbacks, and let NotificationReceiver launch
GeckoApp if necessary.
Bug 1305498 - 6. Don't keep notification cookie in native code; r=sebastian
Keep the notification cookie a single location (in the notification
intent itself), and simplify the native notification handling code.
Bug 1305498 - 7. Use NotificationReceiver for persistent notifications; r=sebastian
Currently, persistent notification callbacks go through a different code
path, but it'd be more consistent and correct to let persistent
notification callbacks go through NotificationReceiver as well.
This takes care of some housekeeping work that was missing for
persistent notifications, such as deleting the mNotifications entry when
the notification is closed.
When key combination is reserved by the system, web apps shouldn't be able to consume the key events. In such case, we've decided that we never expose the key events in web contents (including chrome contents). Therefore, NativeKey stops dispatching keyboard events only for Alt+Space.
However, new code of the fix of bug 1300003 always consumes WM_SYSCHAR which follows WM_SYSKEYDOWN of Alt+Space. This is the cause of bug 1305943.
For fixing this bug, NativeKey should have a helper method, IsReservedBySystem(), and when it returns true, it should do nothing when Handle*Message() is called and should not consume following WM_SYSCHAR messages at handling WM_*KEYDOWN.
Unfortunately, it's impossible to test this regression because nsDOMWindowUtils::SendNativeKeyEvent() may call nsIWidget::SynthesizeNativeKeyEvent() asynchronously. See <https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#1105-1108>. Therefore, it cannot return if it's consumed.
MozReview-Commit-ID: 9ABh2rYNkFs
--HG--
extra : rebase_source : 7416e45babccce3af795dc523f46dc00fdddc6c7
We usually declare class members with following order:
1. public members
2. private members
3. friends
However, current KeyboardLayout is declared with completely opposite order. Let's use usual order for preventing mistakes.
MozReview-Commit-ID: LwOcEUbJzes
--HG--
extra : rebase_source : 828b5d14f1b38f46e4ae5244d15de68c4db6785c
Currently, checking if it's in dead key sequence directly refers mActiveDeadKey. However, this isn't clear for most developers. So, let's create a helper method, IsInDeadKeySequence(), and wrap the nonintuitive check.
MozReview-Commit-ID: 7qTer9R8Gfs
--HG--
extra : rebase_source : 6ecb20cc3f5e28cfcf41fb33df8603785288bdda
For preventing wrapping long lines, old KeyboardLayout::InitNativeKey() uses two variables |virtualKey| and |isKeyDown| which are never modified. However, they may be not clear for some developers where they came from. Additionally, preceding patches reduced a lot of users of them and indent level. Therefore, even if we remove these variables, we don't need additional line breaks in most cases. So, removing them is better for easier to understand.
MozReview-Commit-ID: 680bYVINPAE
--HG--
extra : rebase_source : 15f4398072ccfe659fc6d2ae95a3f13261efa5af
This patch creates KeyboardLayout::MaybeInitNativeKeyAsDeadKey() for wrapping dead key handling code in KeyboardLayout::InitNativeKey().
This makes InitNativeKey() code simpler. Now, any developers must be able to understand what InitNativeKey() does easier than before fixing this bug.
MozReview-Commit-ID: C59ESUXeTxU
--HG--
extra : rebase_source : c840a0544470ec4081e80c11e050d4dfedef4cad
There is DeactivateDeadKeyState() but not ActivateDeadKeyState(). There should be both of them and hides the dead key state management into them.
MozReview-Commit-ID: JvAPE5f2HVy
--HG--
extra : rebase_source : d7027a1a6b75c6859e79d651d3e9b0136cc09891
VirtualKey::GetCompositeChar() needs index of virtual keycode which may make around the caller messy. So, KeyboardLayout::GetCompositeChar() should wrap it and KeyboardLayout::MaybeInitNativeKeyWithCompositeChar() should use it.
MozReview-Commit-ID: 8KLTJpCFZ8u
--HG--
extra : rebase_source : fd13c009330fd485c8cba30f469fc645b560c623
Similar to VirtualKey::GetUniChars(), VirtualKey::GetNativeUniChars() needs key index. So, it should be wrapped by a new helper method, KeyboardLayout::GetNativeUniCharsAndModifiers(), and KeyboardEvent::InitNativeKey() should use this instead of accessing its member's GetNativeUniChars().
MozReview-Commit-ID: 7M9OlNF698Y
--HG--
extra : rebase_source : e19a5c99014a8f0a0ed7cc3a86fe0c4ee10cebb5
When InitNativeKey() retrieves UniCharsAndModifiers for a key, it needs key index for the given virtual keycode. Therefore, wrapping the code with GetUniCharsAndModifiers() makes InitNativeKey() code simpler since each call specifies the virtual keycode to the method instead of key index.
MozReview-Commit-ID: Azy8chXexaz
--HG--
extra : rebase_source : 98da43e7f542037f952206cd3db731f6cbb097e7
This patch gets rid of |shiftState| from KeyboardLayout::InitNativeKey() and make each caller clearer. This must make other developers understand what modifier state is used at each call.
MozReview-Commit-ID: 6zydP1jkffv
--HG--
extra : rebase_source : ea1d5f49ea02812aa632bdbad871688879f2b401
KeyboardLayout::InitNativeKey() is very messy because it handles a lot of cases without helper methods.
It's important to make it simpler implementation for preventing regressions caused by some patches which are written with misunderstanding. So, let's rewrite the method with helper method.
First, this patch make InitNativeKey() use IsDeadKey() instead of referring the table because calling IsDeadKey() is easier to understand.
MozReview-Commit-ID: DtN9qoh7Gz7
--HG--
extra : rebase_source : 8e769c1c88bfe646940491c111de609dbf53eeec
Make contentDocumentChanged and isContentDocumentDisplayed calls require
the caller to pass in a window object, so that we can get the widget and
GeckoLayerClient from the window object. This way these calls no longer
depend on having a global layer client in AndroidBridge.
Add AndroidCompositorWidget to act as the intermediary between gfx code
and GeckoLayerClient, in place of AndroidBridge. AndroidCompositorWidget
currently inherits from InProcessCompositorWidget, but when Android
eventually supports OOP compositing, it will be made to inherit from
CompositorWidget directly.
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 switing layout and gdk_keymap_get_direction might return invalid bidi infromation. 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 : 18b7d5c84f48acd62fa14e21a67b711106fb7d63
Distribution.getDistributionDirectories is currently annotated with
@WrapForJNI, but because it's used from JS through JNI.jsm, the
@JNITarget annotation is more appropriate.
Add jni::IsFennec() that returns whether we're in a Fennec environment
(defined as the presence of the GeckoApp class). Then, add
jni::IsFennec() checks to places where we use JNI for Fennec-only classes.
IMEInputHandler shouldn't append any ranges to dispatch empty composition event since empty clause information may make TextComposition confused. Additionally, it doesn't need to append caret range because CompositionTransaction always sets caret at start of composition when the composition string is empty.
MozReview-Commit-ID: FkLWePXZGJf
--HG--
extra : rebase_source : ede2687618ca072b40ba6d21861f1fc97296c416
TSFTextStore shouldn't append any ranges to dispatch empty composition event since empty clause information may make TextComposition confused. Additionally, it doesn't need to append caret range because CompositionTransaction always sets caret at start of composition when the composition string is empty.
MozReview-Commit-ID: Iu8IWwEOxaf
--HG--
extra : rebase_source : 70b56c6d4caee309615170aee70f28d8c3eb7d92
When NativeKey tries to remove a char message from the queue, another NativeKey instance might be created due to odd API hook or something. In such case, the old instance should handle the received message and the new instance should do nothing for keeping the order of message handling.
This patch makes:
* NativeKey::GetFollowingCharMsg() store removing char message to mRemovingMsg before calling PeekMessage() with PM_REMOVE.
* NativeKey::InitWithChar() set the old instance's mReceivedMsg to the received char message and do nothing even if HandleCharMessage() is called later.
* NativeKey::GetFollowingCharMsg() return received char message if mReceivedMsg is set during a call of PeekMessage().
MozReview-Commit-ID: KXYW0GgC9AY
--HG--
extra : rebase_source : 08472dec28e93450cd04a367843c1511cb812a9c
For detecting nested creation of NativeKey instances, NativeKey should manage the latest instance with sLastestInstance for the other instances and previous instance with mLastInstance.
MozReview-Commit-ID: BFZ0cr1640S
--HG--
extra : rebase_source : e2439a21f5984c6246283924c2013038c734ae2a
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
Instead of using NotificationClient directly from GeckoAppShell, add a
NotificationListener interface, which NotificationClient would
implement. This isolates NotificationClient (and the notification
package) from GeckoAppShell and lets us move the notification package to
Fennec. It also makes a cleaner interface for GeckoView consumers to
implement notification support.
For logging message, we should have better log text generator for MSG.
Then, we can improve the note of crash reports which is appended in NativeKey::GetFollowingCharMessage().
MozReview-Commit-ID: 4sbZJaWFH2o
--HG--
extra : rebase_source : bbc3101a78e4e2aa8b5eb0f68cd6f3605ba924f6
This is important for RTL locales which are drawn with explicit direction but
measured with no direction.
MozReview-Commit-ID: C4k5vgpKggD
--HG--
extra : rebase_source : 6fc3c6dae296d8dabe189361481b12a17e75dcc6
Previously oldState differed from aStateFlags just because it contained
direction flags.
MozReview-Commit-ID: DuGpHdt9EuX
--HG--
extra : rebase_source : 05a06d130a51c7a1830804254ec87c6697ade4a8
Currently, NativeKey::DispatchPluginEventsAndDiscardsCharMessages() calls nsWindowBase::DispatchPluginEvent() and nsWindowBase::DispatchPluginEvent() does nothing when windowless plugin doesn't have focus. However, this is unclear when other developers read the code of DispatchPluginEventsAndDiscardsCharMessages() and it causes unnecessary virtual calls. So, it should try to dispatch plugin events only when a windowless plugin has focus.
For making the check safer, nsWindowBase should expose the method to check it as ShouldDispatchPluginEvent(). Unfortunately, we cannot mark this method as const due to PluginHasFocus() needs to be not const method, though. Then, for loops in DispatchPluginEventsAndDiscardsCharMessages() should check it at each try.
This change helps to log the behavior (working on bug 1297013) without noise.
Additionally, this patch renames the method to MaybeDispatchPluginEventsForRemovedCharMessages() because it doesn't remove any char messages anymore.
MozReview-Commit-ID: F14Lcx47M6U
--HG--
extra : rebase_source : 64b6da75590c99299f75358023844762198136d6
NativeKey removes odd WM_CHAR messages which are caused by ATOK or WXG if the user tries to do "Kakutei-Undo" (meaning "undo the last commit") after dispatching eKeyDown event.
However, NativeKey should remove them from the queue first because there are some problems:
* If focus is moved during dispatching an eKeyDown event, we'll fail to remove the messages from the queue.
* If dispatching eKeyDown advance native event loop due to entering to a modal loop or dosing synchronous XHR, the message pattern is broken before removing the odd messages from the queue.
After removing the odd char messages, NativeKey should store them with mRemovedOddCharMsgs because NativeKey needs to dispatch them to focused windowless plugin.
Note that this patch also fixes a bug of the loop to remove the odd WM_CHAR messages. Old code removes only one WM_CHAR messages, but we need to remove all WM_CHAR messages before WM_KEYUP. This must be a regression.
MozReview-Commit-ID: I60bcIx2SFS
--HG--
extra : rebase_source : 19d0e70d9f39e6d0476c62def5e0a2dc1e0ab444
NativeKey is now removing and storing following char messages when it's created for a keydown message. Therefore, IsFollowedByNonControlCharMessage() just refers the stored messages and it's enough fast. So, we can get rid of mIsFollowedByNonControlCharMessage.
MozReview-Commit-ID: 542A2sHNXeC
--HG--
extra : rebase_source : e748c9855c3cf2d45609f94f9ccc8d43d29dc447
GetFollowingCharMessage() is now called only when removing following char message. Therefore, it does not need to have the optional argument indicating if removing the found message.
MozReview-Commit-ID: 7P39wyfSC1
--HG--
extra : rebase_source : a38bb961df1bc03adc21295bc39e4e9c16e864f2
While dispatching an event, focused widget may be changed. In such case, NativeKey shouldn't continue to dispatch remaining events (eKeyPress events) for preventing to dispatch to input text in unexpected website.
MozReview-Commit-ID: 7geuqks0LQK
--HG--
extra : rebase_source : 3e6c82e1eb0e27115fe93b1a3b4a155914fd06f7
In some cases, we may receive following char message of WM_*KEYDOWN *during* dispatching an eKeyDown event. In such case, NativeKey shouldn't dispatch eKeyPress event twice (one is caused by receiving WM_*CHAR message, the other is caused by post dispatching eKeyDown event code).
This patch makes NativeKey consume following WM_*CHAR messages before dispatching eKeyDown. Therefore, the former case will never occur.
For doing that, NativeKey stores following WM_*CHAR messages in mFollowingCharMsgs and uses it when it needs to dispatch eKeyPress events for each WM_*CHAR message.
MozReview-Commit-ID: 6QNvlwVVlTz
--HG--
extra : rebase_source : c33b5a1ac503326d51ef78f4f8a09c9a63df7871
You know, when Korean IME commits string, then it sometimes set next preedit string. So reseting context causes that next preedit string is committed.
So we shouldn't reset IME context with preedit_end.
MozReview-Commit-ID: CZJJvYjcrKY
--HG--
extra : rebase_source : d7e2e80930355794a40466c68fe22e43e7164d72
For safety, NativeKey::GetScanCodeWithExtendedFlag() returns without extended flag on WinXP and WinServer2003 because ::MapVirtualKeyEx() API doesn't support extend key conversion.
However, extended scan code is available even on them when lParam has 0x1000000 especially when it computes KeyboardEvent.code value. Therefore, it should return with 0xE000 for extended keys on any versions of Windows.
Note that NativeKey::ComputeVirtualKeyCodeFromScanCodeEx() wraps ::MapVirtualKeyEx() API. It checks if the API is not available for the result of NativeKey::GetScanCodeWithExtendedFlag(). So, returning extended scan code from NativeKey::GetScanCodeWithExtendedFlag() is safe.
MozReview-Commit-ID: D2RrHxPI9ET
--HG--
extra : rebase_source : 51f277e8331eb7ad109c3227ac1fe73f6de48105
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
Separate compiled JARs into GECKOVIEW_JARS and FENNEC_JARS, and run
AnnotationProcessor separately on each set. The GeckoView bindings are
put into widget/android/GeneratedJNI* (same as before), while the
Fennec-specific bindings are put into widget/android/fennec/FennecJNI*.
ibus-pinyin has a bug. When application calls gtk_im_context_reset(), which means selection is changed in application, ibus-pinyin sents a set of composition signals with empty commit string. Therefore, selecting text causes removing it.
For preventing it but not breaking the other IMEs which use surrounding text, we should give up to call gtk_im_context_reset() if IME hasn't retrieved surrounding text after the last selection change. Not having retrieved surrounding text means that the IME doesn't have any cache of contents. Therefore, not calling gtk_im_context_reset() at selection change must be safe for such IMEs.
MozReview-Commit-ID: 5cbIZjpd7zN
--HG--
extra : rebase_source : 6010b3e055d66ebd2ed50f9b3ee8ff2330d3c6ab
This patch includes a small memory optimization of using ArrayList and
`volatile int` for storing the pending thumbnails list and pending
width, instead of using LinkedList and AtomicInteger, respectively.
The patch also fixes a possible race condition due to calling
processNextThumbnail outside of a lock. Now it must be called inside a
lock and its name is changed to reflect that.
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
Previous design is only to request audio focus for audible media, but now we
also request focus for non-audible media.
It's simple that the app should own the focus when users start watching media.
MozReview-Commit-ID: 3eJP26h4kh7
--HG--
extra : rebase_source : b35c4ef7d6560635f428eba445f089abd3844bda
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
Ctrl+Backspace causes WM_CHAR for control character DELETE. However, NativeKey::IsControlChar() doesn't treat it as a control character. Therefore, NativeKey treats Backspace key as a printable character.
MozReview-Commit-ID: 29V45CNp8kW
--HG--
extra : rebase_source : 6656d884addf8b49dfa7c12d0b2c8d0543493c4f
On some keyboard layouts, a key sequence, a dead key -> another dead key, may produce a composite character instead of two base characters for each key. For example, with "Russian - Mnemonic" keyboard layout on Win 8 or later, both 's' and 'c' are dead keys but key sequence, 's' -> 'c', produces a Unicode character.
For solving this issue, this patch fixes 2 bugs:
First, KeyboardLayout::GetDeadKeyCombinations() doesn't add dead key entry if 2nd key is a dead key (::ToUnicodeEx() returns -1). In such case, it should add a dead key entry with the first character which is produced when only the 2nd key is pressed (the character is called as "base character" and used for index of the dead key table).
Next, KeyboardLayout::InitNativeKey() should check if 2nd dead key press produces a composite character. If it's produced, it should initialize given NativeKey with the composite character. Otherwise, it should initialize with base characters of each key. This patch does it with KeyboardLayout::MaybeInitNativeKeyWithCompositeChar().
Finally, we should add automated test for this. However, unfortunately, it's not available on Win7 and our infra is still using Win7 for running automated tests. Therefore, this patch doesn't include new automated tests.
MozReview-Commit-ID: G1DrfkHKNcK
--HG--
extra : rebase_source : 6ff4278d594a26a0908464b1e603a0a7ee2b3b38
It's difficult to understand what data is created by KeyboardLayout::LoadLayout(). So, for understanding what data is created, let's add logging code into it.
MozReview-Commit-ID: CelxyVpGn5f
--HG--
extra : rebase_source : fd8f15a42c4c2b4c1f1079184060c6e5f796ac5a
Based on crash reports, and issue was fixed in later drivers.
Also blocking 15.x up to 15.301.2301.1002.
MozReview-Commit-ID: F4kJta8JH1K
--HG--
extra : rebase_source : 5f69443b72cfefde052f70e27d8cf98128b3b913
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
When investigating bug 1075194, I found that we don't check return value of DocumentPropertiesW. So we sould use correct type and add log for this API.
MozReview-Commit-ID: Ck3VwMq9OpQ
--HG--
extra : amend_source : a0da15b578055b7612ce96b44cac2cd69607fa51
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
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
The new test failure is caused by a bug of the test API, KeyboardLayout::SysnthesizeNativeKeyEvent(). It doesn't generate WM_SYSKEY* messages nor WM_SYS*CHAR messages when Alt key is pressed. Therefore, the new path in the previous code works unexpectedly with automated tests.
This patch makes KeyboardLayout::SysnthesizeNativeKeyEvent() WM_SYS* message aware. When Alt key is pressed (but Ctrl key is not pressed) and the Alt key + something doesn't cause text input, the API generates WM_SYS* messages as expected.
MozReview-Commit-ID: FLbe4SYEZLf
--HG--
extra : rebase_source : 054147997eddfb01dbad63afc07e0b4f59a60257
Some keyboard utilities for Windows can change non-printable keys to printable keys. Therefore, if a keydown message is followed by one or more char message whose wParam isn't a control character, NativeKey should treat it as a printable key's event.
MozReview-Commit-ID: HoFbz5Zafeh
--HG--
extra : rebase_source : 9001c58cb082a93946e1b4c445dfe71f15d08997
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 does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 1c42bb32a662f2659c934a245ecd0025045120a5
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 2a94a47f1e7fe986d1efc3854c72968a3e28e365
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from the android nsIWidget instance,
because it can use the nsBaseWidget one.
--HG--
extra : rebase_source : f276e1629fcd0ffccb8c8dbec7bba6639a5ebd9f
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 82733f682c9e254e20354cc6908955a1e7485ee7
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : ccf64aaa9364d096e1f060ef77be7e8455b11e1f
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : b8a0d9a49b31929dd06af9e61fc57f484af7671d
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : e98b7f9970a920c39e941bb531dfc098125913d1
Make the GeckoAppShell.cameraCallbackBridge callback use the new native
JNI bindings. Also refactor the relevant code in GeckoAppShell and
CameraStreamImpl.
Get rid of LayerView.Compositor.getSurface and just pass in the surface
when creating or resuming the compositor. That also lets us get rid of
some synchronization required for getSurface.
Now that nsWindow doesn't own LayerViewSupport, we shouldn't be using
WindowEvent for LayerViewSupport calls. This patch converts the calls
that dispatch to proxy to dispatch directly to Gecko. For
SyncResumeResizeCompositor, it used a proxy to call OnResumedCompositor
on the Gecko thread; this patch makes SyncResumeResizeCompositor post an
event to call OnResumedCompositor directly, without going through the
proxy.
Right now we report Java exception stacks through two code paths:
- GeckoAppShell.reportJavaCrash for exceptions caught by Java code
- jni::HandleUncaughtException for exceptions caught by native code
This patch combines the code for reporting the Java stack trace into
ReportException, to make it easier to add new features such as reporting
OOM exceptions.
We used to only handle certain exceptions in native code, and otherwise
forward the exception to Java handling code. Handling exceptions in
native code gives us better native stack traces in crash reports, so
this patch makes us always handle uncaught Java exceptions in native
code if possible, and only forward to Java as a fallback.
KeyboardEvent::InitNativeKey() should initialize NativeKey if it's created for handling an orphan WM_CHAR message, however, if it the charCode isn't a printable character such as 0x0D for Enter key, it shouldn't refer it because focused editor shouldn't handle keyboard event as inputting the non-printable character.
MozReview-Commit-ID: FwTdGqhPEld
--HG--
extra : rebase_source : 69da91ad47e64199c8ff6c120522eb7e153122cd
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Make the generated SDK binding files depend on the annotation processor
jar file, so that changes in the annotation processor will cause the
bindings to regenerate.
We need to set the compositor-created flag in LayerView correctly when
reattaching to a new LayerView, so that we resume the compositor instead
of trying to create the compositor again, which we already did
previously.
This patch consists of general code cleanup and a new reattach method in
LayerView.Compositor that we call in order to set the compositor-created
flag correctly.
Its return value is only checked in one low-value assertion.
The patch also does the following.
- Removes the Android and GTK overloadings of EnableDragDrop(), which are
identical to the nsBaseWidget one.
- Streamlines the Windows implementation: fixes the indentation and takes
advantage of infallible |new|.
--HG--
extra : rebase_source : d090848cf5ea2e92c0188b07559c1e1f3899829f
Start offset of composition string is fixed when composition string becomes non-empty in focused editor. In other words, until composition string is fixed, composition start offset may be changed from selection start offset at dispatching compositionstart event. Especially, in e10s mode, pending keyboard events usually change composition start offset.
So, while there is composition, IMEHandler should use query events querying text rect or text content relative to actual start offset of composition string because native IME believes composition string at selection selection start when starting composition in the main process.
MozReview-Commit-ID: 3hinwozl9Ow
--HG--
extra : rebase_source : 4b79dd4f53aa51edfc78ff08c07a710160a8de01
The only implementation of SetSizeMode() that can fail is the nsCocoaWindow
one, on an Objective C exception, which is unlikely and can be swallowed.
This allows some nsGlobalWindow functions to become infallible as well.
--HG--
extra : rebase_source : 85d54185f63d2c138ee3f3e0e0bfe3b5e805a981
Returing TS_E_NOLAYOUT while ATOK shows suggest window causes moving suggest window to odd position. This causes flicking the window. Therefore, we shouldn't return TS_E_NOLAYOUT in this case. In this case, ATOK queries whole rect of composition string. So, we can return TS_E_NOLAYOUT for other cases.
MozReview-Commit-ID: LBZQPFjqQgx
--HG--
extra : rebase_source : 27fda6739562dfaf89efd1d2cd9cac03610846ba
ContentCache::TextRectArray::GetUnionRectAsFarAsPossible() should avoid crash by itself even if it's caller's bug. This makes parent process more stable, that is what one of the purpose of e10s is.
MozReview-Commit-ID: qKAfvm6eZw
ContentCache::TextRectArray's end offset is computed as start offset + its length. Therefore, end offset is the last offset in the range + 1. So, IsOverlappingWith() shouldn't return true only when end offset is overlapped with given range.
That means that when TextRectArray doesn't have rects, i.e., mRects is empty, IsOverlappingWith() always returns false. And when TextRectArray has one or more rects, IsOverlappingWith() should compare its range and given range without "=".
MozReview-Commit-ID: JxNPcEwikjR
They don't need to be NS_IMETHOD, but they should be MOZ_MUST_USE. Adding the
latter catches a few missing checks, which the patch adds.
The patch also gives PuppetWidget an InfallibleCreate() function, which makes
the infallibility of PuppetWidget creation clear.
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
ATOK 2011 - 2016 check focused window class name if it's a Mozilla's window. Then, they refer native caret position for deciding its popup window. However, future ATOK release will stop referring native caret position on Mozilla's windows. Therefore, we can stop creating native caret for new ATOK.
MozReview-Commit-ID: HPh3DVqTkvc
--HG--
extra : rebase_source : 00b75b75df2ba1bace328cfb75172c78c6bea29d
ContentEventHandler and ContentCache allow 0 length text rect query. However, if selection is collapsed and caret is at the queried offset, they return actual caret rect whose height (in horizontal layout, width in vertical layout) may be different from actual font height of the line.
Therefore, it may cause "dancing" of candidate or suggest window of TIP. Therefore, we should query text rect at least 1 length. Then, even if there is no character at the offset, they computes caret rect with previous character.
MozReview-Commit-ID: 9LprWTPyMsF
--HG--
extra : rebase_source : c0dfad35bcc1961948e21c8b50b21cdf218ba966
When TSFTextStore::GetTextExt() needs to hack the queried range, it means that the method should not return TS_E_NOLAYOUT since the hacks are implemented for that. However, currently, if hacked offset is still at modified offset, it returns TS_E_NOLAYOUT. This causes flicking IME windows.
For avoiding that, this patch adjust the hacked offset to the last unmodified offset or offset of the start of composition string. Even if there is no modified character in the composition string, we can use the offset since even if there is no character at the offset, query content event returns caret rect at the offset and if there are old characters, it returns its rect which the user still see. So, the rect at the composition start is useful until layout is modified actually.
MozReview-Commit-ID: 4zo9mF3m9u9
--HG--
extra : rebase_source : 6dd15b62422b85edf04150f15caaca45d7bc3600
Currently, TSFTextStore::GetTextExt() checks the offset with mContentForTSF.MinOffsetOfLayoutChanged() as "the first offset of modified characters", however, TSFTextStore::Content::IsLayoutChangedAfter() needs actual offset - 1. This is really not useful. So, we should rename it to IsLayoutChangedAt() and check the offset simply.
Additonally, TSFTextStore::GetTextExt() should set previous offset of MinOffsetOfLayoutChanged() when it hacks the queried range for avoiding bug of active TIP since setting offsets to the result of MinOffsetOfLayoutChanged() means the offset's layout is always not computed yet.
MozReview-Commit-ID: 182BMuubtFc
--HG--
extra : rebase_source : 65355fc4e488592f59dfc0b44806571ff0b87cd6
It's possible for LayerView to be destroyed before it's finished
initializing on the Gecko thread. In that case, we should not continue
with normal destruction of NPZC. Checking isGeckoReady() in
GeckoLayerClient accomplishes that. Also, guard against a case where
LayerView.onSizeChanged is called after LayerView destruction and
results in a NPE from mCompositor being null.
This patch makes the following changes on many in-class methods.
- NS_METHOD F() override; --> NS_IMETHOD F() override;
- NS_METHOD F() override {...} --> NS_IMETHOD F() override {...}
- NS_METHOD F() final; --> NS_IMETHOD F() final;
- NS_METHOD F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 3010fade82a170eab7f13d81bf61b02cd693f3cf
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
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
This patch makes ContentCache store previous character's rect of selection anchor and selection focus because if caret is at end of a line, IME may query the last character of the line.
MozReview-Commit-ID: 5X1K8KtrYfl
--HG--
extra : rebase_source : 403e4c993b48a832d50b4f44738c5b5c6d5ce085
Masayuki Nakano
James Cheng
Aryeh Gregor
Sebastian Hengst
Ryan VanderMeulen
Nicolas Silva
Markus Stange
Jim Mathies
Benjamin Smedberg
David Major
Carsten "Tomcat" Book
Jim Chen
Wes Kocher
Tom Schuster
Phil Ringnalda
Stone Shih
Kartikaya Gupta
Enes Goktas
Makoto Kato
Milan Sreckovic
Kirk Steuber
Jonathan Kingston
Ryan Hunt
Alexandre Lissy
Xidorn Quan
Aaron Klotz
David Anderson
George Wright
Matt Woodrow
Xidorn Quan
Kilik Kuo
Iris Hsiao
Umesh Panchaksharaiah
Thomas Wisniewski
Tanuja Sawant
Bill McCloskey
Karl Tomlinson
Andrew Comminos
Nathan Froyd
Mason Chang
Gerald Squelart
Alastor Wu
Shing Lyu
Manish Goregaokar
Stephen A Pohl
Jonathan Kew
Michael Layzell
Martin Stransky
Ho-Pang Hsu
Chih-Yi Leu
Ryan Hunt
Lee Salzman
Botond Ballo
Ou Shinjo
Nicholas Nethercote
Ethan Lin
Michelangelo De Simone
Randall Barker
Olli Pettay
Kan-Ru Chen
Sotaro Ikeda
Chris Peterson
Jeff Gilbert
John Lin
Igor
eyim
Jimmy Wang