Commit Graph

15545 Commits

Author SHA1 Message Date
Sebastian Keller
901ecfb619 theme: Use the same style for dash tooltips as for window captions
Both serve a similar function but had different styles. Since these two
can now be seen next to each other, the visual difference is quite
noticeable.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3727

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1681>
2021-02-16 19:27:15 +00:00
Marco Trevisan (Treviño)
b74900b3a3 gdm: Override any other lower-priority service message on error
When we got an error, all the other HINT or INFO messages are not useful
anymore and delaying to show them is just a waste of time and may be
even wrong in scenarios with fast authentication devices.

An example are the fingerprint devices, where the user may touch the
sensor repeatedly while we may still show the "touch the sensor" hint
instead of notifying of possible errors.

So, in case we got an error override all the other errors coming from
the same service with lower priority.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
2021-02-16 18:00:10 +00:00
Marco Trevisan (Treviño)
45a5171a95 gdm: Filter service non-error messages on verification stopped or failed
Once the verification has been stopped or has failed all the messages
that are not of error type are just not needed or wrong to show.
For example, in the fingerprint case we may still show the hint to swipe
or touch the device, while the fingerprint PAM service has already been
stopped.

So filter them by adding a new function that adds a null message to the
queue, overriding all the messages that have a lower priority.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
2021-02-16 18:00:10 +00:00
Marco Trevisan (Treviño)
1cc20ca6b6 gdm: Add ability to queue a message overriding ones with less priority
There are cases in which a service may want to override a message with
one coming with higher priority, for example an info or hint message
isn't useful anymore if we've already got an error message.

In the same way when a service has been stopped we don't care anymore
showing its info or hint messages, while it still may be relevant to show
errors.

An example is the fingerprint service that may emit errors quickly while
the hints messages should not be kept around when an error is already
queued or when the service has been stopped.

So, add function that allows to override queued messages based by their
type that follows this policy:
 - Messages coming from different services are always preserved in
   their original order.
 - Messages (from the same service) with a priority equal or higher than
   the last queued one are preserved.
 - Messages matching completely the last queued are dropped in favor of
   this one.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
2021-02-16 18:00:10 +00:00
Marco Trevisan (Treviño)
ef10bb6229 gdm: Keep messages in queue until we've not fully processed them
It can be convenient to get the currently showing message in order to
replace or remove it in case it's not needed anymore.

So simplify the message queue handling by only depending on a single
local variable (_messageQueue) and redefining hasPendingMessages
depending on its content.

Now messages are kept in queue till they are not fully processed and the
first message is always the one currently shown.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
2021-02-16 18:00:10 +00:00
Marco Trevisan (Treviño)
9ecc1a4cd7 gdm: Compress fingerprint failures events using a timeout
When a fingerprint failure event happens we may also soon receive a
conversation-stopped event with an error message (such as in the case
we hit the MAXRETRIES value), but this is going to be ignored in case we
are too quick in consider the first failure a verification-failed event
because that implies disconnecting from all the events and then ignoring
such signals.

To prevent this, add a small timeout before failing the verification so
that if we get a further event we will process it.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
2021-02-16 18:00:10 +00:00
Marco Trevisan (Treviño)
1ee9278786 gdm: Don't try to retry authenticating when the service is unavailable
In the case a service is not available (as it can be in the fingereprint
case when a supported reader is available but has not enrolled prints)
we were trying indefinitely to restart it, however this can lead to
troubles since commit 7a2e629b as when the service conversation was
stopped we had no way to figure out this case and we'd end up to
eventually fail the whole authentication.

However, in such cases the PAM services are expected to return a
PAM_AUTHINFO_UNAVAIL and gdm to handle it, emitting service-unavailable
signal.

So connect to ::service-unavailable and keep track of the unavailable
services so that we can avoid retrying with them.
In case such service is not the foreground one, we can just silently
ignore the error as we did before commit 7a2e629b, without bothering
failing the whole verification.

In case we got a valid error message on service-unavailable, we also
show it, this is normally not happening unless GDM isn't redirecting
here other kind of problems (such as MAXTRIES) which are supposed to
stop the authentication stopping any further retry.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3734
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
2021-02-16 18:00:10 +00:00
Jonas Dreßler
e65e5edee6 appDisplay: Use icon-size instead of width/height for system actions
When creating an icon for the system actions search provider, set the
icon size using StIcons own icon-size property instead of ClutterActors
width and height property. That ensures the scale factor is applied and
the icon will be properly scaled on hiDPI screens.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>
2021-02-16 13:56:20 +00:00
Jonas Dreßler
8f9d6a4c13 appDisplay: Use new indentation style
Otherwise eslint will complain about the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>
2021-02-16 13:56:20 +00:00
Sebastian Keller
1bd2b0123e windowPreview: Consider chrome overlaps when offscreening for opacity
The icon and close button might be overlapping the window actor but
were not considered in has_overlaps() which gets used to decide whether
to offscreen the actor for transparency. Since currently the icon is
visible when the preview is dragged and the whole actor is turned
transparent, the opacity will not be applied to everything as a whole
but the child actors individually. This leads to the window becoming
visible behind the icon.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1684>
2021-02-16 13:29:00 +00:00
Sebastian Keller
8d5fb73695 workspacesView: Don't invalidate allocation before using it for gesture
Calling startTouchGesture() on the workspacesViews can change the
visibility of the workspaces if not all of them are already shown, such
as when there are more than 3 workspaces or for 3 workspaces if we are
not on the central one. This invalidates the allocation and the width
used as distance for the gesture would become 0, resulting in drag
gestures immediately jumping to the first or last workspace due to a
division by 0.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3721

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1682>
2021-02-16 03:50:52 +01:00
Sebastian Keller
629b7394f7 dnd: Set dnd actor size instead of scaling it when reparenting
Previously the actor could end up using its natural size and then get
scaled down to its allocation before reparenting. This however could
affect the layout of the widget due to the larger size. To ensure the
widget looks the same after reparenting set the size to its original
size.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3717

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1680>
2021-02-16 01:07:23 +01:00
Carlos Garnacho
87558efbf1 st: Keep weak ref on texture cache bound texture source
We don't keep any ref on it, so it might leave us with a dangling
pointer here.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3491
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1672>
2021-02-15 21:09:53 +00:00
Marco Trevisan (Treviño)
7a2e629bd0 gdm: Fail and restart verification on conversation stopped for all services
Currently when the foreground service conversation stops we increase the
verification failed count and try to start it again, while if a
background service has been stopped we just ignore it.

This is causing a various number of issues, for example in the case of
the fingerprint authentication service, it is normally configured to die
after a timeout, and we end up never restarting it (while the UI still
keeps showing to the user the message about swipe/touch the device).

So, in such case let's just consider it a "soft" verification failure
that doesn't increase the failures count but will cause us to reset the
UI and try to restart the authentication (and so the affected service).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
ed1ace1d99 authPrompt: Bump the user verifier timeout when wiggling the message
Wiggle may make the error message to be visible for less time so provide
the auth prompt an API to increase the timeout to be used for showing a
message in some cases.

This could be reworked when we'll have a proper asyn wiggle function so
that we could just make the user verifier to "freeze", then await for
the wiggle transition to complete and eventually release the verifier.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
75a1798e75 authPrompt: Wiggle error messages coming from the Fingerprint service
When error messages are coming from the fingerprint service they are actual
failures due to an user input in some device, in so in such case we
can highlight this by using a wiggle effect.

This mimics what has been done in gnome-control-center fingerprint panel
and part of [1].

[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
19c4dce322 authPrompt: Only wiggle the entry on failures coming from the querying service
Currently whenever an authentication failure happens we wiggle the
entry, however this may not be related to the service which failed.

For example if the fingerprint authentication failed for whatever reason,
there's no point to wiggle the text input as it's something unrelated to it.

So, only apply the wiggle effect to the entry in case the failure is
coming from the querying service.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
526f0711f1 gdm: Expose the source serviceName for messages and verification failures
By giving to the AuthPrompt information regarding the source service
name (and so the ability to know whether it's a foreground service) can
give it the ability to behave differently.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
6ccd289691 gdm: Count fingerprint authentication failures in fail counter
Fingerprint PAM module can have multiple failures during a runtime
and we rely on the pam module configuration for the maximum allowed
retries.

However, while that setting should be always followed, we should never
ignore the login-screen's allowed-failures setting that can provide
a lower value.

So, once we have a fingerprint failure let's count it to increase our
internal fail counter, and when we've reached the limit we can emit a
verification-failed signal to our clients.

As per this we need also to ignore any further 'info' messages that we
could receive from the fingerprint service, as it may be configured to
handle more retries than us and they might arrive before we have
cancelled the verification session.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
1158e98913 gdm: Increase the verification failed counter once we've a failure
Decouple the verification failure count increase from
_verificationFailed as there are some cases in which we may want to
increase it without emitting a verification-failed signal.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
53db4b99b8 gdm: Always show fingerprint error messages
When the login/lock screen is shown the error messages for background
services are always ignored.

However, in case the service is the fingerprint authentication method
we still want to be able to show error messages to inform the user
about what failed, and eventually that the max retries (that may be
different from the login screen configuration) has been reached.

This handles partially the design issue [1] related to the login/lock
screen fingerprint authentication.

Eventually we want to use pam extensions to use clearer and parse-able
messages, however in the case of the fingerprint service we can be sure
that the fprint PAM module will only send errors on auth failures.

[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Marco Trevisan (Treviño)
f7685dc224 ShellUserVerifier: Add method to check if the service name is fingerprint
We have multiple places where we check if we're handling a fingerprint
event, so let's add a common public function so that it can be used also
by the authPrompt.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
2021-02-15 16:58:50 +00:00
Jonas Dreßler
09602ae2ae blur-effect: Don't use stage view when drawing off-stage
When we're painting off-stage, for example because we're screencasting
or taking a screenshot, there won't be a stage-view associated with the
paint context. The BlurEffect previously didn't handle that case and
would crash.

Fix that and handle that case by assuming the scale is 1 and not
offsetting the rectangle we blit from the draw framebuffer.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1673>
2021-02-15 13:17:08 +01:00
Daniel Mustieles
c592a06911 Updated Spanish translation 2021-02-15 10:48:39 +01:00
Марко Костић
736f1bc5fc Update Serbian translation 2021-02-15 08:16:57 +00:00
Carlos Garnacho
2f446548b1 shell: Drop shell_global_sync_pointer()
This is now unused, and shouldn't be used anymore.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
863ba76675 messageTray: Drop hack to keep track of X11
This is here to cater for lost events while the pointer wanders
into untracked shell UI (thus not part of the input region under
X11). Let mutter handle this situation instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
2799760244 windowManager: Drop sync_pointer() after relayouts
We should trust the Clutter machinery here, as it has code to trigger
focus changes triggered by relayouts.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
2445212e35 messageList: Drop sync_pointer() after relayouts
We should trust the Clutter machinery here, as it has code to trigger
focus changes triggered by relayouts.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
cbde13fc65 overview: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
0141b66d23 grabHelper: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
f1437506ea dnd: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
A S Alam
b9207e0e19 Update Punjabi translation 2021-02-14 00:50:19 +00:00
Balázs Meskó
1e422faeb8 Update Hungarian translation 2021-02-13 23:32:09 +00:00
Sebastian Keller
2501bc5c8f st/scroll-view-fade: Fix vertical top fading
The fade for the vertical top edge was calculating the fade ratio for a
larger height (up to where the bottom fade starts) than it was
displaying.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1674>
2021-02-13 21:00:46 +00:00
Panawat Wong-kleaw
8a76508f71 osk-layouts: Add additional keys to Thai layout
Add Anghankhu (๚), Fongman (๏), Khomut (๛), and Yamakkan ( ๎) keys.

These keys do not exist in most, if not all, Thai physical keyboards,
but may be used by those who study ancient Thai texts. However,
they are an optional part of the TIS-820-2538 spec[0].

[0] https://www.nectec.or.th/it-standards/std820/std820.html

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3106

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1427>
2021-02-13 17:28:23 +00:00
Panawat Wong-kleaw
478b45084c osk-layouts: Add a shift level to Thai layout
It is currently missing entirely from the generated layout.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3106

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1427>
2021-02-13 17:28:23 +00:00
Carlos Garnacho
28f73a175c windowManager: Do not set Wacom LED state through g-s-d
This piece of machinery is going away, in favor of the own kernel's
support.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1075>
2021-02-13 15:52:55 +01:00
Lucas Werkmeister
bbf1fc28ca lookingGlass: Let history trim input
Checking whether the item is empty is now the history’s job, per the
previous two commits. The history also trims the input for us.

The effect of this is that we call _history.addItem(), and thereby move
to the end of the history, even if the input is empty (or consists only
of whitespace); clearing the input field and pressing Enter becomes a
quick way to jump back to the end of the history. (The current history
item is not overwritten if the input is empty.)

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
2021-02-13 08:58:20 +00:00
Lucas Werkmeister
df94055c58 runDialog: Let history trim input
Checking whether the item is empty is now the history’s job, per the
previous commit. The history also returns the trimmed input for us, so
we can avoid doing that work twice.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
2021-02-13 08:58:20 +00:00
Lucas Werkmeister
d31f805817 history: Trim input and ignore if empty
This ports the runDialog changes of [1] to the underlying history
component, where they can benefit looking glass as well: the history is
now responsible for trimming the input and deciding that it shouldn’t be
stored if empty. (Note that _setPrevItem and _setNextItem already
skipped updating the history if the entry was empty.)

Since both users, runDialog and lookingGlass, also need the trimmed
input for other reasons – runDialog to avoid issues when interpreting
the command as a file path (if it can’t be executed as a command),
lookingGlass to decide whether a command should be run at all – have
addItem return the trimmed input. (runDialog and lookingGlass are not
yet changed to take advantage of this – that will be done in separate
commits.)

[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
2021-02-13 08:58:20 +00:00
Lucas Werkmeister
30203f2694 history: Use strict equality checks
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
2021-02-13 08:58:20 +00:00
Jakub Steiner
5dafc26b6d HC: Set legible app icons for window thumbnails
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3692

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1657>
2021-02-13 08:34:43 +00:00
Marco Trevisan (Treviño)
829a096ba1 gdm: Restart only the service that failed at verification-failure
When verification failed using a specific authentication service we're
currently restarting the whole user authentication system, which leads
to lots of unneeded operations (reinitializing a new user verifier proxy,
restarting all the gdm workers with the relative PAM modules and so on).
And this makes also debugging of login problems more complicated, given
we're cluttering the journal with repeated data.

However, at reauthentication failure GDM has already set up for us an
user verifier that we can use reuse to start only the service that had a
failure. So when possible, just start a new service instead of rebooting
the whole authorization process.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
85ad1157df gdm: Pass source serviceName to verification failures
Depending on the service name we got the failure from we could react
differently, so let's pass the value to the verification failure
handler.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
80a7a8ddb9 gdm: Ensure we cancel all the previously running services on auth retry
When retrying the authentication we should make sure that all the
previously initiated services are stopped in order to begin a new
authentication session with all the configured services.

Unfortunately at the current state we only dispose the currently used
user verifier, but we don't make it to stop all the relative gdm workers
and then they'll stay around potentially blocking any further usage of
them (as it happens with the fingerprint one, that has unique access to
the device).

So, cancel the currently running authentication before starting a new
one if we're explicitly retrying.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
ca912f55cc gdm: Include the failed service name when in reporting errors
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
36fba1a184 gdm: Do not fail the whole authentication if a background service failed
In case a background service such as the fingerprint authentication
fails to start we'd just mark the whole authentication process as
failed.

Currently this may happen by just putting a wrong password when an user
has some fingerprints enrolled, the fingerprint gdm authentication
worker may take some time to restart leading to a failure and this is
currently also making the password authentication to fail:

    JS ERROR: Failed to start gdm-fingerprint for u: Gio.DBusError:
        GDBus.Error:org.freedesktop.DBus.Error.Spawn.Failed:
            Could not create authentication helper process
        _promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
        ### Promise created here: ###
        _startService@resource:///org/gnome/shell/gdm/util.js:470:42
        _beginVerification@resource:///org/gnome/shell/gdm/util.js:495:18
        _getUserVerifier@resource:///org/gnome/shell/gdm/util.js:405:14
        async*_openReauthenticationChannel@resource:///org/gnome/shell/gdm/util.js:378:22
        async*begin@resource:///org/gnome/shell/gdm/util.js:194:18
        _retry@resource:///org/gnome/shell/gdm/util.js:561:14
        _verificationFailed/signalId<@resource:///org/gnome/shell/gdm/util.js:584:30
        _emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
        finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:268:14
        _queueMessageTimeout@resource:///org/gnome/shell/gdm/util.js:273:18
        _queueMessageTimeout/this._messageQueueTimeoutId<@resource:///org/gnome/shell/gdm/util.js:288:65

Given that background services are ignored even for queries or any kind
of message, we should not fail the authentication request unless the
default service fails.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
0ccb8e27d4 gdm: Disconnect user verifier signals on destruction and verification failed
When a verification session has failed we may want to wait for the user
to have completed all the waiting queries and to have read all the
incoming messages, however during such time an user verifier should
not be allowed to queue further messages to the UI, as we're about to
completely stop the identification or start a new one.

Unfortunately this is not true because we're still connected to the
identifier signals, and so we may still show messages.
This is particularly true when using the fingerprint PAM module as it
may restart the authentication while we're in the process of stopping
it.

So, keep track of all the signals we've connected to, and disconnect on
verification failed and during cancel/clear operations.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
c936ca3ea0 gdm: Don't try answering query if the user verifier has been deleted
Answering a query may be delayed to the moment in which we've not any
more messages in the queue, however this case can also happen just after
we've cleared the UserVerifier and in such case we'd have nothing to
answer, but we currently throw an error:

    JS ERROR: Exception in callback for signal: no-more-messages:
      TypeError: this._userVerifier is null
    answerQuery/signalId<@resource:///org/gnome/shell/gdm/util.js:249:17
    _emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
    finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:266:14
    _clearMessageQueue@resource:///org/gnome/shell/gdm/util.js:301:14
    clear@resource:///org/gnome/shell/gdm/util.js:223:14
    cancel@resource:///org/gnome/shell/gdm/util.js:205:18
    reset@resource:///org/gnome/shell/gdm/authPrompt.js:482:32
    cancel@resource:///org/gnome/shell/gdm/authPrompt.js:569:14
    vfunc_key_press_event@resource:///org/gnome/shell/gdm/authPrompt.js:128

So handle this case more gracefully keeping track of the current
cancellable and checking whether it is still valid before trying to answer
a query or do a delayed action.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00