MediaWiki talk:Gadget-markblocked.js

Interface-protected edit request on 29 October 2022
I made a gist of a markblocked.js version that supports rangeblocks. You can see the additions here. I know of the performance hit of calling individual IPs, but I still believe it's a worth it change to make. DatGuyTalkContribs 22:14, 29 October 2022 (UTC)
 * Red information icon with gradient background.svg Not done for now: please establish a consensus for this alteration before using the 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 with 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)
 * ✅ 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   just returns the input string when it's not convertible. In case anything happens, I'd appreciate it if you could add some conditions.
 * Thanks! -- Dragoniez (talk) 03:07, 14 February 2023 (UTC)
 * ✅ — 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)
 * 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  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   capitalizes the first letter). This gadget internally creates a JavaScript object (say, userLink) of , 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   is an array but actually   is, meaning that the former is just undefined. So the thing is, all the keys of   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   would be just enough and there isn't quite any need for preparing specific   conditions.) -- Dragoniez (talk) 03:57, 16 February 2023 (UTC)
 * 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)
 * 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)
 * — xaosflux  Talk 12:04, 16 February 2023 (UTC)
 * Thank you, I apologize for the confusion. -- Dragoniez (talk) 12:52, 16 February 2023 (UTC)

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

Starting edit request. Please replace

with

0x Deadbeef →∞ (talk to me) 09:26, 14 December 2023 (UTC)
 * ✅ * Pppery * it has begun... 16:28, 14 December 2023 (UTC)
 * @0xDeadbeef, since we were the ones talking, I'm guessing this change seems to have had the effect of making some other accounts not highlighted, see e.g. at Bikrookanpurgangster and  at Anne Barrington.... :( Izno (talk) 19:00, 14 December 2023 (UTC)
 * I think it's names with multiple spaces. One space is fine but two or more seems to be causing this effect. Izno (talk) 22:23, 14 December 2023 (UTC)
 * Oh oops, changing replace to replaceAll should fix this. 0x Deadbeef →∞ (talk to me) 22:37, 14 December 2023 (UTC)
 * @0xDeadbeef, replaceAll is from ES2021. Izno (talk) 22:51, 14 December 2023 (UTC)
 * Ah, sorry as I am currently on my phone, maybe https://stackoverflow.com/a/1144788 would work? 0x Deadbeef →∞ (talk to me) 22:58, 14 December 2023 (UTC)
 * @0xDeadbeef, it's not critical :), just post a TPER whenever you have a minute on a real computer. Izno (talk) 23:08, 14 December 2023 (UTC)
 * mw.Title already provides a method to output spaces instead of underscores. Try  (restored the semicolon). Nardog (talk) 00:51, 15 December 2023 (UTC)
 * It works! Izno (talk) 04:08, 15 December 2023 (UTC)
 * Um, take out . Nardog (talk) 04:12, 15 December 2023 (UTC)

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


 * Try temporarily disabling all your user scripts (by blanking common.js) and see if the problem goes away. If so, it may be interacting with a user script in a bad way. Also, what browser, skin, and default # of history entries? I was unable to replicate on Chrome, Vector 2010, and 500 history entries using your example page Medical_school history. – Novem Linguae (talk) 08:36, 9 June 2024 (UTC)
 * I already took a number of hours today disabling everything one by one, including extensions and all scripts, and narrowed it down to this one. The problem only occurs when this gadget is turned on. I am using Chrome (latest), with skin Vector 2022. The default # of history entries is 1,000, but there is no problem listing that many usually. Stefen Towers among the rest!   Gab • Gruntwerk 09:18, 9 June 2024 (UTC)
 * https://en.wikipedia.org/w/index.php?title=Medical_school&action=history&limit=1000&useskin=vector-2022
 * Unable to reproduce. I wonder if anyone else will chime in here having the same problem.
 * If you ever have to figure out what script is causing a bug in the future, you can use a technique called "bisecting", where you disable half at one time and see if that fixes it. If so, disable half of that half, etc. until you are down to the offending script. Should be quicker than going one by one.
 * How are your computer specs? Do you have a 64 bit operating system? Do you have like >8 GB RAM? Loading a page with 20 user scripts and 1000 history entries could be a bit computationally expensive. – Novem Linguae (talk) 10:03, 9 June 2024 (UTC)
 * I did some degree of bisecting along the way where it was more straightforward to keep track of what I turned off and on. Also, I have a 2022 Intel-based PC with Windows 11 (64-bit), a 12-core processor and 24 GB RAM. I have no issue with performance outside of this matter. Stefen Towers among the rest!   Gab • Gruntwerk 17:16, 9 June 2024 (UTC)
 * Further, with this gadget turned off, I see the couple-second hit of my other scripts when the history page loads - but that is an expected hit and the browser doesn't freak out. Stefen Towers among the rest!   Gab • Gruntwerk 17:18, 9 June 2024 (UTC)
 * I just did a fresh test to confirm the issue. I did a load of the above history page. Loaded reasonably as expected. I turned this gadget on in Preferences. Did Ctrl-Shift-R on the history page. The browser as before, flips out for 1-2 minutes before settling down. I turned this gadget off in Preferences. Did Ctrl-Shift-R on the history page. Loaded reasonably as expected. It's always possible this gadget has a conflict with something else, but there's no question I have to keep it turned off to keep the problem from surfacing. Stefen Towers among the rest!   Gab • Gruntwerk 17:31, 9 June 2024 (UTC)
 * I don't have anything weird happen on my computer -- I have the same thing enabled and I'm using Firefox on Fedora. jp×g🗯️ 10:55, 10 June 2024 (UTC)
 * Looking at this with fresh eyes - the following measures didn't make the problem go away:
 * Optimized common.js to better control when scripts load.
 * Turned off all my browser extensions.
 * 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)
 * 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)
 * 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)
 * 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)
 * 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🗯️</b> 08:42, 11 June 2024 (UTC)
 * @StefenTower Try disabling the gadget in your preferences and loading it via common.js rather than ResourceLoader: 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: Dragoniez (talk) 05:48, 17 June 2024 (UTC)
 * Thank you for the idea. I tested it, and the problem I'm experiencing is the same as before. Stefen Towers among the rest!   Gab • Gruntwerk 18:47, 17 June 2024 (UTC)
 * Sorry to hear that it didn't work. It now seems that your situation is attributed to the gadget itself, not to how the script is loaded. Dragoniez (talk) 08:08, 18 June 2024 (UTC)
 * @StefenTower I got another clue of the cause of your situation. Enable the gadget, visit Special:Log/block, press F12 on your keyboard, navigate to the console, and see if there's any yellow/red warning. You might have something like . (You might also want to check the console on pages where you experience the buggish bahaviour). Dragoniez (talk) 17:42, 1 July 2024 (UTC)
 * On Special:Log/block, I see:
 * A single warning
 * A single error
 * Hundreds of warnings saying
 * A single error
 * Stefen Towers among the rest!  Gab • Gruntwerk 04:31, 2 July 2024 (UTC)
 * On the history page above I used to report this issue, I'm seeing the same errors/warnings, except the last one. Stefen Towers among the rest!   Gab • Gruntwerk 04:34, 2 July 2024 (UTC)
 * With the gadget turned off, I'm seeing the same errors/warnings, except the last one. Stefen Towers among the rest!   Gab • Gruntwerk 04:36, 2 July 2024 (UTC)
 * Just doing a normal test, I seems like the June 30 fixes fixed the problem I was seeing. No flipping out in the web browser. Stefen Towers among the rest!   Gab • Gruntwerk 04:42, 2 July 2024 (UTC)
 * @StefenTower Glad to hear the issue's been somehow resolved (I really wonder how, though). As for the console messages, none of them suggests that the gadget's doing harm on your browser experience. #1 is nothing (for our purposes), #3 is just a notice from Chrome, #4 is something that we see everywhere on MediaWiki-powered sites. #2 is something you might want to look into, although it presumably has nothing to do with the gadget, as far as I can tell from your reports. There are some clickable elements around the error message, and via them you can actually figure out which script is throwing the error. Anyway, I had suspected that the issue had to do with the gadget failing to load the  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)
 * 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)
 * 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)

Refactoring
@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  with   or something, then search for   in the page and replace every occurrence of it with  ). 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  module isn't used anywhere. Dragoniez (talk) 13:15, 2 July 2024 (UTC)
 * ✅ – Novem Linguae (talk) 16:43, 2 July 2024 (UTC)

Better add  to MediaWiki:Gadgets-definition for performance then. Nardog (talk) 13:22, 2 July 2024 (UTC)
 * ✅ – Novem Linguae (talk) 16:38, 2 July 2024 (UTC)

OK, I poked at this for awhile today and got some refactoring done. This gadget is pretty easy to test by visiting https://en.wikipedia.org/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)


 * is repetitive. Declare  as Andrybak suggested below.
 * That said,  could be simplified to   either after   or before   Nardog (talk) 03:39, 3 July 2024 (UTC)
 * ✅ – Novem Linguae (talk) 04:17, 3 July 2024 (UTC)
 * Come to think of it,  could be   with   at the end and   after that. That way   isn't needed at all (with   in place of  ). Nardog (talk) 04:27, 3 July 2024 (UTC)

I'll post my version once. Forked from yesterday's version (2024-07-02T18:10:38). Details: Still midway but I'll stop updating my version for now. Dragoniez (talk) 05:36, 3 July 2024 (UTC)
 * 1)   (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  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.
 * 1)   (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.
 * 1)   (Special:Diff/1232302154)
 * I think it's better to limit ourselves to ES6 and use  instead of   because it's an ES2016 feature. (+There's a redundant space in  )
 * 1) Aliases for   (Special:Diff/1232302154/1232323879)
 * s are converted to  tags by the wikitext parser, and special page names that occur in them are translated to the canonical special page name in their hrefs:
 * This is why user links like above are marked up without any issues. But, this is not the case for s:
 * 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  class.
 * (TODO) And, although below is complicated and not easy, it'd be better to collect aliases for  from   and separate them from  . Otherwise, users who import this gadget will have to specify a regex string rather than a plain string, e.g.   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   in   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  (can be copied and pasted into the console):
 * 1)   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  is a bit tricky.
 * 1)   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  is a bit tricky.
 * 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  is a bit tricky.


 * can be used as we now require ES2017. Nardog (talk) 05:58, 3 July 2024 (UTC)
 * 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 Compatibility 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)
 * 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)
 * 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)
 * MediaWiki core itself uses Array includes. The ES version from 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)
 * 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)
 * Yes, it is of ES7 - ECMAScript version history. We should write code compatible to what the official Wikimedia guidelines say. — DaxServer (t·m·e·c) 19:30, 6 July 2024 (UTC)
 * 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 – Compatibility 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)
 * 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)
 * ✅ 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)
 * Sorry for the complexities. Try adding  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   on it, meaning that   returns null. I'll decompose #2 into 4 steps:
 * Move up  (stylistic; Special:Diff/1232342761)
 * Separate the hook handler as a function (Special:Diff/1232343621)
 * should be placed inside, which loads the DOM and modules. (Special:Diff/1232343914)
 * Add a  handler for  . (Special:Diff/1232344339)
 * This is an overview of what I wanted to suggest in #2 above. Dragoniez (talk) 08:05, 3 July 2024 (UTC)
 * 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 ). 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)
 * I won't have much time in the coming weeks and will probably not be able to get to this. You may want to use IAER to attract additional interface admins, who can review your code and deploy your changes. Thanks for your work on this. – Novem Linguae (talk) 03:16, 19 July 2024 (UTC)
 * while we're at it, add  perhaps when switching to mw.Api. See mw:API:Etiquette. Nardog (talk) 11:36, 3 July 2024 (UTC)
 * But we are not POSTing? — DaxServer (t·m·e·c) 14:16, 3 July 2024 (UTC)
 * Yes we are. 50 user names would be too long for GET. Nardog (talk) 23:39, 3 July 2024 (UTC)
 * Blimey, I failed to notice the $.post.. lol — DaxServer (t·m·e·c) 08:42, 4 July 2024 (UTC)

Return of the flip-out
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)


 * 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)
 * Retried. Still flipping out. Stefen Towers among the rest!   Gab • Gruntwerk 22:22, 3 July 2024 (UTC)

Timestamps being decorated
With the changes to the timestamps to make them permalink links, (see: 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  because there's no need to call the jQuery function multiple times and this is inefficient.) Dragoniez (talk) 15:08, 29 June 2024 (UTC)
 * With the variable suggestion:
 * —⁠andrybak (talk) 15:22, 29 June 2024 (UTC)
 * Can be simplified to  Nardog (talk) 01:12, 30 June 2024 (UTC)
 * ✅ * Pppery * <sub style="color:#800000">it has begun... 15:14, 30 June 2024 (UTC)
 * I am not now getting a javascript error practically every second.  . House Blaster  (talk · he/they) 15:23, 30 June 2024 (UTC) (fixed typo which very much affected the meaning of my comment at 16:16, 30 June 2024 (UTC))
 * Seems to have been fixed; ignore me... House Blaster  (talk · he/they) 15:27, 30 June 2024 (UTC)
 * Yep, I caught the same error and fixed it at 15:18 (but you must have been seeing some old cache). * Pppery * <sub style="color:#800000">it has begun... 16:12, 30 June 2024 (UTC)
 * I think these fixes addressed the problem I reported above. At least so far. Thank you! Stefen Towers among the rest!   Gab • Gruntwerk 04:43, 2 July 2024 (UTC)