When deleting text by backspace key of VKB, VKB might use `InputConnection.setComposingText`, not using KeyEvent. So although we dispatch dummy key event, the order of events is incorrect. We should dispatch keydown before input event.
Differential Revision: https://phabricator.services.mozilla.com/D64892
--HG--
extra : moz-landing-system : lando
In most cases, `InputEvent.getTargetRange()` of `beforeinput` event should
return `Selection` ranges at dispatching the event.
This patch also handles special cases.
* composition change - target range should be the previous composition string
which will be replaced with new composition string.
* replace text - target range should be the replace range. This is used by
spellchecker.
* drop - target range should be the drop point.
However, the other exception is not handled by this patch. That is, deletions.
The target range(s) should be the range(s) which will be removed. In most
cases, they also matches selection ranges, but may be extended to:
* surrogate pair boundary
* grapheme cluster boundary like complex emoji
* word/line deletion deletion
* `Backspace` or `Delete` from collapsed selection
* to end of unnecessary whitespaces
For supporting these cases, we need to separate
`HTMLEditor::HandleDeleteSelection()` and its helper methods and helper class
to range computation part and modifying the DOM tree part. Of course, it
requires big changes and `InputEvent.getTargetRanges()` may be important for
feature detection of `beforeinput` event so that we should put off the big
changes to bug 1618457.
Differential Revision: https://phabricator.services.mozilla.com/D64730
--HG--
extra : moz-landing-system : lando
`InputEventOptions` should be able to take target ranges for `beforeinput`
event. However, it requires to include `StaticRange.h` from `nsContentUtils.h`
even though most `nsContentUtils.h` users don't need it. Therefore, this patch
moves it from `nsContentUtils.h` to new header file.
And makes `nsContentUtils::DispatchInputEvent()` moves the target ranges
from `InputEventOptions` to `InternalEditorInputEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D64729
--HG--
extra : moz-landing-system : lando
`InputEvent.getTargetRanges()` can be used only when event type is
`beforeinput`. So, it may be used for feature detection of `beforeinput`
event because Chrome does not implement `onbeforeinput` event handler attribute.
Therefore, this patch makes it behind the pref for `beforeinput` event.
Differential Revision: https://phabricator.services.mozilla.com/D64728
--HG--
extra : moz-landing-system : lando
Maybe we should be using some native color, but the background for that is white
in my testing, so probably not, or at least probably it can be a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D64816
--HG--
extra : moz-landing-system : lando
Some users may want to disable 4th and 5th button of mouse.
This feature has already been implemented on Windows, and
our GTK widget can support this with this simple patch.
Differential Revision: https://phabricator.services.mozilla.com/D64721
--HG--
extra : moz-landing-system : lando
This also makes `GeckoView#onTouchEvent()` always return `true`, because
returning `false` will cause us to not receive any more events for that
touch. We always want to receive events.
Differential Revision: https://phabricator.services.mozilla.com/D64781
--HG--
extra : moz-landing-system : lando
- Increment MAX_DISPLAY_CONNECTIONS to 5 (main, compositor, renderer, and two media threads).
- Stop posting events to message loop when it's deleted. Use message loop shutdown observer for it.
- Shutdown nsWaylandDisplay event queue on both chrome and content processes.
- Use static preference variables which means dmabuf prefs are renamed to: widget.wayland-dmabuf-textures.enabled widget.wayland-dmabuf-webgl.enabled widget.wayland-dmabuf-vaapi.enabled
Differential Revision: https://phabricator.services.mozilla.com/D64474
--HG--
extra : moz-landing-system : lando
It is useful to use ToString.h to log text and selection change instead of
adding it each source code. Actually, there is same code in
IMEContentObserver and widget.
Also, mozilla namespace is required since this conflicts with
WinModifierKeyState.h.
Differential Revision: https://phabricator.services.mozilla.com/D64021
--HG--
extra : moz-landing-system : lando
This crash was caused because there was a case where the Provider would
store the SharedImage even if it failed to initialize it or send it to the
Client.
When the Client next requested a borrow, the Provider would see it was
already storing a SharedImage and would tell the Client to just
reuse the one it already had.
Since the Client never actually received it, it would end up dereferencing
a null pointer.
The fix for this is to wait until the SharedImage is fully initialized and
shared with the Client before storing it. That way, we know that if we have
it then so does the Client.
Differential Revision: https://phabricator.services.mozilla.com/D64659
--HG--
extra : moz-landing-system : lando
Recently opaque region is set when wl_surface is obtained by renderer/compositor.
It does not work as GL/WebRender get wl_surface only once and creates egl_window
on top of it so the opaque region is never updated.
Differential Revision: https://phabricator.services.mozilla.com/D64583
--HG--
extra : moz-landing-system : lando
AMD does not release any graphics cards under the vendor ID 0x1022. That
appears to be reserved for their non-graphics hardware. Instead they
have chosen to continue releasing graphics hardware under the ATI vendor
ID 0x1002. This patch removes all of the AMD ID rules and replaces them,
if applicable, with ATI ID rules. This has meant that sometimes we
failed to block things in the past that we expected to.
Differential Revision: https://phabricator.services.mozilla.com/D64443
--HG--
extra : moz-landing-system : lando
I browsed a bit with it and it looks pretty nice. Should we consider enabling it
on Nightly so we find if there's any obvious problem?
Differential Revision: https://phabricator.services.mozilla.com/D64396
--HG--
extra : moz-landing-system : lando
Inputting Unicode scalar value with `Alt` + numpad keys is available even
without NumLock state. However, `Alt` + function key on numpad should also
be worked because user may intent to perform it. Therefore, this patch
stops the hacking for bug 1606655 when given virtual keycode value is a
function key, but this means that users cannot type a Unicode scalar value
without NumLock key state if the value includes `7` (`Home`),
`4` (`ArrowLeft`), `6` (`ArrowRight`) because Firefox UI handles they are
shortcut keys (for "Go home", "Go back" and "Go forward"). Unfortunately,
I have no idea how to solve this conflict (if it's second key or latter key
after pressing `Alt` key, we could do that with a boolean flag, but I don't
like to make it only for this kind of edge case unless a lot of users want
to do it).
Differential Revision: https://phabricator.services.mozilla.com/D63782
--HG--
extra : moz-landing-system : lando
NS_Convert* has small string optimizations and doesn't require an extra strlen()
call from Adopt().
Differential Revision: https://phabricator.services.mozilla.com/D64191
--HG--
extra : moz-landing-system : lando
With Bug 1613130 fixed we may not need a fallback widget so let's remove this workaround.
Differential Revision: https://phabricator.services.mozilla.com/D64052
--HG--
extra : moz-landing-system : lando
This patch assumes that only element node can have content node. I.e., we
won't hit the following `MOZ_ASSERT`:
```
Element* element = nullptr;
nsIContent* content = aContent;
while (content) {
if (content->IsElement()) {
element = content->AsElement();
break;
}
content = content->GetParent();
}
MOZ_ASSERT(!content || content == element || content->GetParent() == element);
```
Differential Revision: https://phabricator.services.mozilla.com/D63308
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
Bug 1604412 enabled "remote backbuffer" compositing when using non-accelerated
layers. However, due to my misunderstanding of how nWindow and compositing
handles layered windows, I broke the usecase where a child window is
transparent.
In this case, it is the top-level anscestor window that has the
WS_EX_LAYERED attribute and not the child window. The ancestor is the one
that needs to be repainted when a present is requested.
Differential Revision: https://phabricator.services.mozilla.com/D63377
--HG--
extra : moz-landing-system : lando