Provide feedback to users when adding a custom filter with an invalid CSS selector
Background / User story
Brent from Betafish pointed out that when a user adds a custom filter with an invalid CSS selector, we no longer reject the filter and inform the user. This was intentional, we had to remove any code that used the DOM in the background page for the upcoming manifest V3 restrictions. That said, Thomas had an idea about how we could improve the user experience.
Suggested change
After the user adds a custom filter in the options page, if it has a CSS selector check that it is valid. If it is not valid, remove the filter again and display a message to the user $selector$ is not a valid CSS selector (syntax does not adhere to standard).
(see #228 (closed)).
- This is possible since our code running in the options page has access to the DOM API, unlike our code running in the background page.
- We'll need to take care to not display custom filters which have just been added, until after we have verified they don't have an invalid CSS selector. That way we can give the illusion that they didn't get added, when really they did but then were added before being quickly removed.
What to change
- Design: (Link to any designs here)
- Research: (Link to any research data here)
- Spec: (Create spec merge request and link to it from here)
Hints for testers
- Add this custom filter
^^SDKLS###!!!!!!! (&^()%^^$%$jhdrfs
, verify that a message likeLine 1: '#!!!!!!! (&^()%^^$%$jhdrfs' is not a valid CSS selector
is displayed. - Test what happens when large quantities of custom filters are added at the same time, ensure the feedback to the user still makes sense and that the interface doesn't become too sluggish.
Hints for translators
We might need to add the "is not a valid CSS selector" string again, if we removed it previously.
Integration notes
TBD
Edited by Thomas Greiner