MediaWiki talk:Gadget-contribsrange.js/Archive 1

Archive 1

Request for more ranges

Very nice Gadget. However, at german wikipedia we mostly need /17 up to /22, maybe there is some fast way (multiple requests for smaller ranges? bigger requests and postfiltering?). Regards, Codeispoetry (talk) 11:48, 26 March 2008 (UTC)

That would require rewriting the script to use ajax POST, as the GET request used in the <script> is limited to around 4000 characters (which just fits in a /25). The problem however quickly becomes mathmatical: 255.255.255.255/24 is 3986 characters (even though /24 uses ucuserpreifx, which can only be done meaningfully for /8, /16, /24):

ucuser=255.255.255.0|255.255.255.1|255.255.255.2 ... 255.255.255.255.

255.255.255.255/22 would be 15944 characters, 255.255.255.255/17 would be over half a meg... I don't think supporting down to /17 would be very good. --Splarka (rant) 07:22, 27 March 2008 (UTC)

Error

Perhaps someone can explain why Special:Contributions/71.100.0.15's edits are not showing up at Special:Contributions/71.100.0.15/16. This is a bug, if I'm not mistaken. The Evil Spartan (talk) 19:37, 15 July 2008 (UTC)

Per the above section, they would show if the API were as it was when this script was written, but several changes have made pagination pretty broken (and unsupportable in javascript, actually). It should work if you do something less specific, eg: Special:Contributions/71.100.0.15/28. --Splarka (rant) 07:05, 16 July 2008 (UTC)

Current problems (May 2008)

Per the copy from my userspace currently here, and with some modifications made to the API, there are some problems with this gadget.

• Some optimizations of ApiQueryUserContributions.php means that it currently sorts by username first, instead of by date. So the first users found will fill up the specified limit before more users are found. Not really a good JS solution, waiting on a solution in the API (such as a dedicated CIDR function).
  • The optimizations have also broken pagination, there is not yet a solution to this. This is fixed in newer versions of the API.
• /25 and /26 ranges may currently be broken, due to a hard-coded limit of 50 parameters (this module performs uneven CIDR ranges using a pipe separated list &ucuser=1.2.3.0|1.2.3.1 ... but the list limit is 50 (the sysop limit of 500 is not applicable, due to the callback method used)). Possibly this could be overcome by rewriting this as an ajax module, but hopefully a CIDR function will be made available.

Really, the best solution is to write in CIDR support into the Special:Contributions page server-side and do away with this gadget ^_^. Caveat emptor: As it is now it is not really useless, but results may be deceptive and not all inclusive. --Splarka (rant) 03:18, 11 May 2008 (UTC)

See update below. This section might need cleanup after next sync. --Splarka (rant) 11:19, 25 October 2008 (UTC)

Diff Links && Popups gadget

Seems all the diffs are of the form http://en.wikipedia.org/w/index.php?title=-&curid=2525061&diff=87268322 Which all have an invalid title parameter. Q ^{T C} 22:10, 12 June 2009 (UTC)

Nevermind, seems to be the Popups gadget not liking having the title parameter and tries to load those revisions of the - article. Since diffs work the same regardless and you're already pulling it from the API why not include the correct title parameter to appease Popups? Q ^{T C} 22:20, 12 June 2009 (UTC)

It is there because &curid used to only work if a &title parameter was included, even though it was totally ignored. This was fixed after I wrote the script, so it could be removed. I guess I didn't include the full title because it was a bit spammy and redundant. --Splarka (rant) 00:30, 13 June 2009 (UTC)

Per these changes it should work now. But popups definitely should recognize &curid and ignore &title if present, as well as properly handling &diff=number as &diff=prev&oldid=number and NOT as &diff=next&oldid=number as it seems to. --Splarka (rant) 06:11, 13 June 2009 (UTC)

Expand All problem

Great gadget, but there seems to be a compatability issue with Internet Explorer 8. In IE8, the Expand All button does not work (it works in Firefox on the same computer).

Also, it would be useful to have a Condense All button as well as the Expand All button, especially when doing a /16 search. Thanks. --Zach425 ^talk/contribs 12:59, 30 August 2009 (UTC)

I don't know how to fix it for IE8, unless it was a recursive template call problem (in which case it should be fixed). I've changed the button to 'toggle all' which should switch all lists to the opposite visibility of the first one (inclusvely). So if the first one is expanded, they will all be collapsed, etc. --Splarka (rant) 08:46, 10 September 2009 (UTC)

Date range

For anti-vandalism purposes, this would be much more useful if it could give results since rather than before the date. Better yet, the ability to sort results by most-recent use. An ip-hoping vandal often hops shortly after a block, a pattern that should be easily detected.LeadSongDog come howl 16:14, 27 May 2009 (UTC)

Using since or even a narrow date range is possible with this specific API query, but not with the Special:Contributions UI. This would involve creating UI elements which is also possible but cluttery and possibly confusing to the interface. Sorting by date in the query is not possible, because of the method used to return the results (which sorts by user first, then by date). It could only sort the results by date upon completion of /all/ queries, which, if it were many thousands, could freeze the browser for several seconds or minutes. This would be best done with a toolserver tool, probably. --Splarka (rant) 07:35, 28 May 2009 (UTC)

I must be missing something. How, exactly, is a "since" query possible? LeadSongDog come howl 16:10, 9 September 2009 (UTC)

Here is an example. It shows a day of edits for &ucuserprefix=195.229.242. (195.229.242.0/24) using the parameters: &ucdir=newer&ucstart=20070101000000&ucend=20070102000000 . The problem is, this gadget works off of the existing Special:Contributions UI which wouldn't permit such specificity. I could probably add some dummy URI parameters that you could type manually though. --Splarka (rant) 07:44, 10 September 2009 (UTC)

Oh, I guess I already did. This version allows ucstart and ucend to be supplied manually via URI parameters. It just needs to be synched with the gadget. --Splarka (rant) 08:10, 10 September 2009 (UTC)

Okay, done. Try a URL like this. Note it has to be done manually. --Splarka (rant) 08:43, 10 September 2009 (UTC)

Thank you, thank you. That does it. The gadget will be a big help.LeadSongDog come howl 13:57, 10 September 2009 (UTC)

Ranges + sorting

Two issues I'd like to bring up:

• 1) The sort is done in alphabetical order, which is icky for numbers. It would be nice to code in an instance of making it go numerically, if not too processor intense.

• 2) Doing ranges other than /16 /24 or (obviously) /32 would be really nice. And, if you think outside the box a bit, you'll realize it can be done quite easily by just parsing the results on the client end. So a /17 wouldn't necessarily mean 2^15 searches... rather just pruning the /16 result once we retrieve it. Magog the Ogre (talk) 16:04, 19 November 2010 (UTC)

Bug: actual username has trailing wildcard character

See Wikipedia:Village pump (technical)#Username with trailing wildcard. DMacks (talk) 18:46, 10 June 2012 (UTC)

Really?

The Preferences page entry for this says that it does wildcard prefix searches, e.g., Splark*. But it also seems oriented towards Special:contribs. So, I just have to ask, being search and prefix oriented at the moment: Do you mean prefix as in the search parameter prefix:? I'm pretty sure I'm off here, but there is documented at Help:Search the prefix: parameter as applies to page names, not users. I was just searching through gadgets for search gadgets, and found four of them, and could not help tripping over yours as a possible fifth one. (Besides that wording there is another: at first the "wildcard prefix" in the example looked like a suffix, 'til I finally got that it meant the name was a prefix.) Cheers. — CpiralCpiral 09:22, 24 April 2013 (UTC)

IIRC it wasn't as confusing at the time, as the "prefix:" parameter was added to search several months after that description was phrased: [1] vs [2]. I am not sure of a good way to rephrase, maybe "trailing wildcards" or something? --Splarka (rant) 16:43, 25 April 2013 (UTC)

Update (October 2008)

Per rev:42198 it is now possible to accurately continue the query once again. I've rewritten the script heavily in order to take advantage of this, and am testing it now at User:Splarka/contribsrange.js (new permlink but more changes may occur).

New features:

• Redesigned output a bit. Uses DIVs and UL/LI sets instead of text and BR. Also uses progressive status thingy next to spinner.
• Will now query-continue almost forever. It stops after 10,000 edits found unless you bypass this (link provided in abort message).
• Groups them by contributor, similar to enhanced recent changes. If there is only one match, it expands this, else all are collapsed.
  • Tells you by each contributor the number found.

Any objections to syncing this gadget with my copy (after a day or two)? Any suggestions/thoughts on improvements/streamlines? --Splarka (rant) 11:17, 25 October 2008 (UTC)

I like the sound of that. I've had to press "ctrl+f" to find the date of recent edits. Ah, and I'm having some other issues with the way the results are limited to being shown chronologically.

For example, when the CIDR prefix of a range is /20 (like 74.230.96.0/20), then I have to search for Special:Contributions/74.230.96.0/16 so that I don't miss anything. I have to click "next 500" to show the third octet below 74.230.86.x. It does gradually get lower, but it's outdated as well, as you can see in the address bar. Is that solved, or is it still going to be an issue?

Also, I'm wondering if there's a way to make this tool globalized, because the one on toolserver, which doesn't work on enwiki, can be used for other projects. That tool sorts it by date and chronologically but can't navigate to the older edits; it also lacks something that this one doesn't, which is entering queries in CIDR notation (which is used to determine rangeblocks).

Otherwise, I'm fine with it all. I can't say I've tried out Splarka's update yet, but when you can safely say that it's stable (whenever that is), then that's when I might try it out :P I'm sure that it's a great tool and it definitely has a lot of potential. ~ Troy (talk) 19:40, 26 October 2008 (UTC)

The update solves the 'next 500' issue by ... well, try it out. It will find up to 10,000 (and more if you decide to continue). It is now synched, and there should be no outstanding issues (except possibly with /25s, use /24 if you want to be sure) that I know of. Let the testing begin....? --Splarka (rant) 22:52, 5 November 2008 (UTC)

Looks like it works out ...but there's one tiny problem. I can't seem to expand them all. Otherwise, it works pretty well. Of course, I can't complain; I would never be able to work these issues myself (what a pity :P) ~ Troy (talk) 05:15, 6 November 2008 (UTC)

Sub-update (November)

Oops, I never considered stylepath would be non-local. Small tweak may be needed here. --Splarka (rant) 09:23, 18 November 2008 (UTC)

Sub-update (December)

Had to disable /25 and /26 due to API parameter count restrictions. Use /24 instead. --Splarka (rant) 10:03, 3 December 2008 (UTC)

Broken?

The widget preference page says to report any issues here, so (a copy of my comment here):

Broken? http://en.wikipedia.org/wiki/Special:Contributions/46.235.152.24 shows changes that http://en.wikipedia.org/wiki/Special:Contributions/46.235.152* does not - it shows edits by .21 and .41 only - not these edits by .24 ! I have the gadget enabled, and was unable to search using CIDR - my attempts produce "No changes were found matching these criteria."

Yet, the help text states, "You may enter a CIDR range or append an asterisk to do a prefix search."--Elvey (talk) 20:57, 28 May 2013 (UTC)

See Wikipedia:Village_pump_(technical)#Contribs_from_a_CIDR_range_out_of_date.3F. Change the "year" field to 2014 manually to work around this for now. --Splarka (rant) 21:18, 28 May 2013 (UTC)

IP wildcards and CIDR ignoring an address

I'm looking for all contribs from 194.61.160.0/20. I see from the description on the prefs page that /20 is not supported, so I looked for 194.61.162.0/24 to start with: [3]. This yields:

194.61.162.75 2 found
194.61.162.72 10 found
194.61.162.71 13 found
194.61.162.6 199 found
194.61.162.51 24 found
194.61.162.50 6 found
194.61.162.49 11 found
194.61.162.48 38 found
194.61.162.47 33 found
194.61.162.46 12 found
194.61.162.104 2 found
194.61.162.100 4 found

but not 194.61.162.79, even though there are contribs for that address here. I also tried searching for 194.61.162* and got the same results as above. Searching for 194.61.0.0/16 and 194.61.16* yield many more results, but still not 192.61.162.79. —[AlanM1(talk)]— 17:24, 26 June 2013 (UTC)

There is a bug in the currently deployed version that is fixed in User:Splarka/contribsrange.js. See this explanation as to why it has only recently become an issue. Quick workaround is to change the year to 2014. --Splarka (rant) 09:05, 27 June 2013 (UTC)

Cool. Do you know of a way I can change the Contributions link that appears in the linklist at the upper right of pages (with Talk, Sandbox, Preferences, Watchlist, Contributions, Log out) to https://en.wikipedia.org/wiki/Special:Contributions/AlanM1?year=2014 to populate the year automatically with the workaround value? —[AlanM1(talk)]— 06:00, 28 June 2013 (UTC) —[AlanM1(talk)]— 06:00, 28 June 2013 (UTC)

You could do it with a script, but it would probably be easier to find a mod and convince them to test and update the gadget (or just use User:Splarka/contribsrange.js directly). --Splarka (rant) 07:04, 28 June 2013 (UTC)

Better implementation

Can't we do this with a toolserver tool?

The query seems to be reasonably simple:

SELECT rev_user_text,rev_title,rev_comment,rev_timestamp FROM revision WHERE rev_user=0 AND rev_user_text LIKE '12.34.%' AND inet_aton(rev_user_text)<some_num AND inet_ntoa( rev_user_text) > some_num;

Werdna 05:12, 28 September 2008 (UTC)

tools:~vvv/rangecontribs.php can show IP range contribs (it accepts 1.2.3 or 1.2), but it says "this tool is temporary disabled for enwiki because of some performance reasons". —AlexSm 03:54, 29 September 2008 (UTC)

tools:~krinkle/MoreContributions/input.php can be used. However, only asterisks can be used; CIDR ranges in input does not work. --Glaisher [talk] 08:43, 12 March 2014 (UTC)

Protected edit request on 28 February 2014

See also: WP:Village pump (technical) § CIDR range contributions broken?

Hi!

Could someone apply these updates to the gadget? Thanks! Helder.wiki 20:29, 28 February 2014 (UTC)

Helder.wiki, what do you mean? Should I simply dump the entire contents of this revision into the page? I don't understand .js at all, so I need to be given very simple instructions. Nyttend (talk) 13:38, 4 March 2014 (UTC)

Yep! I usually paste the new version of the code in the sandbox to make it easier to copy, and provide a diff between the two pages to make the review easier too. So, Nyttend, in this case, you should replace the content of MediaWiki:Gadget-contribsrange.js by the content of this version of the sandbox. Helder.wiki 13:44, 4 March 2014 (UTC)

Done. Doing it like this, requiring me to do nothing except for copy/pasting all code from a page, is the best possible way to propose changes. I just wasn't sure if you were wanting that, or if you wanted me to replace part of the page, or something else. — Preceding unsigned comment added by Nyttend (talk • contribs) 22:35, 5 March 2014

• Nyttend, can you undo this change as it seems to coorolate with the issues reported WP:VPT#CIDR range contributions broken?. Helder, can you look into what might have caused this as well... When I try to bring up a CIDR range in Special:Contribs, it returns one result and then seems to lock up (Searching... doesn't go away but it doesn't return any more results). I'll run it again with ?debug=true and try to get some more information for you. — {{U|Technical 13}} ^{(t • e • c)} 00:03, 12 March 2014 (UTC)

• My comment at WP:VPT. Nyttend (talk) 00:14, 12 March 2014 (UTC)

As far as I could see by testing the previous version of the script in the console, the error reported on VPT was already happening, so I didn't think it was introduced by these recent changes. When searching for 109.157.154.0/24, this was the message in the console:Helder.wiki 02:18, 12 March 2014 (UTC)

Nyttend, could you make these changes to MediaWiki:Gadget-contribsrange.js and then enable ResourceLoader in the definition of the gadget? This version is working fine on testwiki. Helder.wiki 17:56, 12 March 2014 (UTC)

I updated the link to include also a fix for the bug which appeared when we first replaced addOnloadHook -> $. Helder.wiki 18:46, 12 March 2014 (UTC)

addOnloadHook -> $

I added a copy of this gadget to testwiki:Special:Preferences#mw-prefsection-gadgets which, after enabled, can be tested at testwiki:Special:Contributions/93.219.52.0/24. Apparently, we can restore most of the updates, except for the change from addOnloadHook to $. Helder.wiki 03:08, 12 March 2014 (UTC)

• I can confirm the copy on testwiki works both on testwiki and here on enwp (I copied it to my User:Technical 13/monobook.js and ran it here locally). I'll see what I can do about the addOnloadHook and be back in a few moments. — {{U|Technical 13}} ^{(t • e • c)} 12:58, 12 March 2014 (UTC)

Will have to dig into addOnloadHook deeper, no idea why the replacements aren't working. — {{U|Technical 13}} ^{(t • e • c)} 13:21, 12 March 2014 (UTC)

Matma Rex, do you have any idea why this didn't work? Helder.wiki 14:02, 12 March 2014 (UTC)

In the old version of the gadget, the initialization crContURI = '' was happening before crContURI = url, as expected. The problem is that after replacing addOnloadHook by $, these assignments started to happen in the reverse order (jQuery calls prefixContribsInit earlier than addOnloadHook does?), so crContURI ended up being empty instead of containing the appropriated URL. I provided an updated version of the code in the previous section. Helder.wiki 18:46, 12 March 2014 (UTC)

I assume this answers the question :) Matma Rex talk 19:10, 12 March 2014 (UTC)

Yep. Sorry to bother you :-) Helder.wiki 19:16, 12 March 2014 (UTC)

 Done —TheDJ (talk • contribs) 14:51, 29 March 2014 (UTC)

Aaaaand...

...you clowns broke it for external wikis. Thanks gize! (No, seriously, it doesn't work. mw.loader.load( "//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-contribsrange.js&action=raw&ctype=text/javascript" ) gives me Uncaught TypeError: Object [object Object] has no method 'injectSpinner'. Good job team.) 195.154.112.207 (talk) 16:37, 10 April 2014 (UTC)

It needs a mw.loader.using('jquery.spinner', function(){…}) somewhere, it seems. Matma Rex talk 17:38, 10 April 2014 (UTC)

The definition of this gadget already loads the module query.spinner. If you need to load the raw JS code instead of enabling the gadget in the preferences, you need to make that inside of the call to mw.loader.using mentioned by Matma Rex. Or, in case the call is from a gadget, add the same dependencies to its definition. Helder.wiki 19:19, 10 April 2014 (UTC)

I notice this edit request didn't result in an edit, though it doesn't work for me using the current revision; it only works if I tell it to use this revision as I've done here. Here is a contribs page for an ip range with the oldid specified in my common.js, and here it is without that - it doesn't find the edits. Matma Rex/Helder.wiki, are you saying that 195.154.112.107 and I aren't using the right code in our js files, or what? We need to use mw.loader.using instead of whatever? Ok I guess, though I think it's worth pointing out that that old revision seems to work better than the current one. Cathfolant (talk) 19:56, 10 April 2014 (UTC)

Tried using mw.loader.using in my common.js [4] as that's what I got out of what you said, but that just broke the gadget entirely. Cathfolant (talk) 20:01, 10 April 2014 (UTC)

Cathfolant, according to the documentation of mw.loader, the code should be like this:

mw.loader.using( [ 'jquery.spinner', 'mediawiki.util' ], function () {
    // Remove this line once the wiki is upgraded to MW 1.23
    mw.util.getUrl = mw.util.wikiGetlink;
    // Now that the required modules are ready, load the script
    mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-contribsrange.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400');
} );

Notice I added an extra line to define mw.util.getUrl because that wiki is running a version of Mediawiki which is older than the one in use on Wikipedia.

The code above works fine if open the page you tried before and I paste it in the console (tested on Google Chrome). Helder.wiki 23:58, 10 April 2014 (UTC)

year contributions

I did not notice that one was directed here for bugs, but I filed https://bugzilla.wikimedia.org/show_bug.cgi?id=64834 (original reproduced here):

---

The "Javascript-enhanced contributions lookup 0.2" standard takes the year as the current, but that results in all contributions listed from the previous year, not including the current year.

• https://en.wikipedia.org/wiki/Special:Contributions/198.24.31.121/16
  • lists all contributions starting from the last edit in 2013 till the beginning of time
• https://en.wikipedia.org/w/index.php?limit=50&tagfilter=&title=Special%3AContributions&contribs=user&target=198.24.31.121%2F16&namespace=&tagfilter=&year=2015&month=-1
  • lists all contributions from now till the beginning of time

The standard setting for this script should be changed to include the year mentioned in the 'year' box, not until the year mentioned in the 'year' box.

---

Now looking at the code, I think line 49 needs a '+1' (but I am not confident with this language). --Dirk Beetstra ^{T C} 17:37, 4 May 2014 (UTC)

Sorry the slow response. I suggest you ask someone familiar with javascript to look into this for you. — Martin (MSGJ · talk) 09:57, 14 May 2014 (UTC)

Sorry, undoing the 'answered' - that is exactly the type of person that I try to attract attention from. The bug still needs to be resolved. --Dirk Beetstra ^{T C} 11:18, 14 May 2014 (UTC)

@Beetstra: You're probably better off asking at WP:VPT. I'm not aware of any admins who regularly patrol CAT:EP and who can also code in JavaScript. — Mr. Stradivarius ^{♪ talk ♪} 13:28, 14 May 2014 (UTC)

I'm not sure it needs a +1 on 49, depends on exactly what is trying to be accomplished. Right now, line 51 that uses the result of what is in 49 that reads as:

  if(y > 2000 && y < 2100) opt_ts = '&ucstart=' + y + '-' + m + '-01T00:00:00Z';

says if y is inclusively between 2001 and 2099 then store '&ucstart=' + y + '-' + m + '-01T00:00:00Z' in opt_ts. Is that the goal? — {{U|Technical 13}} ^{(t • e • c)} 14:08, 14 May 2014 (UTC)

The goal is to have the system work appropriately. The standard call of Special:Contributions/198.24.31.121/16 says currently 'From year (and earlier): [2014] From month (and earlier): [all]' - while the working actually is 'From before year [2014] ..' (that is, the actual working is 'From year (and earlier): [2013] From month (and earlier): [blank]' when you fill in 2014). It is expected that the standard call counts back from 'now', not from the last edit of 2013.

Looking further, it gets more complex:

• leave year at 2014 and month at 'All' gives all contributions starting from the last in 2013 backwards - so NO contributions in 2014
• leave year at 2014 and month at 'February' gives all contributions starting from the last in February 2014 backwards - now suddenly some contributions in 2014 show up
• move year to 2015 and month at 'All' gives ALL contributions starting from now backwards, that is including 2014.

I am not so sure if the +1 in line #49 is the solution either, the calculation seems more complex.

I don't understand that line that you quote (#51) either, why is 2001-2099 special for that. What is wrong with wanting to know the edits in 2000, 1999, 1971 (the last one is a joke)? --Dirk Beetstra ^{T C} 07:04, 15 May 2014 (UTC)

Please ask at WP:VPT --JustBerry (talk) 16:55, 26 May 2014 (UTC)

Protected edit request on 27 May 2014

Please make these changes to fix the above problem. Jackmcbarn (talk) 03:55, 27 May 2014 (UTC)

Done — Mr. Stradivarius ^{♪ talk ♪} 04:49, 27 May 2014 (UTC)

IPs not working on Wikidata

Hi there, can someone take a look here, please? Wikidata:MediaWiki talk:Gadget-contribsrange.js
If you could get it working correctly, it would be really great. Thanks a lot!
Best regads, --#Reaper (talk) 00:01, 23 June 2014 (UTC)

CIDR /21

Why is /21 not supported? (example) It seems like supported ranges are /16, /24, /27, /28/, 29, /30, /31 and /32. Why not also allow everything in between /16 and /32? huji—TALK 14:55, 10 November 2016 (UTC)

IPv6

Does this gadget work with IPv6 addresses? If not, could it be made to work? Thanks — Martin (MSGJ · talk) 12:32, 26 November 2015 (UTC)

@MSGJ: It does give contributions from IPV6 ranges if you do asterisk searches. For eg. 2601:5C2:100:9A1:* or 2601:5C2:100:* or 2601:5C2:* and the like. - NQ (talk) 01:59, 11 May 2016 (UTC)

Follow-up Q

A search for, say, 2600:100E* works, but the same search for 2600:100e* returns "No changes were found ..." Bug, or intentional? —ATS 🖖 talk 03:53, 9 December 2016 (UTC)

@ATS: I updated the prompt, it is case-sensitive and requires capital letters in IPV6 currently. — xaosflux ^Talk 17:12, 7 September 2017 (UTC)

fix getElementsByClassName

{{Editprotected}} see [5], fix 'toggle all'. ref. --YFdyh000 (talk) 07:07, 9 January 2014 (UTC)

That's not the right fix. It will break on older browsers. We should use jquery. —TheDJ (talk • contribs) 18:13, 14 January 2014 (UTC)

done using jquery —TheDJ (talk • contribs) 18:18, 14 January 2014 (UTC)

oh, thanks for remind, jquery is a good idea. merely it seems only break for IE6-IE8.--YFdyh000 (talk) 05:38, 16 January 2014 (UTC)

Interface-protected edit request on 25 December 2019

In the comment on line 21, please replace "These parameter soverride" with "These parameters override" (i.e. move the "s" to the other side of the space). Thanks, --DannyS712 (talk) 01:36, 25 December 2019 (UTC)

 Done Galobtter (pingó mió) 08:30, 25 December 2019 (UTC)

Still necessary

Is this entire gadget still necessary now that CIDR ranges are supported natively? I note that wildcards are permitted by this gadget. It might be a good idea to remove the functionality in this gadget which is presently unnecessary. --Izno (talk) 19:52, 22 November 2017 (UTC)

@Izno: This gadget groups edits by IP, while the native implementation doesn’t. For me the grouped version is more usable. This is, of course, subjective, but I think it’s enough to justify keeping this feature in the gadget. —Tacsipacsi (talk) 12:15, 12 April 2020 (UTC)

Spinner

Jon (WMF) changed the code so that it only tries to use the jQuery spinner if that’s already loaded. While this fix avoids null dereference, I don’t think it’s a good solution: if we want to show a spinner, we want to show it always, not just when it happens to have been loaded. Therefore I suggest changing

  if (mw.loader.getState('jquery.spinner') === 'ready' ) {
    $(spin).injectSpinner('prefixcontribs-spin');
  }

to

  mw.loader.using('jquery.spinner').then(function () {
    $(spin).injectSpinner('prefixcontribs-spin');
  });

which makes sure that the spinner always appears sooner or later. Thanks in advance, —Tacsipacsi (talk) 11:04, 13 September 2020 (UTC)

If

mw.loader.getState('jquery.spinner') === 'ready'

is not truthy than the next line will always throw a JS error (and was according to our production logs - a lot of errors! :)). Adding a dependency to

mw.loader.using('jquery.spinner')

is definitely the right solution, however you probably want to load it earlier in the script. If you are trying to display a spinner, it doesn't make sense to asynchronously show it - as that seems to defeat the purpose to me :) The spinner may display after the action the spinner is supposed to be displayed for as shown! Wrapping the whole code is one option, but ideally you'd wrap whatever begins the script e.g. the click of the UI button. Also consider not using jquery spinner for something so simple.

$('<img>').attr('src', urlOfCommonsSpinner ).appendTo(spin)

should work just as well without the overhead.Jon (WMF) (talk) 18:19, 13 September 2020 (UTC)

@Jon (WMF): jQuery.spinner is all about showing spinners, isn’t it? What could it do more complicated than showing a spinner? Yes, preloading the module would be even better, but I don’t know this script well enough to propose a good place for this preload. By the way, the image solution is asynchronous as well—the image needs to be loaded to show up. My favorite example is my local public transport company BKK’s timetable page: if you click on a destination, it shows a spinner GIF until the list of stops is loaded, but loading the spinner is a significant fraction of this time, so I often see the “toltes-loading” alt text (“töltés” meaning “loading” in Hungarian) for longer time than the actual spinner. —Tacsipacsi (talk) 23:01, 13 September 2020 (UTC)

Tacsipacsi, Jon (WMF) - Between the two of you, what is the right solution here? ~Oshwah~^{(talk) (contribs)} 05:53, 15 September 2020 (UTC)

@Oshwah and Jon (WMF): There’s no one Right Solution™ here, as we need to carefully balance between responsiveness and avoiding unnecessary network load: the earlier the ResourceLoader module is loaded, the higher the chance of loading it unnecessarily; the later it’s loaded, the higher the chance of the spinner not appearing immediately (or even not appearing at all, because the actual data loads faster than the spinner module).

I just looked into the code more thoroughly, and now I say more confidently that the least bad solution is loading the module right where it’s needed, that is, the solution I originally proposed (or at the beginning of that function, but that eight lines shouldn’t make a big difference). This function is called at from two places in prefixContribsInit, at the beginning of an if statement and at the beginning of its else if statement. The loading cannot be moved further up within these conditional blocks, and moving them outside of the conditional would mean the module is loaded unnecessarily in the vast majority of cases: when neither condition is true, that is, someone tries to load the contributions for a user name that is neither a CIDR range (like 127.0.0.0/24) nor a user name/IP fragment ending in an asterisk (Tacsip* or 127.0.*), for example when one clicks on the contribs link in your signature, page history, RC etc. (In this case, the script remains silent, doesn’t display anything.) —Tacsipacsi (talk) 18:56, 15 September 2020 (UTC)

@Jon (WMF): are you happy with the approach above and if so, can one of you post a link to a sandbox with the code required? — Martin (MSGJ · talk) 08:12, 22 September 2020 (UTC)

@MSGJ: I hope Jon will be happy with my version (diff). I originally implemented the suggested solution, but while testing it for the race condition, I realized that when it occurs (i.e. the API query is faster than loading the spinner ResourceLoader module), the spinner spins forever without a possibility for the average user to remove it (other than reloading the whole page), which is pretty annoying. :/ So I went for a more race condition-safe solution, which stores the load progress in a global (gadget-scope) variable. I also added a lot of function documentation—I hope they will help the next person trying to understand how this script works, and also IDEs like Visual Studio Code to provide better code completion. (Please delete my subpage once the code goes live, I’d like to keep my user space clean.) —Tacsipacsi (talk) 21:44, 24 September 2020 (UTC)

 Deployed — Martin (MSGJ · talk) 21:50, 24 September 2020 (UTC)

Bug regarding this gadget

When I open up Special:Contributions/Jules*, the page immediately starts searching contribs as if I was looking up an IP address with an asterisk at the end. It's pretty disruptive to look at, since there are a LOT of users whose username starts with Jules. Wondering if this could be addressed? bibliomaniac15 01:14, 13 October 2021 (UTC)

The problem is that searching with "username * " is part of the advertised functionality of this tool. I guess you could check if the user exists, and stop the script from running if it does, but then you wouldn't be able to actually search for users with prefixed "Jules" in their username. You can disable the tool in Preferences > Gadgets > Advanced. Dylsss^{(talk contribs)} 19:32, 18 October 2021 (UTC)

Bug non-vector skins

zh:Special:Diff/68628552 (for Timeless skin). --AnYiLin^Talk 13:11, 12 November 2021 (UTC)