593f659a73
We currently special-case the DISABLED error when initializing filtering, but not on app filter changes. While it seems reasonable that Malcontent.Manager wouldn't emit the signal while disabled, that's not actually true: It is emitted when any user account information tracked by AccountsServices changes. Even if the signal were limited to changes of the ParentalControls extension, it would still get emitted when app filtering *becomes* disabled. So regardless of potential improvements in libmalcontent itself, we should filter out the DISABLED consistently, both when creating the initial filter and when updating it. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6749 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2796> |
||
---|---|---|
.. | ||
config.js.in | ||
dbusUtils.js | ||
extensionUtils.js | ||
fileUtils.js | ||
gnomeSession.js | ||
history.js | ||
ibusManager.js | ||
inputMethod.js | ||
introspect.js | ||
jsParse.js | ||
keyboardManager.js | ||
loginManager.js | ||
meson.build | ||
modemManager.js | ||
objectManager.js | ||
params.js | ||
parentalControlsManager.js | ||
permissionStore.js | ||
signals.js | ||
signalTracker.js | ||
smartcardManager.js | ||
systemActions.js | ||
util.js | ||
weather.js |