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
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue. GeckoThread.waitOnGecko is changed to wait on
both the widget queue and the XPCOM queue. nsAppShell::SyncRunEvent is
changed to avoid a possible deadlock condition involving locking
sAppShellLock twice.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative. As a rule, disposeNative is dispatched to the queue with
the least priority among the queues that other native members of the
same class dispatch to (i.e. "gecko_priority" if all other native
members dispatch to "gecko_priority", or "gecko" if any native members
dispatch to "gecko").
Bug 1344892 - 3. Update auto-generated bindings; r=me
profiler_get_profile() will return nullptr is the profiler is not active, so
there's no need to call profiler_is_active() just beforehand.
--HG--
extra : rebase_source : 9b7d4396599dc10230c5215492c9f63c48a4ff5e
According to ATOK's behavior, IME may send different line breaker from its platform's standard. Therefore, we should treat \r as \n too.
Additionally, currently, TextComposition doesn't allow to input \n with composition. However, this was added for preventing to see odd control characters as boxes with code point. Therefore, we should allow \n for IMEs. (It was allowed, this limitation is unexpected when I reviewed the patch to reject control characters in TextComposition.)
MozReview-Commit-ID: DzGSMgp89Av
--HG--
extra : rebase_source : 0644e5941a080583af8701546111fbf46ec646ec
Although, TextComposition's bug, those tests are not checked with expected values, we should fix them later.
MozReview-Commit-ID: 89jehNqMnCH
--HG--
extra : rebase_source : 2c622396edef067b92393f1e5e5291db9105417a
So, finally, Flush() should replace native line breakers in the composition string before dispatching composition events. However, if the composition string was set by Set(), i.e., it's already been replaced with native line breakers, we shouldn't try to do it again due to performance reason. Therefore, this patch adds |mReplacedNativeLineBreakers| to manage if it's already been called.
MozReview-Commit-ID: 5Y7ULWeP153
--HG--
extra : rebase_source : f825e45a7033c3c651e6324047e75c20f6c69b36
First of all, replacing native line breakers with XP line breakers needs to adjust offset and length of each TextRange. Therefore, we cannot just duplicate the code into TextEventDispatcher::PendingComposition::Flush().
For creating a new method to replace the native line breakers in PendingComposition::mString, we should separate range adjustment code to a static method, AdjustRange(), because we cannot use for loop simply because we need to adjust both mClauses and mCaret.
MozReview-Commit-ID: 5ycsN8EAs45
--HG--
extra : rebase_source : 0ef667669c9027958a0a955f4b883f70be89cbb3
Ctrl+Space causes WM_CHAR of ' '. On the other native applications, you can input ' ' with this key combination though, we shouldn't allow this because we need to remove Ctrl and Alt modifier state at dispatching keypress event for the limitation of TextEditor but this is important key combination for custom shortcut keys.
So, when Ctrl or Alt key is pressed but it doesn't change the inputting character, i.e., the character can be inputted without Ctrl or Alt, we shouldn't remove those modifier state from eKeyPress event.
MozReview-Commit-ID: 7omLvNdQWzW
--HG--
extra : rebase_source : 66d5015567799c489d925ac2419358913f808d63
Synthetic mouseevents generated from touch gestures are dispatched asynchronously
from the touch events. This means that the nsAutoRollup that the widget puts on
the stack during the dispatching of the touch events is no longer in scope when
we get around to firing the mouse events. As a result, the mouse events can end
up reopening rollups that got closed by the touch events and that shouldn't be
reopened. We fix this by stashing the rollup that was in scope while the touch
events were being dispatched, and make sure we keep that in scope for the
synthetic mouse events.
MozReview-Commit-ID: HjteKHfAqvD
--HG--
extra : rebase_source : 46217b1ba610ef193963ccab454a6f584af61a2b
This just decouples nsAutoRollup from the widget class, which it isn't really
bound to anyway because the internal data is static. We'll need to be able to
use nsAutoRollup independently in the next patch.
MozReview-Commit-ID: 1dxSLTr4g1K
--HG--
extra : rebase_source : 6f6964ca046b6f88e5c99c944a08b1c563f17837
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
Shift+F10 is also well-known shortcut key on Linux. So, it should behave same as pressing ContextMenu key. So, for allowing web page to prevent its default, nsWindow for GTK needs to consume Shift key state at dispatching eContextMenu key.
Additionally, we should allow to open context menu with Shift+ContextMenu because only ContextMenu key press can be prevented its default by web page. Therefore, we should allow users to open context menu even with keyboard even if web content doesn't want it.
Note that Ctrl+Shift+F10 or Alt+Shift+F10 should behave same as Shift+ContextMenu key, but we should discuss later.
MozReview-Commit-ID: 1mPGKMTsrkv
--HG--
extra : rebase_source : 75dd8333b24f5e2f4ded4414b5e5ee85de253cc7
In PresShell, eContextMenu event is marked as dispatched only in chrome when its shiftKey state is true. However, Shift+F10 causes the context menu, it should not be marked as so because this is standard shortcut key to open context menu on Windows.
This patch consumes Shift key state if previous key message is WM_SYSKEYDOWN of F10 before dispatching eContextMenu event. So, user cannot block to prevent its default at opening context menu with Shift+F10, we should discuss this later.
MozReview-Commit-ID: 1P9LpeJoQof
--HG--
extra : rebase_source : f77fcf6a4587bc131901d717325f6083b4a89393
Inside OnImeReplaceText, an action can cause the editor to blur and
mDispatcher to be reset. We should guard against that and abandon
subsequent actions.
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative.
Bug 1344892 - 3. Update auto-generated bindings; r=me
get_gtk_cursor attempts to use themed cursor icons for most css cursor types,
but left these two out. Now it will try to use the theme for these as well,
and fall back to the generic FF set used previously.
MozReview-Commit-ID: 9QHV0mc5AxK
--HG--
extra : rebase_source : c03d01f6dc3a30a8f16def9f95cee14d18f7a8a1
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
