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
GrabHelper automatically releases grabs when the user clicks outside
the grabbed actors. However at least for the message-tray (which is
the only user of grabHelper at the moment), we must ignore any events
from the On-Screen-Keyboard, to prevent the tray from hiding at every
key press.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
Currently clicks outside the grabbed actors are handled the same as
the user pressing Escape - a single actor is popped from the grab stack.
However according to the design, outside clicks should release all grabs.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
When Dan Winship wrote the GrabHelper code originally, it didn't
handle a grab stack. I wrote the grab stack code hastily when landed
the message tray, not understanding all of the code that was involved
here.
Fix it so that we properly do the operations for each type of grab
when we first need to, and not sometimes when the first grab is taken.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
Users of GrabHelper.grab() espect that the actor parameter (or one of its
children) will receive focus, irrespective of the previous focus location.
This fixes the key focus on the chat entry when expanding the notification.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
If the user has the mouse down - for example when they are selecting
text and dragging - then the attempt to get a modal grab will fail.
grabHelper: allow the .grab() function to fail and do nothing in this
modal case if the grab fails.
messageTray: handle grab failure and don't pop up the tray. Change the
logic for tray dwelling so that we only try to pop up the tray once
while the pointer is in the dwell area - this avoids the possiility
that the tray will pop up once the user releases the mouse.
https://bugzilla.gnome.org/show_bug.cgi?id=682385
