New feature/script: Mutual Activity

[alleycatboy]

Description

This feature brings something I've seen many people request on the site: filtering your activity feed to only show your mutuals.

Blogs that get many interactions from non-mutuals have to scroll and scroll to find interactions from their mutuals; they find that they don't even notice when their mutuals @ them or replied to their posts.

User-facing changes

This adds a toggle button to the activity page that only shows from their feed, and optionally shows grouped notifications.

Technical explanation

Filtering of non-mutuals is done through toggling the style element inherent to "following" and "rollup" notifications.

Filtering of grouped/rollup notifications is done by checking the state of the Filtering dialog modal and toggling the checkbox only if it is out of sync with the user preferences.

The script uses a registered pageModifications on the Activity page body to check if it should run or not.

On the dialog modal has a display: none and the Filters button is disabled while checking the state to avoid user interference , though the time window for user interference is extremely small. Additionally, it checks if the user already has the dialog open or not.

While the "Mutuals only" filter is enabled, the "Group similar notifications" option is disabled and is telegraphed to the user that the preference is controlled by the script.

When the page is reloaded or navigated to, the previous state of the toggle button is recalled from browser.storage.

When filtering is enabled, a phantom scroll event is triggered on the feed container to trigger loading of more notifications.

Testing steps

Simply enable the extension and click on the "Mutuals only" toggle button to activate and deactivate.

Here is the default action:

When grouped notifications are enabled:

The filter dialog when group notifications are disabled:

The filter dialog when the "Mutuals only" toggle is disabled:

Behavior has also been tested in various color pallets, different screen sizes, and Firefox mobile.

[marcustyphoon]

Ooh, fancy.

• keyToCss() is fast enough to be effectively free to call; feel free to use it inline. Extracting selectors as constants is good when it increases clarity, but doesn't need to be done to the maximum extent possible, when it can reduce clarity!
• I see you're running the code to open the filter dialog, do something, and then close it without any await statements in between them; this means that the entire action is performed within the same javascript event loop task. There is thus no user input processing and no page render possible between the first and last task, and thus the glass-container-hide-and-show and filter-button-disable-and-enable can be removed without any change to functionality!

[alleycatboy]

• keyToCss() is fast enough to be effectively free to call; feel free to use it inline. Extracting selectors as constants is good when it increases clarity, but doesn't need to be done to the maximum extent possible, when it can reduce clarity!

I agree! I try to keep magic strings within the executing and repeating code to an absolute minimum as it makes refactoring a breeze.

• I see you're running the code to open the filter dialog, do something, and then close it without any await statements in between them; this means that the entire action is performed within the same javascript event loop task. There is thus no user input processing and no page render possible between the first and last task, and thus the glass-container-hide-and-show and filter-button-disable-and-enable can be removed without any change to functionality!

Nice catch! That was a holdover from an earlier method I was attempting with await on those functions. Just tested it and removed those functions.

Overall, very constructive review! I'll push changes with your suggestions.