There are cases where this._user might be null when a session
is opened. This is because the user is not selected via GDM but
it is set through PAM. This happens when logging with smart card
or with credential managers, for example.
Given the session-id of the opened session, look for the owner.
This fixes the following error:
```
gnome-shell[153293]: TypeError: this._user is null
Stack trace:
_findConflictingSession@resource:///org/gnome/shell/gdm/loginDialog.js:1219:26
_onSessionOpened@resource:///org/gnome/shell/gdm/loginDialog.js:1254:51
@resource:///org/gnome/shell/ui/init.js:21:20
```
Fixes: df84854d9 ("loginDialog: On login, allow logout a conflicting session")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7526
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
The conflicting session is owned by the same user per definition.
Use the Name property of the conflicting session to get the
username instead of assuming that `this._user` is defined and
passing the username around.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
Since commit df84854d90 the function
_onSessionOpened() is now async. This means that if an error occurs
we get the following warning:
```
gnome-shell[1014]: Unhandled promise rejection. To suppress this
warning, add an error handler to your promise chain with .catch()
or a try-catch block around your await expression. Stack trace of
the failed promise:
_onSessionOpened@resource:///org/gnome/shell/gdm/loginDialog.js:1166:27 @resource:///org/gnome/shell/ui/init.js:21:20
```
Follow the suggestion and add a try-catch block in order to reveal
what the error is. In the catch phase, reset the faded AuthPrompt
otherwise we can't retry with another user.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
The corner pipelines state theme node paint state was not necessarily
free of existing pipelines, so make sure to free them before looking up
new ones.
This avoids leaking thousands of CoglPipeline instances after toggling
the overview a bunch of times.
Fixes: e1868cab1a ("st/theme-node-drawing: Factor in border radius in update_resources()")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3421>
During session startup, we have the following chain:
LayoutManager._prepareStartupAnimation()
`- LayoutManager._startupAnimation()
`- LayoutManager._startupAnimationComplete() (a)
| or
`- LayoutManager._startupAnimationGreeter() (b)
| or
`- LayoutManager._startupAnimationSession() (c)
`- Overview.runStartupAnimation() (d)
`- OverviewActor.runStartupAnimation() (e)
`- ControlsManager.runStartupAnimation() (f)
Branch (b) calls LayoutManager._startupAnimationComplete() once the
animation is complete. Branch (c) does the same, except that
ControlsManager.runStartupAnimation() is an async function that awaits
LayoutManager.ensureAllocation().
LayoutManager._prepareStartupAnimation() is an `async` function, and its
caller catches & logs any error it raises.
Previously, ControlsManager.runStartupAnimation() – (f) in the above
diagram – was declared `async`, because it uses `await` internally, but
also accepted a callback, which was called on successful completion of
the function and the animation it triggers.
If an exception is raised during execution of the function, its callback
would never be called, and because the promise it implicitly returns is
discarded, the exception would never be logged either. And, stepping a
few levels up the call stack, the callback that
LayoutManager._startupAnimationSession() (c) provided would never be
called, and so LayoutManager._startupAnimationComplete() would never be
called, meaning the cover pane that prevents input would never be
removed and the session would be unusable.
Remove the callback parameter from ControlsManager.runStartupAnimation()
(f), and instead make it resolve in the case where the callback would
previously have been called.
Remove the callback parameter from OverviewActor.runStartupAnimation()
(e) – it is just a wrapper around ControlsManager.runStartupAnimation().
Adjust Overview.runStartupAnimation() (d) accordingly: rather than
passing a callback to OverviewActor.runStartupAnimation(), await its
return and then proceed. There is a slight behaviour change here:
previously, in the branch where this._syncGrab() is false, the callback
would be called before calling this.hide(), whereas now this.hide() is
called before the async function returns.
Adjust LayoutManager._startupAnimationSession() and its siblings to be
async, rather than each calling _startupAnimationComplete() directly.
Finally, in _prepareStartupAnimation() await _startupAnimation() either
succeeding or failing, and in either case call
_startupAnimationComplete(), removing the cover pane that prevents all
input.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3428>
The portal login window uses WebKit, which is a security-sensitive
component that not all vendors want to support.
Support that case with a build option, and update the captive
portal handler to use the user's default browser if the portal-helper
is disabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408>
When NetworkManager detects limited connectivity, we currently
pop up the portal helper window immediately. This can both be
disruptive when it happens unexpectedly, and unnoticeable
when it happens during screen lock.
In any case, it seems better to not pop up a window without
explicit user action, so instead show a notification that
launches the portal window when activated.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7688
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408>
Mutter has a new tool for interacting with mutter with features we don't
expose to users yet. It can be exported as a dbus service but it is not
done so by default. This adds an easy way to do so without having to
remember some JS snippet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3425>
