The Filter module implements an UninstallValidator that prevents a module from being uninstall if it provides a filter plugin that's actively being used by some filter. To resolve it, a site admin must simply remove the filter plugin from any active filters.
However, if the filter plugin is enabled on a filter by means of a configuration override, then there is no way to remove it. If the module providing the override is the one you want to uninstall, it's impossible.
I ran into this myself because I'm working on a distribution that has an optional module that, when enabled, modifies an existing filter config entity to add another filter plugin. The module should be able to be uninstalled.
Not sure what the best fix for this is, it seems like it would be pretty complicated to detect if the filter plugin is actually provided via a config override. In the meantime, I will apply a patch that just disables this check.
I think that this uninstall validator may not be necessary? I'm not sure on the original intent, but I suspect it was so that admins didn't accidentally break their site by removing a module that provided an important filter plugin. In any case, it shouldn't actually break the the filter config entity, since they will already remove filter plugins from active filter when the module providing them is uninstalled:
/**
* {@inheritdoc}
*/
public function onDependencyRemoval(array $dependencies) {
$changed = parent::onDependencyRemoval($dependencies);
$filters = $this->filters();
foreach ($filters as $filter) {
// Remove disabled filters, so that this FilterFormat config entity can
// continue to exist.
if (!$filter->status && in_array($filter->provider, $dependencies['module'])) {
$this->removeFilter($filter->getPluginId());
$changed = TRUE;
}
}
return $changed;
}