
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>