In case there are any internal ways the dialogue can close itself
without calling its own close() method, it’s probably better to do all
our cleanup on a handler for the `closed` signal instead.
This should introduce no functional changes except ensuring the
polkitAgent cleanup is always done.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
Otherwise the session could outlive the dialogue, emit a subsequent
signal, and its callback would reference finalised objects/widgets from
the dialogue. The PolkitSession object is implemented by
libpolkit-gobject, so we have no guarantees about its reference counting
— the session object could keep itself alive in another thread, or be a
singleton. In all likelihood, the session hangs around for longer than
the dialogue due to differences in when the two objects are garbage
collected.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
In contrast to generic animated icons, it is reasonable to expect
spinners to be invisible while inactive. Implement that behavior
in the new Spinner class and optionally animate the transitions.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/316
If no password or a wrong password is entered after automounting an
encrypted device, then the password should be reasked. However, this
does not happen because the relevant udisks error messages for this
cases are missing in the exception handler that calls _reaskPassword.
Fix this issue by adding the relevant udisks error strings to the
exception handling in the _onVolumeMounted method.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/640
As a mount operation's UI may be reused (for example after mistyping
the password), we only close the operation once the mount has finished
(successfully or with error).
We therefore need to track ongoing operations, which we currently do
by monkey-patching the corresponding volume object. However while the
underlying GVolume object indeed remains the same through-out the
operation, the JS wrapper object isn't referenced anywhere and may
thus be garbage collected, resulting in a stuck dialog.
Fix this issue by tracking active operations explicitly, so that all
involved objects are referenced until the end of the operation.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/565
The `hints` and `settingName` parameters to the agent call may define
the specific list of secrets NM actually needs from the user. This
seems to have been the intended use of these two parameters but only
recently did NM with the IWD backend start to use this to request 802.1x
secrets. So if `hints` is provided, ask user for the specific secrets
listed there and don't even look at what type of EAP method is in use.
Only the three types of secrets actually in use by NM's IWD backend are
supported for now -- they happen to be the same three that
_get8021xSecrets() had already supported.
If the volume is removed before AUTORUN_EXPIRE_TIMEOUT_SECS seconds, we can stop
the timeout earlier as there's nothing to unset, while the volume instance
won't be valid anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
While the libnm-glib version of the function returns a GByteArray*
that gjs can directly cast to the required gutf8*, the libnm function
returns GBytes* from which we need to explicitly fetch the data.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/136
We use the close() method to disconnect signal handlers set up in
init(), however the handler ID is only valid in the first call in
case the method is called more than once.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/221
Since commit 78a92fb6be we no longer pop up authentication dialogs
on the lock screen, however any dialog that is already open at that
time remains open. This is unexpected, so hide the dialog until
the screen is unlocked again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/166
While polkit requests *should* be the result of a user action, that's
not always the case in practice and authentication dialogs can pop up
out of nowhere at any time. That's always annoying, but particularly
bad on the lock screen. If we disabled the polkit component altogether,
the fallback GTK-based agent would kick in, so instead handle the case
explicitly and postpone showing the dialog until the session is unlocked.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/179
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
It turns out that NetworkManager does export the directory as pkg-config
variable after all, so use that instead of building the path ourselves
from the prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
When the agent doesn't work (e.g. when the screen is locked), it shouldn't be
registered with NM. Otherwise it will keep cancelling the requests that
could happily be serviced with system secrets.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
The native agent already forgets about the request at the point it's
serviced and the further attempt to use it (e.g. cancel it when the screen
is locked) will trigger an assertion failure:
** (gnome-shell:30862): CRITICAL **: shell_network_agent_respond: assertion 'request != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=789811
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 39a840e2c3 added an additional parameter to shell_app_launch().
When adjusting callers, the parameter was also added accidentally to
calls of the confusingly similar g_app_info_launch() ...
Remove those to fix some warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Telepathy's role has been diminishing continuously over the last
couple of years, so while chat integration is a nice feature for
those who use it, it is hard to justify keeping it as a hard
dependency. To address this, split out the component from the
client so we can handle missing typelibs gracefully by not
providing any chat integration.
https://bugzilla.gnome.org/show_bug.cgi?id=779878
The telepathy integration was written at a time where gjs didn't
allow to inherit from GObject classes, which is why we needed a
C helper class. This hasn't been the case for a while now, so cut
out the middle man and implement Tp.BaseClient directly.
https://bugzilla.gnome.org/show_bug.cgi?id=771721
Commit c6f22826cf added a call to update() to refresh the notification
time for sent and received messages. However as it omits the bannerMarkup
parameter, escaped text like ''' now makes it through verbatim.
Rather than adding the parameter, we can just refresh the timestamp in
the existing update() call to fix the issue - it means the notification
timestamp is only refreshed for received messages, but that reflects
the text shown in the notification, which isn't updated for sent
messages either.
https://bugzilla.gnome.org/show_bug.cgi?id=779435
As the telepathy integration picks up existing channels on startup,
ChatNotifications are another case where the real time the message
was received may be before the time it is picked up by the shell.
While this is less of an annoyance than restored GNotifications, as
it generally only affects restarts from the run dialog, it's an
easy fix now ...
https://bugzilla.gnome.org/show_bug.cgi?id=775799
Currently the cache is built once when the first VPN request is
handled, so plugins that are installed or uninstalled after that
aren't picked up. Fix this by invalidating the cache on changes
to the plugin directory.
https://bugzilla.gnome.org/show_bug.cgi?id=773893
And adapt existing callers to the new API. This will allow us to
implement a way to launch applications on the discrete GPU for systems
where an "Optimus" system exists.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
Since commit 82950ecea, we acknowledge pending messages when closing a
chat notification for a channel we are handling to prevent the channel
from popping up again immediately. While this isn't an issue for channels
we don't handle, the unread messages of the destroyed notification are
still considered for the messages indicator in the top bar, which is
clearly confusing (in particular when we end up showing the indicator
without any notifications in the list). As it's arguably correct to not
meddle with a channel handled by someone else, just reset the cache of
pending messages to address this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=770888
While a channel has pending messages, it will pop up again when
dismissed. That is clearly not what users expect, so clear them
out first before closing a channel.
https://bugzilla.gnome.org/show_bug.cgi?id=747991
Currently both the base classes for messages/sections and the message
list itself that instantiates the available sections are located in
the same module. As a result, it isn't possible to define sections
in a different module without introducing circular dependencies. The
Calendar module is already unwieldily large, so split it up a bit to
avoid it growing even bigger in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
Builtin chat and network notifications already follow the notification
policy of appropriate applications, it makes sense to do the same for
autorun notifications to give users control over hotplug notifications
in Settings.
There is nothing particularly critical about this notification, it
was only marked as such to get certain behavior like auto-expanding
and sticking-around to be acknowledged by the user (as it offers
more actions than the summary notification, so it is frustrating
when it goes away because it was missed).
As all notifications will now stay visible until we are sure the
users has seen them, the latter reasoning no longer applies.
Auto-expansion doesn't appear too important and may even be considered
annoying by users, so remove the CRITICAL hint now.
https://bugzilla.gnome.org/show_bug.cgi?id=657923
Since commit 79c04c93e4, we launch Polari instead of Empathy when
activating a chat notification for an IRC channel. It therefore makes
sense to follow Polari's notification policy for those notifications
rather than Empathy's.
https://bugzilla.gnome.org/show_bug.cgi?id=752881
Follow the design we have in gtk+ for buttons dialogs,
which are at the bottom and they expand full width, having
the same amount of space for each one.
Also, since this removes any space for non-button widgets
in the button area, move the spinner present in the auth prompt
dialog next to the password entry.
https://bugzilla.gnome.org/show_bug.cgi?id=746108
