MediaWiki talk:Gadget-markblocked.js/Archive 1

Archive 1

Underline links

If u want, you may check the Underline links option. If this option has value = 'never' then blocked users will not have 'line-through' style, in standard way. ru:Special:Diff/83641579. Iniquity (talk) 12:01, 13 February 2017 (UTC) Just use selectors: ru:Special:Diff/83643224. Iniquity (talk) 13:12, 13 February 2017 (UTC)

Sorry, no idea what you are talking about. Can you be more specific? Code in a sandbox? — Martin (MSGJ · talk) 13:46, 13 February 2017 (UTC)

@MSGJ: Wow, sorry, my fault. You are having selectors' rule. Iniquity (talk) 16:42, 13 February 2017 (UTC)

External links

Can we fix the support for external links? I've proven in principle that it can be done. (The only minor problem I see on testing this is that the tooltip, e.g. on Fruit of the land, starts with "undefined". I'm sure that can be fixed in due course.)

Fixing this might resolve the dispute at WT:Notifications#Checkuser and admin questions. Burninthruthesky (talk) 10:46, 12 April 2017 (UTC) Burninthruthesky (talk) 11:42, 12 April 2017 (UTC)

@Burninthruthesky: I've made the requested change. The only downside is that it will make the script slightly slower, but hopefully not enough that it is noticeable. Kaldari (talk) 17:55, 12 April 2017 (UTC)

Many thanks for your prompt response. Burninthruthesky (talk) 20:50, 12 April 2017 (UTC)

Redlinks for noping

I have incorporated some somewhat-overlapping functionality, to fix redlinked user pages even when using {{noping}}. As Vanjagenije suggests at WT:Notifications#Checkuser and admin questions, can we add this to the gadget please? Burninthruthesky (talk) 19:33, 26 April 2017 (UTC); diff updated 08:05, 27 April 2017 (UTC)

@Kaldari: would you mind looking over this? — xaosflux ^Talk 17:24, 13 May 2017 (UTC)

Hmm, I'm a little worried about adding another API request into the script. This will probably double the execution time. Kaldari (talk) 23:04, 13 May 2017 (UTC)

How about enabling it only if a user preference is set? Burninthruthesky (talk) 07:45, 16 May 2017 (UTC)

Request disabled as stale. Please reactivate if you get consensus for this change — Martin (MSGJ · talk) 11:17, 24 May 2017 (UTC)

Color changes

I have placed the markthrough script to the bottom of my common .js page in an attempt to customize the actual strike colors.

mw.util.addCSS('\
	a.user-blocked-temp {'   + ( window.mbTempStyle || 'opacity: 0.7; text-decoration: line-through' ) + '}\
	a.user-blocked-indef {'  + ( window.mbIndefStyle || 'opacity: 0.4; font-style: italic; text-decoration: line-through' ) + '}\
	.user-blocked-tipbox {' + ( window.mbTipBoxStyle || 'font-size:smaller; background:#FFFFF0; border:1px solid #FEA; padding:0 0.3em; color:#FF0000' ) + '}\
	');

I've been adjusting the color values here, but nothing changes, what am I doing wrong ? Thanks for any help. - FlightTime (open channel) 22:38, 29 July 2017 (UTC)

Protected edit request on 11 October 2017

user = user[2];

change to

user = user[2];
if( /[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7}/.test(user) ) user = user.toUpperCase();

A query for the blocks on 2001:8003:407c:ba00:de0:bcb6:8f7a:120d returns the IPv6 in the form of 2001:8003:407C:BA00:DE0:BCB6:8F7A:120D meaning that blk.user later down in the script does not have the same value as the one stored in userLinks. This causes the script to fail when there is a link to an IPv6 with the letter characters lowercase. (An example would be the current version of ANI) (An example would be Special:Contributions/2602:306:cc2b:7000:41d3:b92d:731c:959d). -- The Voidwalker ^Whispers 19:32, 11 October 2017 (UTC)

Done @The Voidwalker: please confirm I have done that correctly — Martin (MSGJ · talk) 06:14, 14 October 2017 (UTC)

The example works correctly; everything appears to be in order. Thanks! -- The Voidwalker ^Whispers 16:42, 14 October 2017 (UTC)

Would be nice to have range blocks marked too

Could it be that range blocks (such as this for 168.99.198.48 (talk · contribs · deleted contribs · logs · filter log · block user · block log) and this for 2001:8003:54C9:8100:982B:CE3D:8B5A:9A64 (talk · contribs · deleted contribs · logs · filter log · block user · block log)) don't get marked as blocked? More examples can be found here. It would be nice to see them marked as such. Cheers - DVdm (talk) 07:04, 26 October 2017 (UTC)

Support.   — Jeff G. ツ 15:09, 13 April 2018 (UTC)

 Not done: I don't see any problem. The first one is correctry shown as blocked. The second IP is not blocked. And the third link is to the history of ANI. In any case, an edit cannot be made unless the exact change is specified. — Martin (MSGJ · talk) 06:39, 16 April 2018 (UTC)

Crosspost to WT:Gadget

Crosspost to my thread about a proposed change to this gadget: Wikipedia_talk:Gadget#Proposed_change_to_Mediawiki:Gadget-markblocked.js. Thanks! Writ Keeper ⚇♔ 19:03, 21 February 2019 (UTC)

Opacity changes

Currently the gadget changes the opacity of the text based on the user's block length. Would it be possible to get a secondary checkbox in the gadget list to disable that function, so that the usernames are only struck out? The opacity changes can make the names hard to read on some screens. Sario528 (talk) 20:28, 25 March 2019 (UTC)

Hey, Sario528. That would be kind of a big footprint for a small feature IMO, but you can fix this yourself if you like (sorry if you already know this!) Just add the line .user-blocked-indef {opacity:1.0 !important;} to your common.css page, and that should overwrite the opacity styling for indefblocked users. Writ Keeper ⚇♔ 13:57, 26 March 2019 (UTC)

Thanks for responding. While I'm already running a custom version of the gadget myself, I made the request for any user that may be having issues with the opacity changes, and is not comfortable working with code. I understand if it's more work then it's worth making the change as requested, but I figured there was no harm in asking. Thanks again for looking into this. Sario528 (talk) 18:52, 26 March 2019 (UTC)

Interface-protected edit request on 1 November 2019

• Current – Line 59: if ( !url || url.charAt(0) != '/' ) {
• Requested – Line 59: if ( !url ) {
• Reason – This change allows the script to work correctly with {{noping}}. See for example sockpuppet investigation pages where currently only the talk page link is struck through.

– Thjarkur (talk) 18:22, 1 November 2019 (UTC)

I implemented this into my own .js page, and the proposed change seems to work as intended and without any issues. I made comparisons on contribution lists, noticeboards, diffs, and page edit histories, and didn't run into any problems. I'm going to go ahead and implement it... ~Oshwah~^{(talk) (contribs)} 09:12, 19 November 2019 (UTC)

Þjarkur -  Done. ~Oshwah~^{(talk) (contribs)} 09:16, 19 November 2019 (UTC)

Anything different for Partial Blocks?

It's weird to see partially-blocked users, who may be blocked from a single page, show up the same as indefinitely site-blocked. Not sure what this should do to show things differently — maybe mark PBs the same as non-indefinite? — but I do feel something should distinguish them. ~ Amory (u • t • c) 16:26, 13 January 2020 (UTC)

I agree. Best, Barkeep49 (talk) 16:27, 13 January 2020 (UTC)

If we throw restrictions into bkprop, we can at least check if there are any partial block restrictions in-play. Looks like it returns an object if there are any restrictions as the result of a partial block, and an empty array if it's a regular block (or if it's one of those dumb empty blocks vis-a-vis phab:T208645). Not familiar with this code but it shouldn't be too hard to just check that then apply a separate appearance? ~ Amory (u • t • c) 16:50, 13 January 2020 (UTC)

Can we just show partially-blocked users normally? There's no advantage to show them struck out - essentially they just have a technical topic ban. – bradv🍁 17:01, 13 January 2020 (UTC)

I've gone and done this, for now anyway. I've made it so the tooltips still show up, though. ~ Amory (u • t • c) 19:46, 13 January 2020 (UTC)

Just to clarify, the tooltip says "Partially blocked." Not the best but concise enough? ~ Amory (u • t • c) 12:10, 14 January 2020 (UTC)

@Amorymeltzer: I think we should have some sort of indication for partial blocking (indefinite or definite), probably a dotted underline or a small bold P next to the username. @Barkeep49 and Bradv: Thoughts? --qedk (t 桜 c) 20:11, 23 January 2020 (UTC)

I would be ok with the dotted underline but am also just fine with tooltip only. Best, Barkeep49 (talk) 21:02, 23 January 2020 (UTC)

Sorry to summon you again here Amorymeltzer, but it seems you're the one who keeps us running with everything related to blocks. ¯\_(ツ)_/¯ --qedk (t 桜 c) 08:19, 3 February 2020 (UTC)

Was hoping for more input besides you and (half of) Barkeep49. I suppose just doing it will be the best way to get folks to have an opinion... Okay, so underlined for partial blocks; italics for indef or have temporary and indef partials the same? ~ Amory (u • t • c) 12:02, 3 February 2020 (UTC)

I say mark all pblocks as dotted underline. The distinction between site-wide and partial is more important, pblock durations are more or less unproblematic. --qedk (t 桜 c) 13:26, 3 February 2020 (UTC)

I think the styles are fine, but detecting partial blocks doesn't work correctly on a wiki without them available - all blocks show as partial. I would appreciate if that could be fixed so that I don't have to fork this. — JJMC89 (T·C) 03:16, 4 February 2020 (UTC)

@JJMC89: I'm heading off, but should be taken care of now? I don't spend much time on non-WMF wikis, but it worked on wookieepedia, so LMK if you still have issues. ~ Amory (u • t • c) 04:45, 4 February 2020 (UTC)

Works for me. Thanks, Amory. — JJMC89 (T·C) 04:56, 4 February 2020 (UTC)

Interface-protected edit request on 10 February 2020

On line 131 change:

clss = partial ? 'user-blocked-partial' : clss='user-blocked-temp';

to

clss = partial ? 'user-blocked-partial' : 'user-blocked-temp'; Prh47bridge (talk) 09:05, 10 February 2020 (UTC)

 Done Ugh, quite right! Sorry about that, fixed! ~ Amory (u • t • c) 16:22, 10 February 2020 (UTC)

Crosswiki regex issues

Tks4Fish asked me to look into why this script wasn't working on ptwiki (imported to global.js from enwiki). Found an interesting answer...apparently one of the valid userspace prefixes on ptwiki is "usuário(a):" and those parens are polluting the regex. See [1] for what this looks like - the actual regex group we're trying to match, normally group 2, is now group 4 because the (a)s are parsed as capture groups. I'll sandbox a patch to escape parens in the namespace prefix list. GeneralNotability (talk) 23:37, 21 December 2020 (UTC)

Okay, tested out a fix. Please change line 33 from:

userNS.push( ns.replace( /_/g, ' ' ) + ':' );

to

userNS.push( mw.util.escapeRegExp(ns.replace( /_/g, ' ' )) + ':' );

(yes, the double-backslash is necessary) Also, probably worth adding a comment explaining this, probably something to the effect of // Escape parentheses in namespace names so they don't pollute the regex

GeneralNotability (talk) 23:52, 21 December 2020 (UTC)

@GeneralNotability could mw.util.escapeRegExp be used instead? DannyS712 (talk) 09:14, 23 December 2020 (UTC)

DannyS712, thanks, I wasn't aware of that function - looks like it should work. Will do a quick test and then update my proposed change above. GeneralNotability (talk) 14:38, 23 December 2020 (UTC)

(Updated). GeneralNotability (talk) 18:46, 23 December 2020 (UTC)

 Done, thanks. Writ Keeper ⚇♔ 19:12, 23 December 2020 (UTC)

Not highlighted?

At press time, there's a username on Special:Diff/955382324 that should be struck but isn't. No list=blocks API request, and no console errors. I'll try a debugger session later if I have the time. Enterprisey (talk!) 22:26, 7 May 2020 (UTC)

Enterprisey, it's pretty straightforward, look at the switch at the bottom: it's intentionally not called in mainspace. The gadget works by parsing every link on the page, so in that case it's a good idea, but what we could do is instead specify that in mainspace it only looks at links with .mw-userlink. ~ Amory (u • t • c) 10:13, 8 May 2020 (UTC)

Enabled on mainspace diff area

I was recently reminded of this deficit, and so have enabled the gadget in mainspace, but only the diff region where user links are defined. Should work but, as always, holla if it don't. ~ Amory (u • t • c) 12:26, 7 November 2020 (UTC)

@Amorymeltzer: This did in fact, break things, though it took me a while to notice. Previously, the function markBlocked had been passed to mw.hook('wikipage.content').add(). But the return value is now being passed instead. This prevents the gadget from working on dynamically created content, when other scripts or gadgets call mw.hook('wikipage.content').fire().

This patch seems to work, for me. There might be a better way to do this. Suffusion of Yellow (talk) 21:25, 21 April 2021 (UTC)

@Ladsgroup and Skizzerz: I see you made a similar change. That way was my first thought, too, but it will cause the script to re-run on the entire page whenever the hook is fired from another script, instead of the specifically requested element. Unless it's called on a mainspace page, in which case it won't work at all. Suffusion of Yellow (talk) 21:15, 5 May 2021 (UTC)

I think I'd suggest something like this, moving the namespace check to the main function and skipping links already with the userlink class to avoid reruns. Nardog (talk) 21:48, 5 May 2021 (UTC)

@Nardog: But what about the first call? container will be $("#mw-content-text"), even in mainspace, so the check will never happen. Suffusion of Yellow (talk) 21:53, 5 May 2021 (UTC)

Ah, you're right, and moving the check to the main function would have executed it even when not action=view anyway. I would still suggest a:not(.userlink) to avoid querying about the same users though. (Ideally it should keep track of all user names in the scope outside the function to avoid all of it.) Nardog (talk) 22:04, 5 May 2021 (UTC)

I believe this is a simpler solution to your patch:

mw.hook( 'wikipage.content' ).add( function ( content ) {
	markBlocked( container || content );
	container = null;
} );

Just abandons container after the first run and passes whatever the event passes just like we used to. Nardog (talk) 22:28, 5 May 2021 (UTC)

@Suffusion of Yellow: This edit was requested as part of an investigation on IRC into an error message appearing in Commons. A user was loading this gadget via their global.js and noticed on Commons that it was causing error spam in conjunction with a recent change to MediaWiki core. With their help, I isolated the error to this gadget, and in particular the line that was modified. If left unedited, it would cause significant error spam to the thousands of enwiki users of this gadget when the train deploys recent MediaWiki core changes to this wiki tomorrow. The patch I proposed fixes the error with minimal edits, and was validated by the user initially reporting the error that the gadget still seemed functional afterwards. It seems our testing was not complete enough to catch this issue, sorry :(. Please note that on the initial call to markBlocked(), container may be undefined. This is the case for things like Special:Log and when viewing history pages. The patch proposed above I believe may not sufficiently address this fact, although I have not tested it at all so I cannot confirm whether or not that is the case. --Skizzerz (talk) 01:15, 6 May 2021 (UTC)

@Skizzerz: If the first argument to markBlocked() is falsy it falls back to mw.util.$content. Nardog (talk) 01:22, 6 May 2021 (UTC)

@Skizzerz: Thanks for the context. If I understand the change correctly, before Thursday mw.hook('wikipage.content').add(undefined) was a NOOP, but now it throws an error? Suffusion of Yellow (talk) 19:06, 7 May 2021 (UTC)

Poor interaction with Reply Tool

As discussed here, the new reply tool in source mode sends frequent wikipage.content events as you type; markblocked.js listens for those and on every event, performs another round of "list: block" API calls and updates the page. I can see the API calls in the Chrome developer window (network tab), and can see the displayed page flash with the DOM update. For a page like Wikipedia:Sockpuppet_investigations/Ineedtostopforgetting/Archive, it's pretty annoying. It's probably also a lot of needless load on the API servers, but I'm less worried about that than the visual flash. -- RoySmith (talk) 13:54, 20 June 2021 (UTC)

Local blocks on Meta marks users as blocked elsewhere

Hello. I think there's a bug here. See e.g., m:Special:CentralAuth/THY869414832 or m:Special:CentralAuth/Paraenti (with this Gadget loaded on your global or common.js on Meta). The script seems to think that local blocks on Meta-Wiki do apply elsewhere too. Not only locally-blocked Meta-Wiki users get their links in CentralAuth struck everywhere, but hovering your mouse over those non-blocked sites outputs the information from the meta.wikimedia block too, as if a local block existed. Thanks, —MarcoAurelio (talk) 11:41, 9 December 2021 (UTC)

I'm not 100% sure what bug you're referring to; what page exactly is this showing an error on? If the Special:CentralAuth page itself is what you mean, then you should switch to using the Gadget version on Meta, rather than importing the enwiki version; I can't replicate this for myself using their gadget, so I assume they handle that. But regardless, I don't think it makes sense to modify the enwiki gadget to address problems on Meta, especially when Meta has a separately-maintained version. Writ Keeper ⚇♔ 14:42, 18 April 2022 (UTC)

Globally locked and blocked users

Tracked in Phabricator
Task T261752

Hi. Can this script be made to show globally locked and blocked users, as well as locally blocked users?   — Jeff G. ツ 15:09, 13 April 2018 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. — Martin (MSGJ · talk) 06:39, 16 April 2018 (UTC)

MSGJ this gadget strikes through the names of locally blocked users, but does nothing if the user is globally locked but not locally blocked.

MediaWiki:Gadget-popups.js detects both and hovering over a name like User:Chyah will show BLOCKED, LOCKED

The ability to strike through the named of locked users (since in practice the effect of blocking and locking is equivalent) should be provided. The javascript required is out of my league I'm afraid. Cabayi (talk) 15:58, 31 December 2018 (UTC)

Me too. Good luck finding someone to help. Feel free to reactivate the request when the code is ready to deploy. — Martin (MSGJ · talk) 08:51, 2 January 2019 (UTC)

Per mw:Extension:CentralAuth/API there unfortunately doesn't appear to be an way to query which of a list of users are locked - only whether an individual user is locked (and doing one query for every user on a page would make the script extremely slow). Galobtter (pingó mió) 08:39, 29 January 2019 (UTC)

Thanks for the research Galobtter. -- Cabayi (talk) 09:38, 29 January 2019 (UTC)

We may also be able to write a Toolforge tool that does the relevant query directly, although I dunno how possible that is. I'll definitely look into it, though. Enterprisey (talk!) 16:39, 29 January 2019 (UTC)

How about placing those users in a category and cross checking against that category? Headbomb {t · c · p · b} 01:46, 23 March 2020 (UTC)

I'd suggest filing a phab request. This seems like an obvious limitation in the api that should be fixed. I see no reason why list=users shouldn't display locked status (Especially now that its semi-in core and not just CentralAuth). For that matter, I see no reason why globaluserinfo shouldn't take more than one user. Bawolff (talk) 10:07, 23 March 2020 (UTC)

It should really be a separate API called list=globalusers, that would be based off of list=users.– BrandonXLF (talk) 23:01, 23 March 2020 (UTC)

Was a phab request filed? If not, I can do so — DaxServer (t · c · m) 14:22, 11 March 2022 (UTC)

@DaxServer see T261752 -- RoySmith (talk) 14:28, 11 March 2022 (UTC)

Thanks @RoySmith. In the time being, I've put a script based on this one User:DaxServer/Mark-locked.js, using LocalStorage to cache users and reduce calls to the API, hopefully I got it right. — DaxServer (t · c · m) 16:15, 11 March 2022 (UTC)

Cool, thanks. -- RoySmith (talk) 16:18, 11 March 2022 (UTC)

User:GeneralNotability/mark-locked.js already exists. It is written in ES6, which is why it is not implemented directly in the gadget yet.​ Izno (talk) 03:23, 14 March 2022 (UTC)

@Izno for those of us not fluent in gadget, what's the issue with ES6? I've been running DaxServer's version for a day or two now; it seems to work fine and it was trivial to install. It would be a shame to have two competing scripts which did the same thing. -- RoySmith (talk) 03:30, 14 March 2022 (UTC)

ResourceLoader, the system that manages delivery of the JavaScript and CSS resources that compose a gadget, currently rejects JavaScript with a version later than ES5. See phab:T75714. Izno (talk) 08:24, 14 March 2022 (UTC)

Thanks for the link, @Izno. Wasn't aware one already existed 😅. Hope to see the ES6 being fixed soon. If the script is ported to ES5, would it be possible to merge it with the gadget? If so, I could work on something as the time permits. If the ES6 fix is on the way in the near future, this port might not be necessary. — DaxServer (t · c · m) 10:49, 14 March 2022 (UTC)

DaxServer That task is "blocked" on there not being a good parser for ES6 available in the language of interest (PHP is what WMF would prefer) such that ES6 scripts can be syntax-validated before delivery, since post delivery if the browser finds one part of the file you receive that contains the JavaScript load, it will invalidate the whole load. It has seen recent activity discussing that aspect and a mitigation for the problem. Basically, the mitigation would cause ES6 scripts to be delivered separately from earlier scripts, so that if the browser's own JavaScript-syntax checking fails to validate any ES6 script, it would only invalidate the set of all the ES6 scripts delivered, rather than all the other ones as well (which are known to be valid server side). Izno (talk) 19:20, 16 March 2022 (UTC)

Oh, my, that's frightening. -- RoySmith (talk) 15:08, 14 March 2022 (UTC)

Considering it was released in 2015... definitely so... --qedk (t 愛 c) 15:36, 14 March 2022 (UTC)

• Wrote a script that does what you guys have been discussing. Check this out. --Dragoniez (talk) 16:58, 25 April 2022 (UTC)

Italics on Cyrillic characters

The Cyrillic т, when italicized, becomes т (see wikitext, exact same character). I recently blocked a user with the homographic profane name Ѕнјтсцпт (italicized: Ѕнјтсцпт). For anyone using markblocked, it won't be obvious at a glance what the username violation is, since they'll parse it as homographic to "Shimcunm" rather than "Shitcunt".

Is this desirable behavior? If not, is there a way to avoid it, like using some kind of fake italics? -- Tamzin^{[cetacean needed]} (she|they|xe) 07:14, 8 August 2022 (UTC)

Sadly, this is a losing game. What a particular glyph looks like when rendered on the screen depends on the font it's being displayed in. For example, in the font I'm currently using, l (Latin Small Letter L) and 1 (Digit One) look identical. Χ (Greek Capital Letter Chi) and X (Latin Capital Letter X) look different, but they look identical in other fonts. Plus, I'm not even sure the concept of italic makes any sense in most non-latin scripts.

It should be pretty easy to write a back-end tool which takes a unicode string and turns it into a list of the codepoint names (i.e. "Cyrillic Small Letter Te") for each character (nicely wrapped up in JSON). Then markblocked (and other things) could have a little javascript shim which called out to that tool and put the result up as a tooltip. -- RoySmith (talk) 14:21, 8 August 2022 (UTC)

Remove caret from regular expression

Hi, this gadget has a slight problem concerning how it works on mobile view. I'll get straight to the conclusion, and a caret needs to be removed from line 34:

var scriptRX =  new RegExp( '^' + mw.config.get( 'wgScript' ) + '\\?title=([^#&]+)' );

var scriptRX =  new RegExp( mw.config.get( 'wgScript' ) + '\\?title=([^#&]+)' );

Userlinks on mobile view don't start with "/w/index.php" because they need to include "m." as in "//en.m.wikipedia.org/w/index.php?title=User:Dragoniez". As a result, blocked users aren't struck out if the script is loaded from mobile devices (for instance, notice that the links for "User:Syed Ali Ibn Ahmed" are struck out on Wikipedia:Administrators' noticeboard/Incidents#Syed Ali Ibn Ahmed on desktop view but they're not on mobile view). Dragoniez (talk) 14:24, 9 September 2022 (UTC)

That's not why they're not struck out on mobile. It's because the script doesn't load on mobile because it's not specified in MediaWiki:Gadgets-definition. Moreover, the proposed change would result in links to external wikis recognized as internal (which can be avoided by excluding links with external class, I guess). Nardog (talk) 16:36, 9 September 2022 (UTC)

@Nardog: Sorry I wasn't clear at all. What brought me here is that there seem to be occasions on which people have to access the mobile version of the wiki from desktop, and in fact I myself have come across some people before who paste userlinks in the form of external links, and the gadget will be able to deal with these cases as well if the change is made (and I personally don't see anything wrong with this gadget per se recognizing external links as internal. I guess you see some problems arising as a result?) Anyway this change isn't absolutely necessary and maybe we should have some discussion for it beforehand. I'll withdraw the edit request, and I guess it'll be just fine if someone brings this up again when they start to think this change would bring them some benefits. Thanks. Dragoniez (talk) 17:33, 9 September 2022 (UTC)

Oh wait, this would strike out blocked users even if the links aren't of enwiki. That's the problem, and I see the proposed change can't handle this matter by itself. It's my fault I didn't notice this. Dragoniez (talk) 17:39, 9 September 2022 (UTC)

Just noting some more info, "internal" userlinks to another project are struck out if the relevant users are locally blocked, because the regex in line 33 isn't capped with a caret. (e.g. m:User:Projects) Dragoniez (talk) 18:25, 9 September 2022 (UTC)

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.wikipedia.org/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)