This patch also cleans up some inconsistencies in the conditions under which the
main thread would respond to wheel and mouse events. With this patch applied, the
main-thread notifications are only sent if the input block id is nonzero, which
indicates the APZ actually processed the input event and added it to an input
block.
MozReview-Commit-ID: GBlgj6whi5T
--HG--
extra : rebase_source : 01cbbe8b90208a8dc5ab81ab9bdbd39d3bc8ee7a
clang complains that it's unable to instantiate this template because
the functions being passed as arguments are MOZ_JNICALL, while the
actual parameter to the function has no such attribute. Adding the
attribute makes everything line up.
clang complains about specializations of NativeStubImpl not being able
to see the private constructor of ProxyNativeCall. While
ProxyNativeCall includes a friend declaration for NativeStubImpl, it's
not obvious *which* NativeStubImpl is being friended, as NativeStubImpl
hasn't been forward declared and exists in a completely separate
namespace. Forward declaring NativeStubImpl and adjusting the friend
declaration makes everything more correct.
clang complains that a constexpr definition of methods[] cannot refer to
members of the incomplete Impl template parameter, and rightly so.
Making these const is sufficient for our purposes, and that enables us
to move the declaration outside of the class, where it will be
instantiated lazily (presumably at the point when |Impl| is a complete
class definition). We also need to declare the length of methods[], as
other parts of the code require knowing the length of methods[] at
compile time.
For making our code clearer by the stronger type check, we should change the anonymous enum for NS_TEXTRANGE_* to enum class whose name is "TextRangeType" and whose type is "RawTextRangeType" which is an alias of uint8_t.
Additionally, this also adds some utility methods for them.
Note that some lines which are changed by this patch become over 80 characters but it will be fixed by the following patches.
MozReview-Commit-ID: 76izA1WqTkp
--HG--
extra : rebase_source : 27cd8cc8f7f8e82055dbfe82aba94c02beda5fa4
For sending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED after the other change notifications which was caused by the user input, we need to use IMEContentObserver::IMENotificationSender because it sends the notifications when it's safe to do it.
This patch makes TextComposition use IMEContentObserver to send the notification. However, if there is no active IMEContentObserver, e.g., composition events are fired on unfocused window, TextComposition sends it by itself (same as current implementation).
If IMEContentObserver stops observing when it has pending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, it cannot send the notification (i.e., it is discarded completely in such case). However, in such case, IMEContentObserver sends NOTIFY_IME_OF_BLUR. So, anyway, native IME handler should treat the blur notification as it including NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED.
On the other hand, we're buggy if composition events are fired in non-active window. Even in such case, IMEContentObserver should be created for active editor in each document and it notifies IME of the changes. But this is out of the scope of this bug.
MozReview-Commit-ID: 7Q0ZsJTh4hX
--HG--
extra : rebase_source : 6417f991fa8c0fbe3f25b27bacf4257e5485aecc
It's not clear to me what NOTIFY_IME_OF_COMPOSITION_UPDATE means only from the name. For making the name clearer, this patch renames it to NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED and add some explanation to the definition.
MozReview-Commit-ID: 8ySYCNJ1Ytz
--HG--
extra : rebase_source : 3331b8f48e8b460c7f9b088064dcda9488f3403c
TaskbarTabPreview object will be released by GC. So when Disable method is called, window may already destroyed. So we should check whether window is destroyed.
MozReview-Commit-ID: MGz3JmDh37
--HG--
extra : rebase_source : 43a859cbcb729718b59745182c94ef3688a44f0f
This method is for old NSTextInput API and unused now.
MozReview-Commit-ID: thcbEExH58
--HG--
extra : rebase_source : 7d9f665d867366990c5aac5a54555cc2c3483828
PuppetWidget::GetInputContext() needs to communicate with its parent process with synchronous IPC. This is very expensive for focus move.
Currently, IMEStateManager uses nsIWidget::GetInputContext() only for checking the IME enabled state. Therefore, it's enough to cache input context when nsIWidget::SetInputContext() is called. Then, we can avoid to communicate with synchronous IPC with PuppetWidget::GetInputContext() in most cases.
This patch makes IMEStateManager stores the last widget which sets input context. When PuppetWidget uses its input context cache, it should check if it is the last widget to set input context with IMEStateManager since an input context may be shared with other widgets and another one may have update the input context. I.e., PuppetWidget's input context cache may be already outdated after IMEStateManager sets input context with another widget.
This patch gives up to support retrieving IME open state from child process. However, perhaps, this is not necessary for everybody including add-on developers because the only user of IME open state in child process is nsIDOMWindowUtils. So, add-ons can send IME open state from chrome process instead. If this decision is wrong, unfortunately, we should support it again in another bug. It's easy to support with creating another nsIWidget::GetInputContext() or adding additional argument to it.
MozReview-Commit-ID: B2d2CCTsPKj
--HG--
extra : rebase_source : 4117330ba7871753176da960063b612e96f11752
When calling showDefinitionforAttributedString on OSX 10.11, it always return error due to the following exception.
Exception: decodeObjectForKey: class "TitlebarAndBackgroundColor" not loaded or does not exist
So before calling it, we set temporary color value, then restore color after calling it.
MozReview-Commit-ID: 1YeY6X1W6AV
