Actually, long tap can set focus. But since it uses `nsIFocusManager::FLAG_BYMOUSE` flag, we cannot recognize whether setting focus is by long tap or not.
So I would like to add new flag `FLAG_BYLONGPRESS` and `CAUSE_LONGPRESS` that are by long tap.
Differential Revision: https://phabricator.services.mozilla.com/D35991
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Summary:
Currently, `IMEStateManager::SetIMEState` sets hint to the following logic.
- If there is no submit button into form element, set `next`
- If there is submit button, set `search` or `go`
- If there isn't into form element, no hint.
But Chrome sets `next` hint when next focusable element is input that is text
control. So even if there is submit button into form element, we should set
`next` to hint when next focusable element is input that is text/number
control and is in form.
Also, If current focused element isn't in `<form>`, I don't still set hint.
`nsFocusManager::DetermineElementToMoveFocus` may set focus to cross-process
document. So `next` is set when in form and it isn't last element in form.
Reviewers: masayuki
Reviewed By: masayuki
Subscribers: JanH
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D12885
--HG--
extra : rebase_source : f9d297416c046d9b718d9ff925006c162d67f286
extra : histedit_source : d8d946deb81f1f961d002e32720eb9a40a91bf64
Summary: To make setting action hint simple, I would like to move it to static function.
Reviewers: masayuki
Reviewed By: masayuki
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D24832
--HG--
extra : rebase_source : 730451dd56d0d0d2b8208765cac979f54b9745b1
extra : histedit_source : 5775444e938ec3dfa01e8a7a624dea49b785b307
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
Smart Location Bar (a.k.a URL bar) has some features, loading inputted URL
directly, searching bookmark items and history items, and search inputted words
with registered search engine.
So, it does not make sense its inputmode is "url". E.g., neither showing URL
specific software keyboard nor switching IME open state automatically for
typing URL may not be expected in most cases.
Unfortunately, there is no proper inputmode value for Smart Location Bar.
Therefore, this patch uses "mozAwesomebar" value and accepts the value only in
chrome documents. This value should be handled by each native IME handler
properly.
MozReview-Commit-ID: 7vUnbpg91F2
Some pages might use neither a default submit element nor rely on implicit submission and instead implement their form handling with JS key event listeners.
On Android, most IMEs won't allow sending an "Enter" key press if we're using an actionHint of "next" as our default, so we now use "go"/"search" for the last single line text/number input that is not disabled.
MozReview-Commit-ID: ACC15OYtcTF
--HG--
extra : rebase_source : 5ee608ea576e31ca320c93631bdb5e25716d9199
IMEStateManager has a static instance of InputContext which has some nsString
instances. Then, their members will be released after XPCOM shutdown and
that is detected as unexpected destruction.
Therefore, IMEStateManager should release them by itself at XPCOM shutdown.
Using nsTSubstring::SetCapacity(0) is the simplest way to release only the
string buffers.
MozReview-Commit-ID: LMrQxQF9xPn
--HG--
extra : rebase_source : 7cbaf19b76be8db083c10270d0ee436a1c061ea2
Currently, IMEStateManager::OnChangeFocusInternal() tries to sync the state
whether menu keyboard listener is installed between itself and active remote
process -- When menu keyboard listener is installed, it posts a message to
_only_ active remote process. When menu keyboard listener is uninstalled,
it posts a message to _only_ active remote process. So, it's not guaranteed
that active remote process at installing and uninstalling may be different.
If it's different, IMEStateManager in the old remote process believes that
menu keyboard listener is still installed. This is what the cause of IME
unavailable in a remote process.
Current approach must be wrong. IMEStateManager should manage menu keyboard
listener state only in the process which the listener is installed in. Then,
when menu keyboard listener is uninstalled, IMEStateManager needs to restore
the latest input context in the remote process without asking the remote
process.
Therefore, this patch does:
* stops IMEStateManager::OnChangeFocusInternal() posting message when menu
keyboard listener is installed and uninstalled.
* removes the message sender and receiver from PBrowser.
* cache the latest input context of active remote process in
IMEStateManager::SetInputContextForChildProcess().
* make IMEStateManager::SetInputContextForChildProcess() not set input context
when menu keyboard listener is installed in the process.
* tries to restore latest input context in the remote process in
IMEStateManager::OnChangeFocusInternal(). If there is no cached input
context, it does nothing and waits next SetInputContextForChildProcess() call.
* clears the cache when IMEStateManager::OnChangeFocusInternal() changes
active remote process to different one or nullptr.
So, this must improve performance at activating and inactivating memubar and
opening and closing popup menu in the main process.
MozReview-Commit-ID: EelKSPlaXdw
--HG--
extra : rebase_source : db7334b3c0d3ce87868450ee3179692027975bd6
In some cases, sFocusedIMEWidget may be nullptr but oldWidget still has
composition since IMEStateManager doesn't guarantee that NOTIFY_IME_OF_BLUR
is sent after REQUEST_TO_COMMIT_COMPOSITION nor REQUEST_TO_CANCEL_COMPOSITION.
Therefore, when it tries to clean up old widget's composition, it should refer
the old widget's IME notification requests.
MozReview-Commit-ID: 8kZvJbHfs5z
--HG--
extra : rebase_source : 3a1aab1023ab36e3668efd93b95fb5c8ccf2f21d
When a remote process has focus and it loses focus,
IMEStateManager::OnChangeFocusInternal() sends NOTIFY_IME_OF_BLUR via
IMEStateManager::NotifyIMEOfBlurForChildProcess(). Therefore,
sFocusedIMETabParent and sFocusedIMEWidget are set to nullptr here. So, if a
window becomes active, REQUEST_IME_TO_COMMIT_COMPOSITION in
IMEStateManager::OnChangeFocusInternal() won't work because
IMEStateManager::NotifyIME() ignores the request because of coming from wrong
process.
Therefore, IMEStateManager::OnChangeFocusInternal() needs to send
REQUEST_TO_COMMIT_COMPOSITION with proper process information which is only
stored by TextComposition instance.
MozReview-Commit-ID: KNEvOoQtK1E
--HG--
extra : rebase_source : 2d0c9297a6ffd3e7883130c80deec0479212148e
Android now supports telling an IME that it shouldn't store user-entered content into it's dictionary/language model/etc. and we want to automatically enable this in private browsing.
As the code that handles input on Android doesn't have any notion of tabs (and therefore of the difference between normal and private tabs), the best way to get that info across is to retrieve it directly within the IMEStateManager from the corresponding document and store it in the inputContext, which is then passed to Java for Fennec to handle.
Implementing this within Gecko also has the benefit that this part of the code can be used by other platforms as well should they want to support similar features in the future.
MozReview-Commit-ID: DsxjC4Ma7DR
--HG--
extra : rebase_source : f0940cb40170ab32cf5a172d07a61d083427be8a
Currently, IMEStateManager::OnChangeFocusInternal() sends blur notification to IME when a remote process has IME focus and focus is moving from the process. However, if IME wants to keep composition even during deactive and nobody will gets focus (i.e., all windows becomes deactive), IMEStateManager shouldn't send the blur notification because it causes committing composition.
Therefore, it should send blur notification only when focus is moving to a PresContext (that means that not all windows becomes deactive) or IME doesn't want to keep composition during deactive.
Then, even if another window becomes active next time, IMEStateManager can send "stop IME state management" message to the composing remote process and the remote process can commit composition normally.
Additionally, this patch ensures to send blur notification when IME focused TabParent or widget is being destroyed. This fixes new memory leak bug of this patch (sFocusedIMETabParent keeps grabbing the instance until shutting down in some mochitests).
MozReview-Commit-ID: KYiFGo970a8
--HG--
extra : rebase_source : c3de0df442420979414b47d8d20c7988c49b205b
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
This patch fixes a simple mistake which was written when we support IME in e10s mode.
IMEStateManager::OnChangeFocusInternal() already has code which makes the method doesn't set IME state again when focus is not being changed, input context of the widget was already set by a remote process and our process is being activated. However, the condition of checking if input context of the widget was set by which process is reversed.
MozReview-Commit-ID: 61ZH0VnKqPq
--HG--
extra : rebase_source : 14eb8e276e6307ed30d018d4385c454f80c1e831
When focus is moving from a remote process to different process (including to the main process), destroying IMEContentObserver in the focused remote process occurs later. I.e., NOTIFY_IME_OF_BLUR will be notified later. However, it may be too late for new focused process especially when destroying the focused widget.
Therefore, this patch makes IMEStateManager notifies IME of blur in such case.
MozReview-Commit-ID: GkypubVjn3H
--HG--
extra : source : 9f4bd86dff910c2e3c3ae35f3e883d809c4a204e
IME should receive notifications and requests only from proper process. E.g., IME shouldn't commit composition by a request which came from previous focused process.
This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally. If the request or notification came from remote process, it should be non-nullptr. Then, this makes it ignore notifications and requests from unexpected process.
Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.
Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.
MozReview-Commit-ID: 9CgKXQRJWmN
--HG--
extra : source : f3b5711908870c5e0e852a399a07e0ae721a12f1
Currently, IMEStateManager always sets input context as set by current process even when it needs to adjust IME state when a tab parent for current focused IME process is removed. Then, input context for the widget is marked as for main process but the widget still have IME focus of a remote process.
For fixing this mismatch, IMEStateManager should set ORIGIN_CONTENT even when the tab parent is being destroyed.
MozReview-Commit-ID: C10YOAtkET4
--HG--
extra : source : 9430d123b19e0ac551c6048bb044fcfa22d13e45
When focus is moved from the main process to a remote process and there is active IME content observer (i.e., an editor in the main process has focus), IMEStateManager should destroy the active IME content observer because it may cause notifying NOTIFY_IME_OF_BLUR when the main process takes focus again.
MozReview-Commit-ID: BG3eZhxoWBW
--HG--
extra : source : 3447abd6be7ad112e97bfe860507a382c5d19385
