commit c8bb45b41c3a13ef161103f649aa18938e028a70 introduced a new
verification state, VERIFICATION_IN_PROGRESS, to detect when the user
has already interacted with the authentication prompt, so the
prompt can rate limit the number of times the user can cancel
authentication attempts with the escape key (without also rate limiting
the number of times they can hit escape to go back to the clock without
interacting with the prompt).
That means there are now two states that represent the user actively
undergoing verification: VERIFYING and VERIFICATION_IN_PROGRESS.
It's inappropriate to reset the smartcard service if the user is
actively conversing with it. We try to check for that by looking at the
original verification state, VERIFYING, but we unfortunately, neglect
to account for the new VERIFICATION_IN_PROGRESS state.
The result is that if a user types their smartcard pin at the clock,
and then inserts their smartcard, the pin will get cleared instead of
used, and they have to retype it again.
This commit fixes the oversight, and allows users to again pre-type
their smartcard pin at the clock before inserting their smartcard.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2765>
Both timestamp and options parameters have been unused since
the switch to Clutter.grab(), so remove them.
Stop using Params.parse(), so that code that still passes the
parameters doesn't throw an error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3195>
It was added in commit 48fb16b570 for the lock screen, but that
hasn't been based on ModalDialog for a long time.
It doesn't appear that anything else ever used the parameter,
so just remove it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3195>
Currently extensions can only be locked down completely by
restricting the `enabled-extensions` key via dconf.
This is too restrictive for environments that want to allow users
to customize their system with extensions, while still limiting
the set of possible extensions.
To fill that gap, add a new `allow-extension-installation` setting,
which restricts extensions to system extensions when disabled.
As the setting is mainly intended for locking down by system
administrators, there is no attempt to load/unload extensions
on settings changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3180>
Since the last commit, we have infrastructure in place in the ScreencastService
to blocklist pipelines which crashed the recorder.
If such a crash happens a few minutes into a screencast, we can't do any better
than telling the user about the problem and encouraging them to try again (with
the faulty pipeline now blocklisted).
If the crash happens while starting the recording though, we can actually do
better: We can try to auto-restart the ScreencastService ourselves, and the
recording might still succeed without the user noticing anything. So retry
that start of the recorder for two more times, and then finally give up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
When gstreamer crashes during recording, it pulls the whole screencastService
down with it.
These crashes are typically caused by the gstreamer pipeline that's in use,
so to avoid running into them again and again, we can blocklist the last
used pipeline in case the recorder didn't shut down (aka crashed) last time.
To store this state, create a file (gnome-shell-screencast-pipeline-blocklist)
in the XDG runtime dir and store the ID of the current pipeline in that file
before we try to start.
Now when we crash while running the pipeline, the entry in that file will stay
around and we'll pick it up on the next start of the screencastService as a
blocklist.
When the recording was successful on the other hand, we'll call
`this._updateServiceCrashBlocklist([...this._blocklistFromPreviousCrashes])`
and remove the new entry from the file again before shutting down the recorder.
In addition to that, we can now encourage the user to try recording again
after a crash happened. Adjust the failure notification a bit to say
"please try again".
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6747
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
Since we now propagate error types back to gnome-shell now, let's start
with showing a special error message in case the disk ran out of space,
which is probably the most typical error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
When the screencast fails to start, we currently don't really inform the
user, other than the red screencasting indicator in the panel going away.
Re-use the failure handling paths to also show a notification when the
screencast fails to start. The notification in this case obviously should
not have an action to open a file (there is no file), so make that depend
on whether this._screencastPath is set and unset the path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
