feat: Show controls when hiding a post on its permalink page

[marcustyphoon]

Description

Note to self: the "Hide all posts from blogs I've blocked" tweak currently hides posts unconditionally when they're viewed by themselves if they have a blocked blog in the trail, something which this PR (iirc) carefully avoids; consider making these consistent.

I think we should never be outright hiding posts if we're on their permalink page; maybe we should have a "hide this post" util which checks for that and inserts a signpost in the permalink case. (No plans to do this myself, please implement this if you want to.)

Originally posted by @AprilSylph in #677 (comment)

Resolves #2029.

Semi-blocked by #719 (these should both have consistent appearance, so whichever of them is reviewed first should be approved before working on the other).

Here's an experiment that moves our basic "hide this post" logic into a util and, as discussed above, implements a controls element instead of a mysterious blank space if the post is being viewed on its permalink page. UI copied from #677 (which probably can't actually use this without some more refactoring, but oh well) / #719. I'm not sure if it actually handles blog colors very well; I haven't looked at it in ages.

Features may specify the message for the modal; if they don't, posts are simply never hidden on permalink pages, again as discussed above.

If I did this correctly, it should work if a post is hidden by multiple utils, and there shouldn't be lifecycle bugs even in that case.

outdated

const { hidePost, showPosts } = createPostHideFunctions({
  id: 'tweaks-hide-blocked-blogs',

  // Only applies to posts hidden by a blocked blog in the trail (see isTimelineExempt below)
  controlsOnPermalinkPage: {
    message: 'This post contains a blocked blog!',
    buttonText: 'show post anyway',
  },
});

Updated appearance, from #719:

const { hidePost, showPosts } = createPostHideFunctions({
  id: 'tweaks-hide-blocked-blogs',

  // Only applies to posts hidden by a blocked blog in the trail (see isTimelineExempt below)
  controlsOnPermalinkPage: {
    message: 'This post contains a blocked blog.',
  },
});

Testing steps

• On e.g. https://www.tumblr.com/search/evil%20science/recent?src=typed_query, confirm that No Recommended can hide posts from non-joined communities, and that they reappear when the feature is disabled.
• Block a post with PostBlock and confirm that it disappears, reappears when PostBlock is disabled, and is replaced with the new UI when viewed alone when PostBlock is enabled.
• Enable the "Hide all posts from blogs I've blocked" tweak and block a blog like tumblr.com/fandom. Confirm that a post containing content from that blog in the trail, like https://www.tumblr.com/azul-ocean24/803113081314099201, is replaced with the new UI. Confirm that a post by that blog, such as https://www.tumblr.com/fandom/803112786763907072, does not use the new UI (since you already click through "You have this Tumblr blocked, so we've hidden it from your view." to see it).
• Filter some content in a post, enable the "Hide filtered posts entirely" tweak, and confirm that the post disappears, reappears when the tweak is disabled, and is replaced with the new UI when viewed alone when the tweak is enabled.
• Use postblock on the post with a blocked blog in the trail. Filter a term in it, too, why not? Confirm that all three UI elements are displayed in place of the post, and that you must click all of them to make the post appear. (We could write code to make a single element appear in this case, which is probably better UX, but then we'd have to write the UI copy in a composable way, and does that seem worth it?)

• Like a post... look, test the "Hide posts that I've liked on the dashboard" and "Hide my own posts on the dashboard" tweaks, ok?

[marcustyphoon]

• feat(Postblock): Make options UI items links if possible #719 merge; UI changes

[marcustyphoon]

Could probably remove the button text override and just set it to "View post" unconditionally, really. This would go along with removing the ability to disablehideManually and use the hiddenAttribute, controlledHiddenAttribute, and controlsAttribute exports.

(I wrote these all in to be able to use the utility in the Mute feature, which has a mode where it hides an entire timeline with an informational message like this. It probably makes sense to export the UI at a lower level for this and handle any complexity in Mute, rather than adding a bunch of complexity to this code path, I imagine.)

[AprilSylph]

Ugh, just found a slight regression from #719 in testing this PR: unblocking a post via the control panel doesn't visibly unblock the post on its permalink page anymore.

Before: post is hidden, then becomes visible when unblocked
After: post is collapsed; unblocking does not change this

[AprilSylph]

I guess it's still valid to request it be fixed in this PR, since the same regression is built into the util that supersedes the PostBlock-specific functionality.

[AprilSylph]

That aside, I do want to say that the new util file is absolutely beautiful.

[marcustyphoon]

A minor annoyance I've noticed while fixing that: if you have a filtered post hidden on a permalink page, you click "view post" to unhide the post, which shows you a filtered post (reasonable)... but then when you click "view post" in the filtered post it gets hidden by our util again, so you have to click one more time. So I guess... oh, this is easy to fix; check for controlledHiddenAttribute.

[marcustyphoon]

Additional testing steps:

• Filter some content in a post, block it with postblock, and view it on a permalink page. Confirm that clicking through to view it takes two clicks (when it transitions from filtered view to not-filtered view, it's not hidden again; the fact that you clicked to view it persisted).
• Refresh. Unblock it from the control panel. Confirm that it's shown.
• Immediately re-block it. Confirm that it is hidden again (the showPost util call cleaned up everything, so it can be blocked again; the fact that you clicked to view it did not persist).

[AprilSylph]

I don't like that a single post hidden for multiple reasons shows two signposts at the same time, which must both be dismissed before the post becomes visible.

I'm not entirely sure what I want to happen instead, though. Maybe CSS that hides a signpost when preceded by another signpost, so that they become layered instead?
i.e. "This post contains filtered tags or content." → View post → "This post is hidden by PostBlock." → View post → (The post)

[marcustyphoon]

Oh, if I'd thought of that as an implementation method for the layering I probably would have done it, yeah. I think that's an improvement on showing both. Not quite as elegant as combined text, but as mentioned I don't think that's worth implementing and I don't have any better ideas at the moment.

[AprilSylph]

I think this is a regression from 78c4300: the util no longer behaves correctly on restarting the addon.

Post is collapsed with signpost → restart XKit Rewritten → post is shown

[marcustyphoon]

Oh, if I'd thought of that as an implementation method for the layering I probably would have done it, yeah. I think that's an improvement on showing both. Not quite as elegant as combined text, but as mentioned I don't think that's worth implementing and I don't have any better ideas at the moment.

I guess technically the copy could be This post ${elementsAsList(messages, 'and').join('')}. That would elegantly create "This post contains a blocked blog and is hidden by PostBlock."

edit: Hm, this would be a util rewrite. Maybe I'll try it at some point. It's too bad you can't use content: "This post " attr(something that grabs multiple attrs somehow) "."; here; that would have been fun.

[AprilSylph]

Works the way I want it to! Huge UX improvement.

Do you still daily-drive master? I was thinking I could give you the weekend to beta-test this, and then do a release on Monday.

[marcustyphoon]

I do indeed daily-drive master*, though I don't really use any of the post-hiding utils regularly. Still, may as well see if anything explodes.

*haha uh... plus a bunch of additional random junk like #1625.