Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
Usually, IME sets selection and considers candidate list position at starting
new composition. However, Apple Japanese IME sometimes consider the candidate
list position at retrieving the character rects before setting selection.
Therefore, we need to store last commit string's character rects, but don't
need to store it in long time because Kakutei-Undo is supported by Japanese
IMEs and they work only immediately after committing a composition. E.g.,
after moving caret, it won't be available.
Depends on D97838
Differential Revision: https://phabricator.services.mozilla.com/D97839
Autocapitalize isn't applied if type is url, email or password. If these types,
truncate autocapitalize value in InputContext not to pass it to widget.
Differential Revision: https://phabricator.services.mozilla.com/D86676
We do this analogously to how PanGestureInput does it except that the delta's that we compute mLineOrPageDeltaY from are computed by us instead of provided to us.
mLineOrPageDeltaY being non-zero is what EventStateManager::DispatchLegacyMouseScrollEvents uses to decide to send legacy mouse events, so we need to populate it to get those legacy events to send.
This fix is Windows only on purpose as pinches on macOS don't seem to send wheel events (Windows sends ctrl+wheel). When Linux gets implemented it will need to be determined what to do.
Differential Revision: https://phabricator.services.mozilla.com/D86495
The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
`mousemove` event coming from the parent process causes `mouseout` and
`mouseleave` events of the last synthesized `mousemove` in the test. The
reason is, synthesized `mousemove` for tests makes `PresShell` in the content
process record the cursor location, but won't make it `PresShell` in the
parent process do it. Therefore, parent process may synthesize `mousemove`
event for the system cursor position which does not match with the synthesized
mouse location in the content process. Therefore, `:hover` state may be
updated unexpectedly.
This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
came from another process. Then, makes `PresShell::HandleEvent()` ignore
synthesized `mousemove` events coming from another process only when the
recorded mouse location was set by a mouse event synthesized for tests.
Differential Revision: https://phabricator.services.mozilla.com/D65282
--HG--
extra : moz-landing-system : lando
At bug 1614208, the line style value mapping was changed, but
`GeckoEditable.IME_RANGE_LINE_*` are not updated.
This patch makes the style in `TextRangeStyle` an enum class for making it
type safer, and updates `GeckoEditable.IME_RANGE_LINE_*`, and finally, adds
`FYI` comments in `TextRangeStyle` to make developers realize it requires
manual update.
Differential Revision: https://phabricator.services.mozilla.com/D62883
--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::hitCluster to WidgetMouseEventBase::mHitCluster
Differential Revision: https://phabricator.services.mozilla.com/D25318
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::pressure to WidgetMouseEventBase::mPressure
Differential Revision: https://phabricator.services.mozilla.com/D25314
--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
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
Some InputContext members are not forwarded through
PBrowser::SetInputContext.
MozReview-Commit-ID: C1bGYq4w8zT
--HG--
extra : rebase_source : 1481f08c7593fe9dceb3b96bbfe480a1c58ecf9d
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process. However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.
So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat. For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.
On Windows, there are two ways to generate keyboard input messages. One is
using SendMessage() or PostMessage(). The other is SendInput() API. In both
ways, utils can make their input as repeated key messages.
The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.
On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags. Otherwise, only first call is
treated as non-repeated event.
So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.
MozReview-Commit-ID: 3rinrOjx8Tf
--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
This commit implements the auto-dir scrolling functionality in APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot
will be implemented in a future.
MozReview-Commit-ID: 9xai99x71gh
--HG--
extra : rebase_source : 118d188f730e3fb91d147b076a053cb04e622e55
Do some work in preparation for implementing actual functionalities for this
bug. No actual functionality change is involved in this commit.
MozReview-Commit-ID: 5aLhr38n1N4
--HG--
extra : rebase_source : 15cfc2cea5b7668367dd3bd4a0746ae8c61b7d20
