MediaWiki talk:Gadget-markblocked.js

Interface-protected edit request on 29 October 2022

I made a gist of a markblocked.js version that supports rangeblocks. You can see the additions here. I know of the performance hit of calling individual IPs, but I still believe it's a worth it change to make. DatGuy^Talk_Contribs 22:14, 29 October 2022 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{Edit interface-protected}} template. Probably where I'm at, since you recognize there's a performance penalty. Feel free to leave a comment at WP:IANB so others can take a look and/or test that adjustment. Izno (talk) 07:57, 10 November 2022 (UTC)

Interface-protected edit request on 12 February 2023

Please replace

user = user[2];

with

user = user[2].slice(0, 1).toUpperCase() + user[2].slice(1);

The first letter of a username can be in lowercase when the name is typed manually, and in those cases user links aren't marked up even if the associated users are blocked. For instance, Special:Contributions/Projects and Special:Contributions/projects should both be struck out but currently only the first is. --Dragoniez (talk) 17:59, 11 February 2023 (UTC)

 Done however I'm not sure if this is going to break things when coming across non-latin character sets - if so this should be reverted. — xaosflux ^Talk 01:26, 14 February 2023 (UTC)

• Thank you xaosflux, I had tested that with Japanese characters before submitting this request, and it appears that String.prototype.toUpperCase just returns the input string when it's not convertible. In case anything happens, I'd appreciate it if you could add some conditions.

var firstLetter = user[2].slice(0, 1);
user = (/[a-z]/i.test(firstLetter) ? firstLetter.toUpperCase() : firstLetter) + user[2].slice(1);

Thanks! --Dragoniez (talk) 03:07, 14 February 2023 (UTC)

@Dragoniez:  Done — xaosflux ^Talk 04:47, 14 February 2023 (UTC)

I'm not sure what the point of this is. If a non-ASCII letter like "ａ" or "ω" comes after Special:Contributions/, MediaWiki automatically converts it to "Ａ" or "Ω", as does String.prototype.toUpperCase. It seems to be doing the exact opposite of what you're trying to do (to avoid conversion where MediaWiki doesn't). Nardog (talk) 05:00, 14 February 2023 (UTC)

@Dragoniez: ICYMI. Nardog (talk) 00:59, 16 February 2023 (UTC)

Sorry I missed your comment. I'm not sure if this is an intended behaviour of mediawiki, but the first letter of a username following Special:Contributions/ is never capitalized automatically even when you directly type it into the browser's address bar. As you say, there might be other cases where the system wants to keep the first letter in lowercase but at least for this gadget, I don't believe we would ever need that because list=blocks always returns usernames with uppercase first letters (e.g. https://en.chped.com/w/api.php?action=query&list=blocks&bkusers=projects&formatversion=2; notice that "projects" is all in lowercase but res.query.blocks[0].user capitalizes the first letter). This gadget internally creates a JavaScript object (say, userLink) of [username: string]: HTMLAnchorElement[], and compares its keys with usernames in API responses, but when the first letter of a username is not capitalized for some reason, the code can't find associated anchors because API responses expect that userLink['User'] is an array but actually userLink['user'] is, meaning that the former is just undefined. So the thing is, all the keys of userLink must have a capitalized first letter for block status queries. (Anyway, I'm, more precisely we are, using the first code above in a derivative script of this gadget on jawp but I've never come across any malfunction due to the absence of the ternary operator in it. I just wanted to say "try this instead if you come across any problem" by "in case anything happens", but I believe that incorporating toUpperCase() would be just enough and there isn't quite any need for preparing specific if conditions.) --Dragoniez (talk) 03:57, 16 February 2023 (UTC)

@Dragoniez: As you say, there might be other cases where the system wants to keep the first letter in lowercase That's not what I'm saying. It appears you're capitalizing the first character only if it's an ASCII Latin letter, but as pages like Special:Contributions/ａ and Special:Contributions/ω show, it's not just ASCII Latin letters that MediaWiki automatically capitalizes at the beginning of a username. So your second edit request is unnecessary and counterproductive AFAICS. Nardog (talk) 04:19, 16 February 2023 (UTC)

Alright. As I said above, I didn't intend the second code as an edit request but just as a possible countermeasure for when what Xaosflux worries about happens. Please revert Special:diff/1139253824. --Dragoniez (talk) 04:35, 16 February 2023 (UTC)

 Undone — xaosflux ^Talk 12:04, 16 February 2023 (UTC)

@Xaosflux: Thank you, I apologize for the confusion. --Dragoniez (talk) 12:52, 16 February 2023 (UTC)

Line 62

The case conversion at this line is inconsistent with the case conversion that MediaWiki does. See [1]. This should use something like new mw.Title(user).getMain() instead. A manifestation of this issue can be found at Wikipedia:Sockpuppet investigations/あすぺるがあすぺしゃりすと, where some accounts are not marked as blocked, but they are actually blocked. 0xDeadbeef→∞ (talk to me) 03:42, 10 December 2023 (UTC)

Starting edit request. Please replace

user = user[2].slice(0, 1).toUpperCase() + user[2].slice(1);

with

user = new mw.Title(user[2]).getMain().replace('_', ' ')

0xDeadbeef→∞ (talk to me) 09:26, 14 December 2023 (UTC)

 Done * Pppery * _{it has begun...} 16:28, 14 December 2023 (UTC)

@0xDeadbeef, since we were the ones talking, I'm guessing this change seems to have had the effect of making some other accounts not highlighted, see e.g. Jay Shree Ram Ji at Bikrookanpurgangster and Steph at Unipet at Anne Barrington.... :( Izno (talk) 19:00, 14 December 2023 (UTC)

I think it's names with multiple spaces. One space is fine but two or more seems to be causing this effect. Izno (talk) 22:23, 14 December 2023 (UTC)

Oh oops, changing replace to replaceAll should fix this. 0xDeadbeef→∞ (talk to me) 22:37, 14 December 2023 (UTC)

@0xDeadbeef, replaceAll is from ES2021. Izno (talk) 22:51, 14 December 2023 (UTC)

Ah, sorry as I am currently on my phone, maybe https://stackoverflow.com/a/1144788 would work? 0xDeadbeef→∞ (talk to me) 22:58, 14 December 2023 (UTC)

@0xDeadbeef, it's not critical :), just post a TPER whenever you have a minute on a real computer. Izno (talk) 23:08, 14 December 2023 (UTC)

mw.Title already provides a method to output spaces instead of underscores. Try user = mw.Title.newFromText( user[2] ).getMainText(); (restored the semicolon). Nardog (talk) 00:51, 15 December 2023 (UTC)

It works! Izno (talk) 04:08, 15 December 2023 (UTC)

Um, take out new . Nardog (talk) 04:12, 15 December 2023 (UTC)

Gadget making my browser flip out when loading page history

If this is the code behind "Strike out usernames that have been blocked", when I have it enabled, a page history like this loads in a very unstable manner, sometimes making my browser flip around and sometimes minimize, almost like it has temporarily crashed. I have been using the gadget for a long time, but it has seemed like I've been having problems with this for months. I wish I could pinpoint when the issue started happening. For now, I'm keeping it disabled although I found it quite useful when dealing with vandalism and such. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:21, 9 June 2024 (UTC)

Try temporarily disabling all your user scripts (by blanking common.js) and see if the problem goes away. If so, it may be interacting with a user script in a bad way. Also, what browser, skin, and default # of history entries? I was unable to replicate on Chrome, Vector 2010, and 500 history entries using your example page Medical_school history. –Novem Linguae (talk) 08:36, 9 June 2024 (UTC)

I already took a number of hours today disabling everything one by one, including extensions and all scripts, and narrowed it down to this one. The problem only occurs when this gadget is turned on. I am using Chrome (latest), with skin Vector 2022. The default # of history entries is 1,000, but there is no problem listing that many usually. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 09:18, 9 June 2024 (UTC)

https://en.chped.com/w/index.php?title=Medical_school&action=history&limit=1000&useskin=vector-2022

Unable to reproduce. I wonder if anyone else will chime in here having the same problem.

If you ever have to figure out what script is causing a bug in the future, you can use a technique called "bisecting", where you disable half at one time and see if that fixes it. If so, disable half of that half, etc. until you are down to the offending script. Should be quicker than going one by one.

How are your computer specs? Do you have a 64 bit operating system? Do you have like >8 GB RAM? Loading a page with 20 user scripts and 1000 history entries could be a bit computationally expensive. –Novem Linguae (talk) 10:03, 9 June 2024 (UTC)

I did some degree of bisecting along the way where it was more straightforward to keep track of what I turned off and on. Also, I have a 2022 Intel-based PC with Windows 11 (64-bit), a 12-core processor and 24 GB RAM. I have no issue with performance outside of this matter. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:16, 9 June 2024 (UTC)

Further, with this gadget turned off, I see the couple-second hit of my other scripts when the history page loads - but that is an expected hit and the browser doesn't freak out. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:18, 9 June 2024 (UTC)

I just did a fresh test to confirm the issue. I did a load of the above history page. Loaded reasonably as expected. I turned this gadget on in Preferences. Did Ctrl-Shift-R on the history page. The browser as before, flips out for 1-2 minutes before settling down. I turned this gadget off in Preferences. Did Ctrl-Shift-R on the history page. Loaded reasonably as expected. It's always possible this gadget has a conflict with something else, but there's no question I have to keep it turned off to keep the problem from surfacing. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:31, 9 June 2024 (UTC)

I don't have anything weird happen on my computer -- I have the same thing enabled and I'm using Firefox on Fedora. jp×g🗯️ 10:55, 10 June 2024 (UTC)

Looking at this with fresh eyes - the following measures didn't make the problem go away:

1. Optimized common.js to better control when scripts load.
2. Turned off all my browser extensions.
3. Commented out all scripts in common.js and vector-2022.js

So what's left is apparently this gadget has a conflict with another gadget, beta or otherwise preference setting. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:40, 10 June 2024 (UTC)

I have just ruled out conflicts with other gadgets and betas as far as ones I'm using. So I'm left with a preference setting somewhere potentially in conflict. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:30, 10 June 2024 (UTC)

It also doesn't seem to have any conflicts with Appearance preference settings. I also checked against selected other settings but nothing so far has turned up. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 03:20, 11 June 2024 (UTC)

If anyone has any ideas for something I can check, please let know. I'm going to give up on this for now, as I need to move on to other things. But for the time-being, I am not going to keep the gadget enabled in my setup, as the trippy page loads are just getting on my nerves. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 03:35, 11 June 2024 (UTC)

@StefenTower: Sorry to have been useless here, but know that you have my sympathy with whatever ends up being the problem with this bizarre inexplicable bug -- many such cases, I'm afraid. jp×g🗯️ 08:42, 11 June 2024 (UTC)

@StefenTower Try disabling the gadget in your preferences and loading it via common.js rather than ResourceLoader:

mw.loader.load("//en.chped.com/w/index.php?title=MediaWiki:Gadget-markblocked.js&action=raw&ctype=text/javascript");

I once came across a gadget that didn't work properly for certain users, and the approach above somehow circumvented the issue. Although the exact mechanism remained unclear, this suggested that ResourceLoader could do some harm depending on your computer/browser environments. Note that if this approach works for you, we expect that the approach below won't work:

mw.loader.load("//en.chped.com/w/load.php?modules=ext.gadget.markblocked");

Dragoniez (talk) 05:48, 17 June 2024 (UTC)

Thank you for the idea. I tested it, and the problem I'm experiencing is the same as before. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 18:47, 17 June 2024 (UTC)

Sorry to hear that it didn't work. It now seems that your situation is attributed to the gadget itself, not to how the script is loaded. Dragoniez (talk) 08:08, 18 June 2024 (UTC)

@StefenTower I got another clue of the cause of your situation. Enable the gadget, visit Special:Log/block, press F12 on your keyboard, navigate to the console, and see if there's any yellow/red warning. You might have something like Uncaught TypeError: Cannot read properties of undefined (reading 'newFromText'). (You might also want to check the console on pages where you experience the buggish bahaviour). Dragoniez (talk) 17:42, 1 July 2024 (UTC)

On Special:Log/block, I see:

• A single warning This page is using the deprecated ResourceLoader module "jquery.ui". Please use Codex instead.
• A single error Uncaught TypeError: Cannot read properties of undefined (reading '0')
• Hundreds of warnings saying Third-party cookie will be blocked in future Chrome versions as part of Privacy Sandbox.
• A single error Uncaught (in promise) Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received

Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:31, 2 July 2024 (UTC)

On the history page above I used to report this issue, I'm seeing the same errors/warnings, except the last one. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:34, 2 July 2024 (UTC)

With the gadget turned off, I'm seeing the same errors/warnings, except the last one. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:36, 2 July 2024 (UTC)

Just doing a normal test, I seems like the June 30 fixes fixed the problem I was seeing. No flipping out in the web browser. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:42, 2 July 2024 (UTC)

@StefenTower Glad to hear the issue's been somehow resolved (I really wonder how, though).
As for the console messages, none of them suggests that the gadget's doing harm on your browser experience. #1 is nothing (for our purposes), #3 is just a notice from Chrome, #4 is something that we see everywhere on MediaWiki-powered sites. #2 is something you might want to look into, although it presumably has nothing to do with the gadget, as far as I can tell from your reports. There are some clickable elements around the error message, and via them you can actually figure out which script is throwing the error.
Anyway, I had suspected that the issue had to do with the gadget failing to load the mediawiki.Title module properly (along with a bunch of other things that can be improved in the coding). I think I'll propose an overhaul when I have time. Dragoniez (talk) 07:49, 2 July 2024 (UTC)

Timestamps being decorated

With the changes to the timestamps to make them permalink links, (see: meta:Tech/News/2024/26), all timestamps on user talk pages are being decorated when visiting blocked users' talk pages. The timestamps should not be decorated. – robertsky (talk) 02:19, 28 June 2024 (UTC)

• I remember I fixed this for MarkBLockedGlobal on ja:Special:Diff/99120922. Please make the following change:

  if ( $( link ).hasClass( 'mw-changeslist-date' ) || $( link ).hasClass( 'ext-discussiontools-init-timestamplink' ) || $( link ).parent( 'span' ).hasClass( 'mw-history-undo' ) || $( link ).parent( 'span' ).hasClass( 'mw-rollback-link' ) ) {
  	return;
  }
  

  This will do the job. (Note: It's better to have a variable for $( link ) because there's no need to call the jQuery function multiple times and this is inefficient.) Dragoniez (talk) 15:08, 29 June 2024 (UTC)

With the variable suggestion:

	$contentLinks.each( ( i, link ) => {
		const $link = $( link );
		if ( $link.hasClass( 'mw-changeslist-date' ) || $link.hasClass( 'ext-discussiontools-init-timestamplink' ) || $link.parent( 'span' ).hasClass( 'mw-history-undo' ) || $link.parent( 'span' ).hasClass( 'mw-rollback-link' ) ) {
			return;
		}
		url = $link.attr( 'href' );
		if ( !url ) {
			return;
		}
		const articleMatch = articleRegex.exec( url ),
			scriptMatch = scriptRegex.exec( url );
		if ( articleMatch ) {
			pageTitle = articleMatch[ 1 ];
		} else if ( scriptMatch ) {
			pageTitle = scriptMatch[ 1 ];
		} else {
			return;
		}
		pageTitle = decodeURIComponent( pageTitle ).replace( /_/g, ' ' );
		user = userTitleRegex.exec( pageTitle );
		if ( !user ) {
			return;
		}
		const userTitle = mw.Title.newFromText( user[ 2 ] );
		if ( !userTitle ) {
			return;
		}
		user = userTitle.getMainText();
		if ( ipv6Regex.test( user ) ) {
			user = user.toUpperCase();
		}
		$link.addClass( 'userlink' );
		if ( !userLinks[ user ] ) {
			userLinks[ user ] = [];
		}
		userLinks[ user ].push( link );
	} );

—⁠andrybak (talk) 15:22, 29 June 2024 (UTC)

Can be simplified to if ( $link.is( '.mw-changeslist-date, .ext-discussiontools-init-timestamplink, .mw-history-undo > a, .mw-rollback-link > a' ) ) { Nardog (talk) 01:12, 30 June 2024 (UTC)

 Done * Pppery * _{it has begun...} 15:14, 30 June 2024 (UTC)

I am not now getting a javascript error practically every second. line 10 > eval at line 2: Uncaught ReferenceError: $link is not defined. HouseBlaster (talk · he/they) 15:23, 30 June 2024 (UTC) (fixed typo which very much affected the meaning of my comment at 16:16, 30 June 2024 (UTC))

Seems to have been fixed; ignore me... HouseBlaster (talk · he/they) 15:27, 30 June 2024 (UTC)

Yep, I caught the same error and fixed it at 15:18 (but you must have been seeing some old cache). * Pppery * _{it has begun...} 16:12, 30 June 2024 (UTC)

I think these fixes addressed the problem I reported above. At least so far. Thank you! Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:43, 2 July 2024 (UTC)