MediaWiki talk:Gadget-markblocked.js/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? &mdash; Martin (MSGJ · talk) 13:46, 13 February 2017 (UTC)
 * Wow, sorry, my fault. You are having selectors' rule. Iniquity (talk) 16:42, 13 February 2017 (UTC)

Redlinks for noping
I have incorporated some somewhat-overlapping functionality, to fix redlinked user pages even when using noping. As suggests at WT:Notifications, can we add this to the gadget please? Burninthruthesky (talk) 19:33, 26 April 2017 (UTC); diff updated 08:05, 27 April 2017 (UTC)
 * 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 &mdash; 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.

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
change to 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)
 * Yes check.svg Done please confirm I have done that correctly &mdash; 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 and this for ) 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)
 * Red information icon with gradient background.svg 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. &mdash; 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. Thanks! Writ Keeper &#9863;&#9812; 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  to your common.css page, and that should overwrite the opacity styling for indefblocked users. Writ Keeper &#9863;&#9812; 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:
 * Requested – Line 59:
 * 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 - ✅.  ~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 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)
 * 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. 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, 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 and (half of) .  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. —&thinsp;JJMC89&thinsp; (T·C) 03:16, 4 February 2020 (UTC)
 * 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. —&thinsp;JJMC89&thinsp; (T·C) 04:56, 4 February 2020 (UTC)

Interface-protected edit request on 10 February 2020
On line 131 change:

to

Prh47bridge (talk) 09:05, 10 February 2020 (UTC)
 * Yes check.svg Done Ugh, quite right! Sorry about that, fixed! ~  Amory  (u • t • c) 16:22, 10 February 2020 (UTC)

Crosswiki regex issues
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 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:
 * to
 * (yes, the double-backslash is necessary) Also, probably worth adding a comment explaining this, probably something to the effect of
 * GeneralNotability (talk) 23:52, 21 December 2020 (UTC)
 * @GeneralNotability could  be used instead? DannyS712 (talk) 09:14, 23 December 2020 (UTC)
 * , 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)
 * ✅, thanks. Writ Keeper &#9863;&#9812; 19:12, 23 December 2020 (UTC)
 * (Updated). GeneralNotability (talk) 18:46, 23 December 2020 (UTC)
 * ✅, thanks. Writ Keeper &#9863;&#9812; 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)
 * , 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)
 * This did in fact, break things, though it took me a while to notice. Previously, the function  had been passed to  . 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.
 * 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)
 * 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  class to avoid reruns. Nardog (talk) 21:48, 5 May 2021 (UTC)
 * But what about the first call?  will be , 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  anyway. I would still suggest   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:  Just abandons   after the first run and passes whatever the event passes just like we used to. Nardog (talk) 22:28, 5 May 2021 (UTC)
 * 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, container may be  . 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)
 * If the first argument to markBlocked is falsy it falls back to mw.util.$content. Nardog (talk) 01:22, 6 May 2021 (UTC)
 * Thanks for the context. If I understand the change correctly, before Thursday  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 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, &mdash;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 &#9863;&#9812; 14:42, 18 April 2022 (UTC)

Globally locked and blocked users
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)
 * Red question icon with gradient background.svg 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. &mdash; Martin (MSGJ · talk) 06:39, 16 April 2018 (UTC)
 * 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. &mdash; 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 . -- 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? &#32; 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. – Brandon XLF  (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 -- 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 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)
 * 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&#124;they&#124;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: 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 Administrators' noticeboard/Incidents 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  class, I guess). Nardog (talk) 16:36, 9 September 2022 (UTC)
 * 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)