User talk:RoySmith/tag-check.js

Latest comment: 3 years ago by Enterprisey in topic More JS sadness

More JS sadness

edit

@GeneralNotability, Enterprisey, and Writ Keeper: summoning the power of people who actually understand javascript...

I've got a race condition in tag-check.js. Sometimes it fails to annotate anything. Reloading the page usually makes it work. And, in true heisenbug style, adding console logging fixes the problem :-)

I think I've got it down to when it fails, I get a "Uncaught TypeError: Cannot read property 'replace' of undefined", with a not very helpful stack trace. See https://github.com/roysmith/spi-tools/issues/96 for details. I suspect this is caused by some interaction with User:Writ Keeper/Scripts/cuStaleness.js or User:Writ Keeper/Scripts/sockStaleness.js, but that's just a hunch.

Any clue what might be causing this?

I'm currently loading https://tools-static.wmflabs.org/spi-tools-dev/spi/tag-check.js, but I'm pretty sure what's in User:RoySmith/tag-check.js exhibits the same behavior. -- RoySmith (talk) 21:04, 19 August 2020 (UTC)Reply

RoySmith, after a little bit too much debugging, I got it. The jQuery selector in checkTags looks for links with the userlink class. However, the userlink class is not there by default (check for yourself by setting the URL parameter safemode=1 on any SPI page) - it's inserted by the markblocked gadget ("Strike out usernames that have been blocked" in your preferences), and will thus only show up after some delay. Whenever the markblocked gadget hadn't yet inserted the class before tag-check queried for elements with the class, tag-check wouldn't make any more progress. I would recommend removing the ".userlink" all together in the selector (unless it causes issues, but it's working for me at the moment), so the new selector would just be "span.cuEntry a[href*='/User:']". Enterprisey (talk!) 08:09, 25 August 2020 (UTC)Reply
Enterprisey, Ah, awesome, thanks! You're the best. It smelled like some kind of race condition, but I was assuming it was a race with one of the other SPI scripts noted above. I never thought to look at the gadgets.
All these years, I've managed to avoid doing any serious javascript, but now that I'm getting into it, I'm kind of enjoying it. The last time I dabbled in it, "let", "const", and "async function" hadn't come along yet. They make it a much nicer language than what I remember. -- RoySmith (talk) 13:18, 25 August 2020 (UTC)Reply
Enterprisey, Hmmm, there may be more going on than that. I agree that removing the .userlink is the right thing to do, but it doesn't explain the Uncaught TypeError. If the gadget hadn't run yet, the selector with .userlink should just return an empty set, but it shouldn't generate the exception. I'll make the change and publish it, and see what happens. -- RoySmith (talk) 13:42, 25 August 2020 (UTC)Reply
RoySmith, yeah, I was unable to reproduce the exception using just tag-check. Reading the stack trace from the GitHub issue you linked, looks like MediaWiki:Gadget-edittop.js is misbehaving. Perhaps it's conflicting with some other script or gadget you have? Enterprisey (talk!) 15:48, 25 August 2020 (UTC)Reply