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.)
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)
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 VoidwalkerWhispers19:32, 11 October 2017 (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)
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.
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)
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)
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)
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)
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)
(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
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)
@Amorymeltzer: This did in fact, break things, though it took me a while to notice. Previously, the functionmarkBlocked 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().
@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)
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:
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: 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)
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Hi. Can this script be made to show globally locked and blocked users, as well as locally blocked users? — JeffG. ツ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.
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)
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)
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)
@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)
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".
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)
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 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
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
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. DatGuyTalkContribs22: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
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
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. — xaosfluxTalk01: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.
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)
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)
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
The case conversion at this line is inconsistent with the case conversion that MediaWiki does. See [2]. 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)
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)
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
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:
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)
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)
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))
