Although I don't know why Ergo-L keyboard layout behave differently on my
environment and the reporter's environment. In the reporter's environment,
second dead key press causes `WM_DEADCHAR` with `0` `wParam`. Then,
`GetFollowingCharMessage()` returns `false` so that it's not stored into
`mFollowingCharMsgs`. Then, `NativeKey::IsFollowedByDeadCharMessage()` returns
`false` and `NativeKey::mIsDeadKey` is set to `false`. Therefore, `NativeKey`
dispatches only `eKeyDown` event but whose `.key` is `"g"` rather than
`DeadKey` and finally, fails to call `KeyboardLayout::ActivateDeadKeyState()`.
Therefore the following dead key sequence is not treated as so.
This patch makes it return `true` for such `WM_DEADCHAR` message so that the
`WM_KEYDOWN` message will be treated as a dead key sequence.
Differential Revision: https://phabricator.services.mozilla.com/D219317
When an element starts capturing a pointer, pointer/mouse boundary events are
dispatched by `EventStateManager::PreHandleEvent` [1]. However, when the
capturing element loses the capture, they are not dispatched.
When the pointer capture is implicitly released, the pointer may be over another
document. Therefore, this patch synthesizes an internal `ePointerMove` and
`eMouseMove` on the widget to make `PresShell::HandleEvent` redirects the event
to proper document under the pointer.
Unfortunately, I add 2 manual tests into WPT. The reason is, a drag operation
across document boundary with test driver does not work even if I specify the
pointer position within the parent document coordinates. This is same both on
Firefox and Chrome. Additionally, writing the new tests as a mochitest won't
work too. If I use synthesized mouse events, I see similar failure.
Additionally, when I use native events, it works, but unstable to run on CI.
1. https://searchfox.org/mozilla-central/rev/669fac9888b173c02baa4c036e980c0c204dfe02/dom/events/EventStateManager.cpp#1139-1140
Differential Revision: https://phabricator.services.mozilla.com/D218896
Currently, we set `tiltX` and `tiltY` on Windows, macOS and Linux. However,
they don't let us know the new values directly. Therefore, they are required
only for the DOM `PointerEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D219128
It's only used in non-compositing WMs, to implement popup transparency,
and it's completely untested.
Instead, do not draw shadows and rounded corners on those WMs.
Differential Revision: https://phabricator.services.mozilla.com/D219141
It's only used in non-compositing WMs, to implement popup transparency,
and it's completely untested.
Instead, do not draw shadows and rounded corners on those WMs.
Differential Revision: https://phabricator.services.mozilla.com/D219141
During EndDragSession and the dispatch of the dragend event in a content process
(e.g. in an extension), accessing the event's dataTransfer didn't work because
the session was already disconnected from the BrowserChild. This broke things
like tab dragging from web-extension-based tabbars. This leaves the drag
session in place until after EndDragSession is done. It also makes the
reciprocal change to InvokeDragSession.
Differential Revision: https://phabricator.services.mozilla.com/D218667
- Move more widget events from mContainer to mShell. We generally want to listen on mShell and use mContainer
for GtkContainer related events only.
- Set correct event masks for mShell/mContainer
Differential Revision: https://phabricator.services.mozilla.com/D216913
* Make mXPos/mYPos work in terms of margin (mExtraMargin).
* When we have no anchor, explicitly upgrade them to anchored-to-point.
Differential Revision: https://phabricator.services.mozilla.com/D215444
This requires quite a bit of piping to get the ChildID passed everywhere where
we currently pass the pid in IPC. This is done by adding a new struct type
(EndpointProcInfo), which is passed around instead of OtherPid in these places,
and contains the full pid.
In most cases, it was a fairly painless change to move over, however in some
cases, more complex changes were required, as the pid was being stored
previously in something like an Atomic<...>, and needed to be switched to using
a mutex-protected value.
In the future, it may be possible to remove OtherPid from IPDL actors once
everything is migrated to ChildID, but we're still a long way off from that, so
for now we unfortunately need to pass both around.
Differential Revision: https://phabricator.services.mozilla.com/D217118
* Make mXPos/mYPos work in terms of margin (mExtraMargin).
* When we have no anchor, explicitly upgrade them to anchored-to-point.
Differential Revision: https://phabricator.services.mozilla.com/D215444
We no longer have the parent/child window set-up for popups, so we can
just use mWnd.
Remove the HideWindowChrome() stuff. That landed once already in [1],
but was backed out along with other stuff, due to it causing buttons to
show up on non-native notifications (which is the only top level that
hits this code-path).
Eventually, I want to handle this more like other platforms (via D209502
and D207303) but until those land, just explicitly set hidechrome="true"
on that window in order to be able to land this simplification
separately.
Bug 1454589 doesn't happen with this change, and there's no reason to
apply size mode in SetWindowTranslucencyInner, so remove that chunk of
code too.
[1]: https://hg.mozilla.org/mozilla-central/rev/24dc60b32e21
Differential Revision: https://phabricator.services.mozilla.com/D218635
* Make mXPos/mYPos work in terms of margin (mExtraMargin).
* When we have no anchor, explicitly upgrade them to anchored-to-point.
Differential Revision: https://phabricator.services.mozilla.com/D215444
This is just a renaming patch, motivated by a need for clarity before
addding more YUV formats. Comments and log messages are updated as well,
and one function in MacIOSurface is renamed.
There is one small change in TextureHost.cpp to satisfy clang-tidy.
Differential Revision: https://phabricator.services.mozilla.com/D217883
The patch comes from https://gitlab.com/redhat/centos-stream/rpms/firefox/-/merge_requests/94
Firefox isn't currently handling window focusing right on X11... There's a few problems:
If no startup id is provided, it tries to get user time from g_get_monotonic_time when there's no guarantee that timestamp is synchronized or even in a compatible unit. This merge request addressed that by dropping the code that uses g_get_monotonic_time entirely, and instead adding a heuristic to synthesize a startup id based on the time of the last user interaction on the display. This makes an assumption that firefox was started as a result of user interaction, which might not always hold true, but it's more likely than not, and is basically the same assumption firefox is already making by trying to use a timestamp of "now" (g_get_monotonic_time) when focusing the window.
If a startup id is provided, it fails to tell gtk to use it when focusing the window because it calls gtk_window_present_with_time with some other random timestamp instead of passing GDK_CURRENT_TIME (which is the magic value that means "use startup id for timestamp"). This commit tries to detect when a startup id is available, and the display is X11, and if so use a timestamp of GDK_CURRENT_TIME.
Differential Revision: https://phabricator.services.mozilla.com/D217174
The patch comes from https://gitlab.com/redhat/centos-stream/rpms/firefox/-/merge_requests/94
Firefox isn't currently handling window focusing right on X11... There's a few problems:
If no startup id is provided, it tries to get user time from g_get_monotonic_time when there's no guarantee that timestamp is synchronized or even in a compatible unit. This merge request addressed that by dropping the code that uses g_get_monotonic_time entirely, and instead adding a heuristic to synthesize a startup id based on the time of the last user interaction on the display. This makes an assumption that firefox was started as a result of user interaction, which might not always hold true, but it's more likely than not, and is basically the same assumption firefox is already making by trying to use a timestamp of "now" (g_get_monotonic_time) when focusing the window.
If a startup id is provided, it fails to tell gtk to use it when focusing the window because it calls gtk_window_present_with_time with some other random timestamp instead of passing GDK_CURRENT_TIME (which is the magic value that means "use startup id for timestamp"). This commit tries to detect when a startup id is available, and the display is X11, and if so use a timestamp of GDK_CURRENT_TIME.
Differential Revision: https://phabricator.services.mozilla.com/D217174
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
When event target frame is destroyed, `PresShell::NotifyDestroyingFrame` updates
current event target content to the frame content. However, event target of
some DOM events need to be `Element`. Therefore,
`PresShell::mCurrentEventTarget` needs to store at least the handling
`EventMessage` to consider whether the event target can be non-element content
node or only element node. So, we need to make `PresShell::EventTargetInfo`
store `EventMessage`. Then, we can make `PresShell::NotifyDestroyingFrame`
prefer inclusive ancestor element as new event target from the `EventMessage`.
Although I don't understand what's going on the reported case, but I found the
simple case when event target is changed to a `Text` with the assertion in
`PresShell::DispatchEventToDOM`. Therefore, this patch has a new test.
Note that if target frame is a frame for element, e.g., when event target is
a focused element, `IsForbiddenDispatchingToNonElementContent` result won't
change the behavior. Therefore, its implementation is not optimized for
non-user input events.
Differential Revision: https://phabricator.services.mozilla.com/D217205
macOs has the feature for auto-correction.
Other browsers already has this feature, and can control this by
`autocorrect` attribute [*1] that is still non-standard.
Since content script can modify source text for autocorrect by
any event handers, autocorrect is run when source text isn't
changed only.
The event order for this implementation is the following.
1. `keydown` event by space
2. `keypress` event by space
3. `beforeinput` event (`insertText`) by space
4. `input` event (`insertText`) by space
5. `beforeinput` event (`insertReplacementText`) by autocorrect
6. `input` event (`insertReplacementText`) by autocorrect
7. `keyup` event by space
Also, Safari's order is that input event for space is fired after
`insertReplacementText`. And, Chrome's is broken. When typing
`"omw"`, "w"'s keyup is fired after dismissing a picker. And they
don't use `insertReplacementText`.
And, Saferi can prevent this when calling `event.preventDefault()`
on `keypress` event handler for space/enter key. But I guess that
there is no way to get event handler calls `preventDefault()` from
widget side on Chrome process.
*1 https://github.com/whatwg/html/pull/5841
Differential Revision: https://phabricator.services.mozilla.com/D213512
When using autocorrect, we should use `insertReplacementText` according
to https://github.com/w3c/input-events/issues/152. So I would like to
add eContentCommandReplaceText command for this.
Also, this command has an option that is source string text. When
processing text subsitution, parent process doesn't know whether
target replaced text is modified. So I add this option for check.
Differential Revision: https://phabricator.services.mozilla.com/D213511
Masayuki Nakano
Emilio Cobos Álvarez
Sandor Molnar
stransky
David Parks
Iulian Moraru
Nipun Shukla
Alex T
Eitan Isaacson
pstanciu
Noemi Erli
Nika Layzell
Norisz Fay
Narcis Beleuzu
Hiroyuki Ikezoe
Brad Werth
Makoto Kato
Stanca Serban
Tom Schuster
Ray Kraesig
Ryan VanderMeulen