Google Groups KillFile 3.4.2 Released
Well after poking around a bit I found all kinds of broken bits and pieces in the script and this release should work as you expect it to.
As always update your script by clicking on this link which will update your script to the latest and greatest.
Apologies with the bumpy release, hopefully it will be smooth sailing here on out.
Tags: killfile
Damian,
Everything appears to be working perfectly for me now!
Thanks a ton,
Nathan
Finally :) Glad it’s working out for you.
Hi Damian,
First of all, I want to thank you for this script. It has really provided a more enjoyable google groups experience for me. I have found what appears to be a bug in the latest version as well as some previous versions. When an author’s “name” is very long, like over 100 characters, which is permitted by google, clicking on the X next to the name in Topic List or on Ignore User in Topic Summary does nothing - it just sits there. There is one moron who is ruining the group I am in by constantly posting from a day in the future from his chinese server, thus always appearing on top, and he chooses very long names. If you could fix this, I would be much obliged. Thanks, Richard
Can someone post a topic:xxx I can use to kill all the MI5 spam?
Fred,
The following seems to kill much, but not all, of the MI5 spam. Just copy-and-paste the following to the end of your kill list:
%FFTopic%3AM%60I%205.*%FFTopic%3AM%27I-5.*%FFTopic%3AM%2CI.5.*%FFTopic%3AM-I%205.*%FFTopic%3AM.I%2C5.*%FFTopic%3AM%20I.5.*%FFTopic%3AM.I%275.*
This will kill topics that begin with the following:
M`I 5
M’I-5
M,I.5
M-I 5
M.I,5
M I.5
M.I’5
Oddly, when I add %FFTopic%3AM%27I.5.* (to kill topics starting with M’I.5 ), ALL of the topics reappear, but without the “X” next to them.
BUT … if I remove the previous entries, and have the same %FFTopic%3AM%27I.5.* ( M’I.5 ) so that it is the sole topic-killed item in the kill list, then topics with M’I.5 do disappear. Not only that, but topics with M’I-5 (which is not in the kill list) ALSO disappear.
Weird.
Regards,
Mark
Mark:
Thanx!
Fred
Hello Damien,
I’m having a problem with adding topics & wildcards to the killfile list.
For example, I click the X next to a post with this topic:
M,I.5 P ersecution my res ponse to th e haras sment
When the “edit window” pops up, I edit the topic name by adding the .* wildcard, changing the entry to:
Topic:M,I.5.*
However, the post still appears when I refresh the screen. And the killfile list does not have the string I entered, rather the entry has mysteriously morphed into this (extra “\” characters have been inserted):
Topic:M,I\.5\.\*
To “fix the problem” I can edit the entry in about:config, deleting the extra \ characters (which appear as %5C in the about:config entry)
Another problem (related?). After having edited the entry in about:config, I cannot remove the entry by clicking on “Killfile” and clicking the X next to the entry there. I must go to about:config to remove it.
Mark
p.s. This problem happens with two versions of Greasemonkey, 0.7.20070607.0 and 0.7.20080121.0,
and the recent Google Groups Killfile version 3.4.2 (I updated it on 1/26/08)
When a subject has been changed to a previously killfiled topic, the topic reappears and it appears that clicking on the X next to the new title has no effect.
E.g,
1. Title 1
2. Renamed Title (Killfiled as expected)
3. Re: Title 1
4. 2nd Renamed Title (Clicking on X has no effect)
Is there a known issue with Ignoring ‘truncated’ user names. When new users sign up and don’t give a nickname but give a long email address (ie. >35 characters), google truncates the username and inserts ellipsis just before the “@” sign in the User field of the post. At least in some cases, this seems to break the ‘Ignore User’ function. I’ve came across a particular case where a single poster is using two different User IDs: one with a nickname - which I can Ignore - and one with only the long email address - which I can’t.
To control harvesting of email address from Usenet, google now protects the expansion of those truncated User names with a character recognition task. Perhaps that’s somehow blocking the ‘matching’ process between the entry in the Killfile, and the Used ID at the top of each post?
It used to work, but I haven’t tested it since we moved to using regular expressions to do the matching (and . is a special regexp character)
I’ll do some testing and see if something broke.
You are all right, the regexp thing hosed the app… I’ll get it fixed in short order. Sorry about that.
Seems to find this type of address difficult to block:
el…@no.spam
probably: ellis@no.spam
Is it something to do with munged addresses?
This is the origial:
Path: g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!usenet-fr.net!club-internet.fr!feedme-small.clubint.net!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!sn-xt-ams-06!sn-xt-ams-05!sn-post-ams-02!sn-post-sjc-01!supernews.com!news.supernews.com!not-for-mail
From: el…@no.spam ()
Newsgroups: sci.geo.earthquakes,alt.talk.weather
Subject: Re: 17:14
Date: Sun, 09 Mar 2008 18:16:11 -0000
Organization: S.P.C.A.A.
Message-ID:
X-No-Archive: Yes
References:
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Originator: el…@no.spam ()
Cache-Post-Path: no.spam!unkn…@no.spam
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
X-Complaints-To: abuse@supernews.com
Lines: 9
It is yes. I plan to get this fixed early this week. Bear with me.
I’ve just uploaded an updated script 3.4.3 that I think has addressed the problems. Please let me know of any cases where it doesn’t work (include a URL and the username) and I’ll update things as necessary.
Happy Blocking.
Hmm, Seem to be having problems posting a comment. Second try.
I’ve made the following changes to my version that fixes the problem where multiple patterns attempt to kill the same topic:
— googlegroupskillfile.user.js.orig 2008-03-19 12:45:16.791559000 +0000
+++ googlegroupskillfile.user.js 2008-03-19 12:45:16.081662000 +0000
@@ -179,8 +179,7 @@
var user = cand.textContent;
var blocked = false;
- for (var j=0; j<list.length; j++) {
- blocked = false;
+ for (var j=0; !blocked && j<list.length; j++) {
topicRE.compile(”^” + list[j]);
if (topicRE.test(topic) || topicRE.test(user)) {
@@ -275,9 +274,9 @@
for (var i=0; i<candidates.snapshotLength; i++) {
var cand = candidates.snapshotItem(i);
var user = cand.textContent;
+ blocked=false;
- for (var j=0; j<list.length; j++) {
- blocked = false;
+ for (var j=0; !blocked && j= 0) {
wrappingTable = document.evaluate(”ancestor::table[2]“, cand, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
Tim.
Ahh, good idea Tim, I’ll incorporate this change in the next release.