Commit 7419674b changed some grabs from requiring both mouse and
keyboard grabs to be considered successful to only requiring either of
them.
Due to this it was possible for example to open the overview or the
screenshot UI with a client (such as Chrome when opening a menu) holding
the mouse grab. This then made it impossible to interact with the UI
using the mouse (or keyboard) and if attempted could result in an
unresponsive UI.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5414
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2287>
In the case of bringing up the OSK while there is a grab (like, every
GNOME Shell entry), we used to special case event capturing so events
directed to the OSK would be let through.
When Clutter.Grab came around, events would be propagated only within
the actor hierarchy that holds the grab, which rendered this special
case just as useless as the OSK while a grab was hold. Since it wouldn't
be part of the grab hierarchy, clicking on the OSK would do nothing.
In order to let the OSK handle events, double down on the special case
and let it forward the event directly to the actor under the device,
instead of trying to let it through somehow. Since the actor under the
device are usually OSK buttons in this case, we don't need further
propagation to make it work, which makes the OSK functional again while
the shell holds a grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2237>
We have made good progress on object literals as well, although there
are still a lot that use the old style, given how ubiquitous object
literals are.
But the needed reindentation isn't overly intrusive, as changes are
limited to the object literals themselves (i.e. they don't affect
surrounding code).
And given that object literals account for quite a bit of the remaining
differences between regular and legacy rules, doing the transition now
is still worthwhile.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
Commit d92b71d2b2 went overeager in the removal of the additional
actors that were allowed to handle events (since the new grab
infrastructure makes them unable to see events in the first place),
and removed an early return in the captured event handler meant to
let events go through in those cases.
Since the grabbing actor was also part of this group, this was also
the code path where child actors of the grabbing actor could handle
events. Removing these made the captured event handler eat most
events meant for children. Add this check back, specifically for the
grabbing actor.
While at it, explicitly check (and propagate) crossing events,
since these are now enforced to be propagated (and warned about) in
Mutter.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4991
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
All callers have been updated to keep this handle to identify their
own grab.
Also, optionally use the windowing state to determine whether
the grab is suitable for the specific uses. This removes the need
to trying to grab twice in the places where we settle for a keyboard
grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
This is subject to further possible simplifications. Use Clutter.grab
to redirect input and focus, a fundamental difference here is that
we do redirect input to the topmost owner of the grabhelper stack,
instead of the stage. This is better behaved with the presence of
other grabs, at the cost of some behavioral changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
Some GrabHelper uses are in the form:
doPreGrabStuff();
this._grabHelper.grab({
onUngrab: () => {
undoPreGrabStuff();
},
});
A promise-based variant allows to write this more cleanly as:
doPreGrabStuff();
await this._grabHelper.grabAsync();
undoPreGrabStuff();
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/903
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
Starting from commit 7bb84dae, GrabHelper requires the owner to be an Actor as
we pass this to pushModal that assumes it to be as well.
So check that GrabHelper owner is an actor and throws an error if it is not the
case. This helps in tracking down issues such as gnome-shell-extensions!68
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/565
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Commit bbfa616f27 renamed _ignoreRelease to _ignoreUntilRelease
in some places, but not others, which broke GrabHelper.ignoreRelease().
Complete the name change to fix the fallout (e.g. app launcher menus
closing on button release).
The grab would previously just consume the button release, while propagating
motion events, possibly down to clients in wayland. This would produce
inconsistent streams there.
On pointer events, the inconsistency would just be having clients receiving
events with the button 1 set in the mask, with no implicit grab. When touch
events are handled, this would be more hindering as the client would receive
touch_motion events with no prior touch_down nor later touch_up, something
never supposed to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
GrabHelpers use a 'captured-event' to steal events and emulate
modality or grab-like semantics. There can be issues when you try to
use multiple GrabHelpers stacked on each other. As Clutter follows
the DOM-like semantics of "first come, first serve", when a second
GrabHelper connects to 'captured-event', its callback will only be
processed *after* the first GrabHelper's callback is called.
This breaks the expectation of narrowing modality where new modals
take priority over the old ones.
Solving this globally in a cleaner manner would require a rewrite of
pushModal/GrabHelper. As a stopgap fix for now, use one shared
'captured-event' handler between all GrabHelper instances, and
delegate to the individual GrabHelpers.
https://bugzilla.gnome.org/show_bug.cgi?id=699272
We can easily implement much of the same behavior ourselves by
keeping track of Clutter's focus events. Reintroduce heavily
modified FocusGrabber to do the work for us.
This will temporarily break when the user selects a window until
we can make gnome-shell automatically set the stage focus.
This also removes our only use of focus grabs, so remove those
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
Currently, if a button-press event results in releasing the last modal
grab (e.g. clicks outside the grabbed actors), we don't consider the
event handled and allow its emission to continue. If we consider
dismissing a grab as an action of its own, any additional action
triggered by the same event becomes an unexpected side effect.
Tweak the capture handler accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=696422
Since we drop our event handler, we won't see ever the release event
from the button press, so unset the flag so it doesn't muck with the
next time somebody takes a grab.
https://bugzilla.gnome.org/show_bug.cgi?id=696102
We may release the focus grab at any time, so it's not guaranteed
we'll be in event processing. In particular, hovering over and out
of a notification will cause this to happen, as the notification
is hidden on a timeout.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
Calling onUngrab() may change key focus, either directly or
indirectly (e.g. hiding the actor). Such key focus changes
would cause an extra actor to be ungrabbed, so make sure to
ignore such focus changes while we're ungrabbing.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
If we don't this for a nested grabFocus grab, the notify::key-focus
will be called, not think that the new key focus is part of the
grab, and cancel the full grab. This leaves the grab helper in an
inconsistent and confused state, as the grab is pushed onto the
grab stack after.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
While debugging, I found that the signal to focus-window-changed
was never getting disconnected, making a call to ungrab every time
the focus window changed, even if there were no focus grabs anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
GrabHelper saves the actor that had key focus when taking over the grab
(if any). On ungrab, the key focus is either restored or moved to some
child of the saved actor. The latter is unexpected and causes some odd
behavior, so don't be fancy and only restore the actual focus.
https://bugzilla.gnome.org/show_bug.cgi?id=693570
This is necessary for child popups in menus, e.g. while in a combo box,
clicking outside of the user menu should drop the entire menu, but
clicking on the user menu itself should only drop the combo box.
https://bugzilla.gnome.org/show_bug.cgi?id=689109
I have no idea why we used 'event' rather than 'captured-event' before.
'event' has some really strange quirks that came up when porting PopupMenu
to the GrabHelper
https://bugzilla.gnome.org/show_bug.cgi?id=689109
