Sleazy Fork

Awesome work! I was in the process of updating my old userscript, but then I found this one and I might just abandon mine lol.

I do have a couple requests though:

• The buttons on mobile are partially covered by a search icon so ideally they would be moved somewhere more accessible
• There are some more annoyances to consider removing: "live" button in sidebar, the "informationBar" banner, the onlyfans sidebar, etc

More detail for the annoyance part:
- "liveAd" sidebar button (can just display: none)
- "injection" divs (they show up in home feed on mobile) (can just display: none)
- "onlyfans sidebar" divs (can leave this tbh, not too intrusive)

The livestreams still show up on mobile; I worked around this on my script by just removing the element when it had a child with class '_StreamateCamera_1eekr_1'. The class does only show up when it initially loads the stream though. Alternatively, you could just remove the entire div, but I'm not sure VisibleOnly just applies to the streams.

Thanks for the kind words and the detailed feedback!

To be honest, I hadn't considered mobile users at all, mainly because I'm only on desktop myself. (Am I the minority here? lol). I'll fire up my browser's mobile emulation and see what's going on with that search icon.

And thanks for the detailed list of other annoyances. The liveAdButton is a definite candidate for removal. I'll investigate the other items you mentioned and consider them for a future update.

As a side note, I've been debating whether annoyance removal should be a core part of this script, especially since I added the .GifPreview.VisibleOnly rule. I tend to think that job is better left to dedicated ad-blocker extensions, but I'll have to weigh the convenience.

Thanks again for the helpful report!

Yeah, I had similar thoughts on the annoyance removal too. I justified it since some are pretty easy to hide/remove, but I can see how it could get out of hand (especially with future site updates). I would be fine either way; worst case could always make a separate userscript just for that.

Hi, I've just published v1.4.0, which should address most of the issues you pointed out.

I fired up the mobile emulator and you were spot on—the buttons were definitely in a bad spot. I've adjusted their positioning, so they shouldn't overlap with the native icons anymore.

I also took your advice on the annoyances. I've added a new AnnoyanceManager. The new method for blocking in-feed ads is much more robust on desktop and mobile I think.

Please let me know if it's working for you.

Just tried the update out and LGTM, thanks!

Glad to hear that! Thanks for checking it out!

Found another possible annoyance to consider if it's not too much trouble. I've found them when scrolling in a niche both on desktop and mobile.

There are some planted gifs that act as ads where a button links to an external site (I assume). Usually they're shown to be from users like "Ersties", "Brazzers", "Candy AI", etc. Anyway, the main way I've seen to differentiate them from normal gifs is inside the MetaInfo where there are classes like "metaInfo_isBoosted" and "boostedBtn".

I'm sure there is probably another way to detect them because attempting to download them with the userscript gives the "HD URL not found in cache" error unless you open them in a new tab.

Hi. Thanks for the detailed report. I was also aware of those .metaInfo_isBoosted / .boostedBtn ads.
I had intentionally held off on blocking them in the current version, because unfortunately, removing them cleanly is very tricky.

The core problem is that those ad posts are structured exactly like normal video posts, specifically with a pre-defined aspect-ratio (height).
When I try to remove them with display: none (which is the standard way), the browser loads the post, reserves its full height, and then the script hides it. This sudden layout change causes a really jarring "flicker" as you scroll.
I also tried an alternative (visibility: hidden) which fixes the flicker, but it just leaves a massive blank space where the ad was, which also looks broken and confusing.

Because these ads have a defined height (unlike the other ads the script blocks), it's very difficult to remove them cleanly without causing either a flicker or a blank void.

I'm currently looking into a compromise: a way to hide the ad content while leaving the "space" intact, and then putting a simple message like "Advertisement Hidden" inside it. This would stop the flicker and clearly show what the script did, instead of leaving a weird empty gap.

I'll keep you posted if I can get that working well.

Hmm, when I tested out the display: none !important; with your sentinel code I don't get any kind of flicker (desktop and mobile). I also tried messing around with some other methods like setting position: absolute + top: 9999px + left: -9999px, but that was basically the same as display: none in my testing.

I had [class*="metaInfo_isBoosted"] for the sentinel matching and then found the closest .GifPreview to hide, similar to your existing code for the streams.

Hi, you were absolutely right.
I tested your suggestion of using the Sentinel (JavaScript) approach to apply display: none instead of pure CSS, and it works perfectly. No flicker at all, even on mobile.
I think the flickering was caused by the CSS :has() rule. The JavaScript method seems to run quickly enough to hide the container before the browser finishes calculating its layout height, which prevents that visible "jump".

This is definitely the right solution. Thanks so much for the great feedback! I'll include this fix in the next update.

v1.4.2 is out now. Give it a try!

Works great, thanks

Hi, the FeedModule that contain Streamate live streams are showing as blank sections on mobile (haven't tested desktop). The actual content is blanked because of the VisibleOnly rule but the container still exists. I fixed this locally by adding `.FeedModule:has(.StreamateCameraDispatcher),` to the Annoyance Styles section.

Also, the OnlyFans creator FeedModule has been popping up again on the mobile home page as it seems the class name changed. It now contains a `.AdCreators`.

Alternatively, I've seen attributes like `data-feed-module-type="live-cam"`, `data-feed-module-type="only-fans"`, and `data-feed-module-type="niche-explorer"` for these types of FeedModules which seems like it may be more resilient to changes to the site. Let me know what you think, thanks.

Thanks for the detailed info! I agree that relying on data-feed-module-type is much more resilient.
I've updated the script to use those attributes and fixed the blank section issue on mobile. Please give it a try.