• 4 Posts
  • 102 Comments
Joined 2 years ago
cake
Cake day: July 2nd, 2023

help-circle





  • What an insightful post 🙂

    The only one of these I’ve updated since the original is the one for Ars Technica, which is now this:

    arstechnica.com##:not(:not(head>title:has-text(/Serving the Technologist/))) article:has-text(/Trump|Elon|Musk|nazi|doge|maga/i)

    The reason being that ‘Ars Technica’ now appears in the title of articles, while it didn’t originally, which caused the original filter to block out entire articles. ‘Serving the Technologist’ only appears on the homepage so this updated filter will still filter the homepage but display the contents of articles that contain blacklisted words.




  • zkfcfbzr@lemmy.worldtoLinux@lemmy.mlFirefox 135.0 released
    link
    fedilink
    English
    arrow-up
    99
    ·
    4 months ago

    Firefox now includes safeguards to prevent sites from abusing the history API by generating excessive history entries, which can make navigating with the back and forward buttons difficult by cluttering the history. This intervention ensures that such entries, unless interacted with by the user, are skipped when using the back and forward buttons.

    Nice


  • Hello again 🙂 I have a good feeling about this one.

    infosec.pub##:not(head>title:has-text(/leopard/i)) article.row:has-text(/Trump|Elon|Musk|nazi/i):not(:has-text(/leopard/i))
    

    It’s doing basically the same thing as the last one but now instead of targeting an <a> tag with the community-link attribute, which was basically just the first way I was able to find of identifying a community last time, it targets the title of the page itself, which seems like it should be a lot more reliable. This does mean using the literal leopardsatemyface-type filter won’t work since the title of the page is the community’s user-friendly name: “Leopards Ate My Face” in this case.

    So as before it should block any posts which contain words from the blacklist, unless they also contain words from the whitelist - and now if the title of the page has any words from the whitelist (indicating we’re on an allowed community page), it will block nothing at all. The blacklist and whitelist will apply to the post title, community name, and even the submitter’s name - anything you can read and even some things you can’t read.


  • I think I may see why. I didn’t actually bother to check the main feed before, but it seems like it does have the a.community-link tag the new filter targets in every post - so if a post from leopardsatemyface ever shows up in the main feed, then the filter will think it’s on that community page and fail to block any posts. But the filter should work fine so long as no posts from that community are currently on the main feed. This should be the case regardless of which regex is used - if it wasn’t just a coincidence earlier I’ll have to test around to figure out what happened with that.

    It’s a process making a good filter, I guess - I may look into a more reliable and narrower way to achieve the desired effect later on



  • Hey! I’m pretty sure this one will work:

    infosec.pub##:not(a.community-link:matches-attr(title=/.*?leopard.*?/i)) article.row:has-text(/Trump|Elon|Musk|nazi/i):not(:has-text(/leopard/i))
    

    Where now we have three filters. If the community name matches the first regex, then nothing at all will be filtered out - and then the other two work the same as before. So any post that matches the blacklist regex will be filtered out unless it also matches the whitelist regex.

    I chose to make the first regex /.*?leopard.*?/i because my thinking is you may want to just copy/paste the other whitelist filter there for simplicity, but it might make more sense to do it like the others, like /leopardsatemyface|second community|third community|etc/i. The “title” of a community for the purpose of this filter should be whatever appears after /c/ in the URL, not counting the @lemmy.world (or whatever instance) part.



  • I’m not sure I follow - the filter seems to work as-is to me. It allows posts on both the front page and the !leopardsatemyface@lemmy.world to bypass the filter for me.

    To be clear, it’s not only applying to the title row - the article tag it targets contains the entire post as it appears in the post feed, including the title, community name, the person who submitted it, the timestamp, etc. So if anything there contains a filtered or whitelisted word it should trigger the filter.

    I wouldn’t have necessarily expected the whitelist filter to work directly on the leopards community page, since posts on community feeds don’t include the community name, but it works anyways because, it seems, there’s a hidden mod option in the HTML with the community name in it: <div class="modal-body text-center align-middle text-body">Are you sure you want to transfer leopardsatemyface@lemmy.world to TheBat@lemmy.world?</div>



  • At one point I had the very similar filter lemmy.world##.post-listing:has-text(/trump/i), but I wasn’t happy with it because it would also remove post content on actual post pages, not just the post feed. That was the whole reason I swapped to the article.row solution instead - posts in the feed have the row class while posts on their own page don’t. But it looks like you found an alternate solution to achieve essentially the same thing. Neat!

    I have no real interest in filtering out comments, but it’s nice to have that option there for people who do.