Jump to content

MediaWiki talk:Common.js/Archive 23

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 20Archive 21Archive 22Archive 23

autocollapse

@TheDJ, I just wonder what I'm missing - wouldn't something along the lines of 

if ( $('.mw-collapsible').length > 1 ) { $('.autocollapse').addClass('mw-collapsed') }

be simpler? (if this is a stupid question I apologize in advance, I may well be overlooking something here) — Alexis Jazz (talk or ping me) 01:19, 5 September 2023 (UTC)

Not 100% sure, im on mobile for a while. There are many things going on with collapsible. This is the post init phase, so module state has already been initialized. While the css might work, possibly the internal state would go out of sync ? —TheDJ (talk • contribs) 06:07, 5 September 2023 (UTC)
TheDJ, I think you're right. What about: 
if ( $('.mw-collapsible').length > 1 ) {
	els=$('.autocollapse:not(.mw-collapsed) button.mw-collapsible-toggle');
	for (var int = 0;int<els.length;int++) {
		els[int].click();
	}
}
? — Alexis Jazz (talk or ping me) 06:48, 5 September 2023 (UTC)
Collapsible elements can be nested, and this snippet would also click on nested collapsible elements' toggles, even if those elements weren't marked with autocollapse. You have to use .data( 'mw-collapsible' ).collapse() on the mw-collapsible element (not the toggle) to avoid that problem, like this script does currently. Matma Rex talk 23:48, 5 September 2023 (UTC)
Matma Rex, but the code here seems to do more than that, though I'm still figuring out what. Part is support for the deprecated "collapsed" class (couldn't a bot do a global replacement for that?) and part is innercollapse/outercollapse. I'm not sure innercollapse/outercollapse are widely used, an insource: search returns 149 and 175 results respectively (with overlap) and several of those results are sandboxes. But the results also include {{navbox}} and {{table}}, so it may be widely used through those templates. Oh well. And I'm not sure why it's changing CSS color.
This seems slightly simpler and more compact than the current code section:
if ( $('.mw-collapsible').length > 1 ) {
	els=$('.autocollapse:not(.mw-collapsed)');
    for (var int = 0;int<els.length;int++) {
		$(els[int]).data( 'mw-collapsible' ).collapse();
	}
}
I'm not interested in dying on this hill though but let me know if I can help somehow. — Alexis Jazz (talk or ping me) 02:39, 6 September 2023 (UTC)
Inner/outer is used by WPBS and/or (some specific?) WikiProject banner, with a few dozen uses in main space. Nixing inner/outer would definitely be nice, but someone has to spend time deleting/migrating uses to alternatives, or making some argument or another for removal in those places.
Autocollapse is most used by navbox and sidebar, but it also hits a few amboxes. I know The DJ has suggested previously to both restrict to and automate in the handful of classes where it really makes sense (e.g. navboxes indeed).
As for color changing, that's primarily for navboxes to ensure that the hide/show text will show up against colorful headings. (C.f. any sports navbox.)
As for support for collapsible class, that really is just someone standing up a bot and working through all the uses. One of the reasons I haven't contemplated it yet is that in the main space there is MOS:COLLAPSE, so whether those uses should even exist is a question I wanted to answer first and then simply remove the uses instead if some RFC agrees to the removal. But that's a high energy 30 days for what is currently only 2 lines or so in Common.js, and I'm not in the mood to spend social capital defending that bot.
Any which way, I think there are better wins elsewhere than this specific region of our JS load, unless you want to spend some significant time on sundry tasks. (See also my obligatory advertising of MediaWiki talk:Common.css/to do particularly the infobox migration, as well as phab:T340705.) Izno (talk) 04:10, 6 September 2023 (UTC)
Yeah in the past I’ve considered limiting auto collapse to navboxes indeed. But I haven’t analyzed it enough to be sure of the fallout (aka how many ppl might complain). “ there are better wins elsewhere” I think thats also a good point, there’s lots to win, but there are likely easier wins up for grabs ;) —TheDJ (talk • contribs) 07:30, 6 September 2023 (UTC)
Actually, the color changing could be replaced by Module:Navbox recognizing whether |titlestyle= contains color (this already happens in isIllegible()) and adding a class, which TemplateStyles uses to add the color:inherit rules, couldn’t it? (Assuming that it isn’t used outside of navboxes.) —Tacsipacsi (talk) 21:10, 6 September 2023 (UTC)
Navbox isn't the only place that uses collapsible anything, just the most common that I can point to that also has colors. Most templates these days that also collapse can have colors set on them. Izno (talk) 23:44, 6 September 2023 (UTC)
Then maybe those other templates should also implement the TemplateStyles-based solution. The current code makes an assumption that doesn’t necessarily hold in templates other than navboxes: it assumes that the font color is specified on the parent element of the [hide] button (the <th>/<td> of collapsible tables, or the <div> having the mw-collapsible class in case of collapsible <div>s). However, the color can be specified on any ancestor element; in case of <div>s, even on a descendant element that contains he [hide] button visually but not at the DOM level. Where the font color of a given collapsible template can be specified is specific to that template and thus better handled in template code. —Tacsipacsi (talk) 08:24, 7 September 2023 (UTC)

Quick question

What does this contain? Is this the UI for the website? Or the syncing code? Or the search script? What is this username? (talk) 12:37, 27 December 2023 (UTC)

This is additional client-side javascript that is delivered and set to execute for all desktop users. It is specific to the English Wikipedia. — xaosflux Talk 18:55, 27 December 2023 (UTC)

Class-triggered gadgets

Main page: WP:On-demand gadgets

I propose adding the following to MediaWiki:Common.js and MediaWiki:Mobile.js: 

mw.hook('wikipage.content').add(function ($content) {
    $content.find('.load-gadget').each(function (_, e) {
        mw.loader.load('ext.gadget.ondemand-' + e.dataset.gadget)
    });
});

Sample usage (within a template, which can then be used on pages): 

<div class=load-gadget data-gadget=xyz>
</div>

Presence of such an html element triggers the gadget with name ondemand-xyz to load.

Past discussion is at Wikipedia:Interface_administrators'_noticeboard/Archive_1#Chess_viewer where @Xaosflux suggested using a central loader for content-enhancing gadgets. @User:isaacl also provided an implementation (the final comment on the page) but I'm proposing a smaller, more minimalist implementation that

  • only allows gadgets, because loading other pages in MediaWiki namespace with action=raw is not performant (no minimisation or caching).
  • avoids hooking wikipage.content because that is only useful if some other JS is adding a class to trigger a gadget load, an unlikely use-case.

Courtesy pings to others from the discussion: @User:Wugapodes, @Anomie, @קיפודנחש, @Galobtter, @Izno, @Writ Keeper. – SD0001 (talk) 12:43, 26 December 2023 (UTC)

avoids hooking wikipage.content because that is only useful if some other JS is adding a class to trigger a gadget load, an unlikely use-case It's used more than you think. Features such as mw:Extension:RevisionSlider, mw:Manual:Live preview, and mw:Extension:DiscussionTools use it. Even the "Convenient Discussions" script you use makes use of it. Anomie⚔ 13:14, 26 December 2023 (UTC)
Also, I note the implementation you refer to requires all "on demand" gadgets be named with an "ondemand-" prefix, which may be a useful property to preserve. Anomie⚔ 13:18, 26 December 2023 (UTC)
Right, I missed thinking about those uses of wikipage.content. Requiring an ondemand prefix seems reasonable as well. Amended the edit request. – SD0001 (talk) 13:42, 26 December 2023 (UTC)
 Not done this certainly needs wider discussion first. — xaosflux Talk 16:20, 26 December 2023 (UTC)
And echoing prior concerns already - this has to be run on every single load of every single page, where it will almost never be needed. Using an extension instead of a gadget is preferable for things like the last use-case (some interactive chess game). — xaosflux Talk 16:23, 26 December 2023 (UTC)
The point is that there would be only one check for N different gadgets. There are already some checks in Common.js for loading WikiMiniAtlas (lines 57-71) that could use this system instead. Some updates would be needed in Module:Coordinates and Module:Attached KML but once done, we could delete that block in favour of this one. So on the whole, there's no added JS cost. Would you be in favour of implementing this if it takes care of WikiMiniAtlas?
Converting any feature to an extension is always preferable, but it's not easy for volunteers to get them deployed on Wikimedia production as it requires some level of WMF support or sponsorship. I believe work is being done on the ChessBrowser extension for more than 4 years. It's not surprising it hasn't yielded a result yet. – SD0001 (talk) 19:13, 26 December 2023 (UTC)
I'm not a "hard no" on this, just that it needs to be very carefully considered. — xaosflux Talk 23:30, 26 December 2023 (UTC)
Refarding the extension idea, I just came across phab:T241524 asking for a generic solution which has been open since 2019. Anomie⚔ 02:20, 27 December 2023 (UTC)
I agree this change seems reasonable to implement. * Pppery * it has begun... 22:15, 26 December 2023 (UTC)
Provided this is to be implemented, couldn't the code be a little more efficient? $content can be rather large, and it has no use in the special namespace or on page history. How about putting it in if (mw.config.get('wgNamespaceNumber') >= 0 && mw.config.get('wgAction') !== 'history') { ... }? Nardog (talk) 04:31, 27 December 2023 (UTC)
Special:ExpandTemplates for one has valid use for it. Perhaps we shouldn't try to over-optimize. Anomie⚔ 04:37, 27 December 2023 (UTC)
Then how about using wikipage.categories instead? E.g. 
mw.hook('wikipage.categories').add(function ($content) {
    $content.find('a[href^="/wiki/Category:Pages_using_on-demand_gadget_"]').each(function () {
        mw.loader.load('ext.gadget.ondemand-' + this.getAttribute('href').slice(44));
    });
});
Nardog (talk) 03:16, 30 December 2023 (UTC)
What would the advantage of that be, versus the potential disadvantage that that hook might not be fired in all places where a content (pre)view is rendered? Anomie⚔ 03:28, 30 December 2023 (UTC)
That it won't run on a large tree, e.g. recent changes with thousands of entries. Where does it not fire where a content (pre)view is rendered? Nardog (talk) 03:32, 30 December 2023 (UTC)
I see no firing of that hook in the code for DiscussionTools or RevisionSlider, for example. Anomie⚔ 04:09, 30 December 2023 (UTC)
Modern versions of jQuery just use native methods under the hood – querySelectorAll or getElementsByClassName. A single class as a selector is a very common use-case, so browsers would optimise for that. On the other hand, a complex selector like a[href^= is probably not optimised. – SD0001 (talk) 17:21, 2 January 2024 (UTC)
I have setup a documentation page for this feature: WP:On-demand gadgets. Also, Module:Coordinates and Module:Attached KML have been edited to support loading WikiMiniAtlas through this method (as a gadget, MediaWiki:Gadget-ondemand-WikiMiniAtlas.js), so that we can get rid of the special case loading code for it from Common.js. – SD0001 (talk) 17:21, 2 January 2024 (UTC)
I think the proposed implementation is good. It's similar to how we load the code for collapsible elements and sortable tables in MediaWiki ([1]). I would add a check that the requested gadget actually exists before calling mw.loader.load, to avoid warnings or errors occurring due to creative vandalism on pages.
On a general note, these gadgets themselves will have to be resilient against page vandalism. For example, being careful with how it handles content found on the page to avoid DOM-based XSS vulnerabilities, but also making sure that they can't be instructed to do something that disrupts editing, like covering the whole page with some interactive element. Matma Rex talk 17:38, 4 January 2024 (UTC)
I'd support this. I don't this needs any premature optimization. Especially if this replaces the wikiminiatlas load it will be very useful. I think the check for the gadget existing would be good per Matma Rex. Galobtter (talk) 01:54, 5 January 2024 (UTC)
@Galobtter @Matma Rex Not sure if the check is necessary. No http request gets raised for a non-existent gadget, only a console warning (no console error) – which could be useful in understanding why something doesn't load, detecting vandalism, etc. – SD0001 (talk) 08:03, 13 January 2024 (UTC)
Yeah that seems fine I guess. Probably all use cases should be templates so we can easily audit non-template uses of this in mainspace. Galobtter (talk) 01:51, 16 January 2024 (UTC)
information Note: In principle, this seems to be basically the same as mw:TemplateScripts, with a slightly different implementation. Would be nice to merge these two efforts instead of setting up "competing" systems. Jon Harald Søby (talk) 16:37, 10 January 2024 (UTC)
I think using the gadget system rather than raw JS pages is probably better as gadgets get minification and such. Using mw.hook() as is proposed here will work better with various kinds of dynamic content generation. Anomie⚔ 16:50, 10 January 2024 (UTC)
Yup, and phab:T8883 was refused, and phab:T241524 is lingering. Developers seem to hate the idea of doing this? — xaosflux Talk 15:25, 15 January 2024 (UTC)
I see mixed opinions there from different devs? (Tgr seems supportive.) Galobtter (talk) 01:51, 16 January 2024 (UTC)
There is support among MW devs for this. T241524 is only lingering because one developer doesn't think this is a good idea, for non-techincal reasons - such as that they don't think intadmins qualified to check that gadgets loaded this way have no-JS fallbacks, don't cause gaps in content when viewed by a search crawler or while printing, etc. That might be a reasonable point for mediawikis in general, but enwiki has lots of technical editors who can write code that conform to standards. Adding the feature to MW itself is a bigger deal - one of the ways get there is to first showcase that the feature can be used responsibly.
But if we don't implement this locally because MW isn't implementing it, we're stuck in a cycle where there's no progress at either level. – SD0001 (talk) 16:37, 25 January 2024 (UTC)
I have the proposed code at User:SD0001/MediaWiki:Common.js, if someone can give this a second look to ensure WikiMiniAtlas loads won't be impacted. One difference is that WikiMiniAtlas would now load on mobile domain as well (when MediaWiki:Mobile.js is edited to the same effect). The gadget seems to work fine on mobile, so I see no harm but if we don't want it on mobile, MediaWiki:Gadget-ondemand-WikiMiniAtlas.js can be modified accordingly. – SD0001 (talk) 12:10, 15 January 2024 (UTC)
I support this and appreciate SD0001 for working on it. I'm personally fine doing this without consensus on VPT but I don't think that's a unanimous view, so we might as well take it there first. Enterprisey (talk!) 00:53, 16 January 2024 (UTC)
Posted notifications at VPT and WT:Gadget. – SD0001 (talk) 16:40, 25 January 2024 (UTC)
Weakly against this, but only weakly. The risk is low, since they'd be gadgets, but I sincerely don't like the idea of a third party (another user) dictating what sort of JS is run for a user. I would think that means the level of scrutiny for each "ondemand" gadget has to be even higher, since they're not necessarily something a user—or reader!—has opted in to. The third party could theoretically swap out which ondemand is loaded or add one to an unrelated page, so the interaction between these becomes even more important. It also makes anything that pulls from an external wiki—where we don't get to audit changes as readily—more of a risk for an end-user. ~ Amory (u • t • c) 13:40, 30 January 2024 (UTC)
The alternatives aren't much better. Would you rather have the whole script in MediaWiki:Common.js? Or custom loaders for each one, like WikiMiniAtlas has? Or would you rather have the same in a default-enabled gadget?
I agree with you that the level of scrutiny for any ondemand gadget should be as high as for code in MediaWiki:Common.js or in default-enabled gadgets, with the difference being that arguments about cluttering Common.js or the gadget list wouldn't apply. The fact that the corresponding ondemand gadgets would be clearly indicated by having titles beginning "Gadget-ondemand-" should make is straightforward enough for intadmins to know when the extra scrutiny is needed. Anomie⚔ 14:14, 30 January 2024 (UTC)
I don't dispute or disagree with any of that. We'll obviously ensure the "ondemands" are safe, but there's a difference between intadmins and consensus saying "this is safe and everyone can/will run it" and intadmins saying "this is safe" and then someone else deciding when you run it. I'm anathema to the idea that anyone could put a template on ANI and boom, code gets run for everyone. That doesn't feel good. ~ Amory (u • t • c) 14:41, 30 January 2024 (UTC)
🤷 I can't say I see much difference between intadmins saying "this is safe and everyone can/will run it from common.js or a default-enabled gadget" and "this is safe and everyone can/will run it on pages that have the right bit of wikitext". Anomie⚔ 22:39, 30 January 2024 (UTC)
Well, I'd say the difference is what happens when someone creates a subpage that includes the wikitext for all the ondemand gadgets a couple dozen or hundred times, then quietly transcludes it on ANI or the like? I think mw.loader is smart enough not to overload the servers, but what's that do to everyone who visits the page? Both computationally and otherwise. That's the kind of thing I mean. ~ Amory (u • t • c) 13:13, 1 February 2024 (UTC)
One or a hundred times shouldn't make a difference, each gadget should get loaded only once on the page. Anomie⚔ 01:05, 2 February 2024 (UTC)
To elaborate on what Anomie says, mw.loader is also smart enough to not overload clients. Invoking the same gadget multiple times causes it to load and execute just once. mw.loader.moduleRegistry records the module state as ready, and further load calls are no-op.
As for the one time it does load, no HTTP request takes place at all for gadgets that are <100 kb in size as they are cached in localStorage. Even for gadgets that are larger, they are typically present in the browser's disk caches (unless you are hard reloading or if the gadget was recently modified). There is research that shows the efficacy of the technique. – SD0001 (talk) 10:53, 9 February 2024 (UTC)
I don't mean to belabor the point—it's a weak opposition after all—but I'm specifically not concerned about server or network requests. I'm concerned about how trivially easy it is to disrupt large numbers of users en masse, and to do so in non-obvious ways for most folks. I know it won't be taxing as a network request, it will be taxing for the users. ~ Amory (u • t • c) 23:27, 11 February 2024 (UTC)
How would it be taxing for the users, if not for the network requests? Gadgets would include checks to bail out quickly if invoked on a page where it shouldn't be. For example, enwiki's largest gadget, xfdcloser-core if invoked on this page – where it's not supposed to do anything, bails out in about 0.5 ms. That's a really tiny amount of time, and all of this is happening well after the first paint so interactivity (TTI) is not affected. – SD0001 (talk) 18:51, 15 February 2024 (UTC)
<mapframe>, <graph> and a few other tags today allow anyone to inject JS into wiki pages. That JS has gone through gerrit code review, whereas on-demand gadgets go through a community edit request process. That's a difference, I admit, but for default-loaded code, we could consider bridging the difference by requiring all changes to go through review even if the proposer is an int-admin.
It also makes anything that pulls from an external wiki—...—more of a risk for an end-user I agree this is a concern. To address this, I would propose to not allow cross-wiki on-demand loads. Where necessary (such as in the case of WMA), we copy-paste the code locally and setup a bot to raise edit requests every time upstream is edited. (This also improves performance as local code is RL-optimized, so it's a win-win.) – SD0001 (talk) 17:45, 30 January 2024 (UTC)
BRFA filed for this at Wikipedia:Bots/Requests_for_approval/SDZeroBot_13. – SD0001 (talk) 20:10, 10 March 2024 (UTC)
I have a similar request at Wikipedia talk:TemplateStyles#Template scripts, although the script is needed for the {{sticky header}} template to move header rows to the <thead> element. If a user has to add class=load-gadget data-gadget=xyz to the table or above it, then that would complicate the usage of that template. But if it were added to the transclusion above the table, then it shouldn't be problematic and only loads on certain pages. Ideally, the script would load once on any pages that have tables with .sticky-header:not(.sortable). The sticky gadget has a similar script that moves header rows to the <thead> element. The best solution would be MediaWiki moving the header rows for all tables (not just sortable), thereby making it work when no JS. From the discussion above, there seems to be concern about trusting one person to verify the JS. I agree that there could be a lot of damage done. In that case, maybe think about having two people verify it. Jroberson108 (talk) 00:07, 17 February 2024 (UTC)
It might be a good idea to implement it like somewhat like this given Amorymeltzer’s concerns above:
mw.hook( 'wikipage.content' ).add( ( $content ) => {
    var $gadgetTargets = $content.find( '.load-gadget' );
    var onDemandDeps = [];
    $gadgetTargets.each( ( i, e ) => {
        onDemandDeps.push( 'ext.gadget.ondemand-' + e.dataset.gadget );
        if ( i === $gadgetTargets.length - 1 ) {
            mw.loader.load( onDemandDeps );
        }
    } );
} );
This should cut down the impact to less requests. stjn 01:24, 21 February 2024 (UTC)
See the follow-ups above to that concern. mw.loader already does all this internally, in a less crude way. – SD0001 (talk) 14:38, 24 February 2024 (UTC)
@SD0001: To clarify, I can use mw.loader to add template scripts to a template? Not user scripts. Jroberson108 (talk) 16:18, 24 February 2024 (UTC)
Unless I don’t know something, non-default gadgets are not stored in the LS unless they are/were used before, and the part about cache/localStorage is incorrect. But yeah, given what you say overall, not a huge concern. stjn 00:42, 25 February 2024 (UTC)
Well, for anything to get cached, it needs to be loaded once. This is true for all RL modules, not just non-default gadgets. They will surely be fetched via http calls if someone is opening Wikipedia for the first time in a while on that browser/device. But not on subsequent page loads. – SD0001 (talk) 10:13, 29 February 2024 (UTC)

Ready to implement?

Discussion has been going on for more than 2 months, and I don't see any unresolved concerns. Can we implement this now? – SD0001 (talk) 17:14, 7 March 2024 (UTC)

This is no longer required as https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 has been merged. Not the most elegant implementation as it relies on categories, but we'll take it. – SD0001 (talk) 14:33, 21 March 2024 (UTC)
Yup, seems like this entire hack can be skipped. We're going to need some serious testing with the category stuff. — xaosflux Talk 18:11, 21 March 2024 (UTC)

Removing magic editintros

The last discussion on remove the "magic editintros" (for BLP/disambig pages) was at MediaWiki talk:Common.js/Archive 22#Replacing magic editintros with editnotices and Lua. That fixated on solving the problem by detecting page categories using lua - which is not really possible until phab:T50175 is resolved. I have a patch for that in the pipeline which is stuck. But never mind, this doesn't actually need T50175:

I propose to drop the code from Common.js and include the editintros via Template:Editnotices/Namespace/Main like other editnotices. I've created Module:Mainspace editnotice which implements the existing editnotices added by the template and by Common.js. – SD0001 (talk) 06:38, 4 February 2024 (UTC)

Pinging people from the earlier discussion: @Galobtter @TheDJ @Tacsipacsi. – SD0001 (talk) 06:42, 4 February 2024 (UTC)
I'd support this, per what I said in the last discussion. I assumed it'd be too annoying to figure out disambiguation pages without the category, but since it is possible, that was the only blocker to doing what I was trying to do. The only thing is that this needs to be fast since the editnotice is parsed everytime it needs to be displayed. Galobtter (talk) 15:52, 5 February 2024 (UTC)
Performance should be no more of an issue that the already existing check for {{refideas}} on the talk page is (which I wrote without even thinking about performance and AFAIK hasn't caused any problems of that nature). * Pppery * it has begun... 17:19, 5 February 2024 (UTC)
As part of the {{draft at}} inclusion conditionals, the current editnotice is already checking whether the page is a disambiguation page. In the new module, I'm reusing the same check result for both use-cases. I also tested by not reusing the result and letting it get computed twice - even then no discernible change in lua execution time was seen at a millisecond precision. – SD0001 (talk) 17:52, 5 February 2024 (UTC)
Looks good then. Galobtter (talk) 19:02, 5 February 2024 (UTC)
I have requested the edits at Template talk:Editnotices/Namespace/Main#Interface-protected edit request on 6 February 2024. – SD0001 (talk) 10:48, 9 February 2024 (UTC)
 Done * Pppery * it has begun... 18:58, 9 February 2024 (UTC)

Unarchiving this discussion as there is a problem, as indicated at Template_talk:BLP_editnotice#Suppresses_link_to_Page_notice, which has been traced to the above edit. Is there something that can be done to resolve the issue? SilkTork (talk) 23:24, 25 May 2024 (UTC)

Removing hasClass shim

The hasClass shim looks like low-hanging fruit to be removed since almost nothing still using it is likely to have survived other javascript deprecations in mediawiki. I checked the uses - the search returned 33 results:

All results: (exported here via CD's convert to wikitext feature, and then annotated)

  • User:GregU/randomlink.js continue; if ((mw.config.get('wgAction') == "history") != hasClass(link, "mw-userlink")) continue; if (link.hostname... 8 KB (847 words) - 12:46, 29 November 2021
    • 94 users, 6 active, but the script is already broken due to undeclared use of getElementsByClassName, see last section of talk page
  • MediaWiki:LAPI.js error: ' + root.getInnerText ()); } } return doc; }, hasClass : function (node, className) { if (!node) return false; return... 73 KB (8,718 words) - 03:31, 20 November 2023
    • ☒N false positive
  • User:The Editor's Apprentice/randomlink.js continue; if ((mw.config.get('wgAction') == "history") != hasClass(link, "mw-userlink")) continue; if (link.hostname... 9 KB (1,012 words) - 13:45, 27 August 2022
    • 3 users, looks already broken as portletId used further down isn't declared anywhere. cc The Editor's Apprentice
      • It isn't already broken - that error displays but it still created a link. I edited the script to fix the hasClass issue, since I'm not willing to be the person known for willfully breaking people's stuff. * Pppery * it has begun... 01:23, 18 June 2024 (UTC)
  • User:Kimdime/monobook.js getElementsByTagName('div'); for(var a=0;a<Divs.length;a++){ if(hasClass(Divs[a],"thumbinner")){ var DivThumb = Divs[a]; ... 15 KB (1,368 words) - 16:40, 7 February 2021
  • User:Pmartin/cache.js } var element_parent = current_link.parentNode; if (hasClass(element_parent, "noarchive")) { continue; } ... 2 KB (265 words) - 03:15, 23 March 2011
  • User:Ucucha/hiderefs.js getElementsByTagName("sup"); for(var i = 0; i < refs.length; i++) { if(hasClass(refs[i], "reference")) refs[i].style.display = refs_hidden... 1,019 bytes (116 words) - 13:35, 29 November 2021
  • User:Saintrain/S3/colcol.js //====================================== hasClass ========================================================> var hasClass = (function () { var reCache = {};... 4 KB (460 words) - 20:05, 6 February 2021
    • ☒N false positive
  • User:Cacycle/MooTools.js each(arguments, this.removeProperty, this); return this; }, hasClass: function(className){ return this.className.contains(className... 117 KB (12,449 words) - 04:48, 22 November 2009
    • ☒N false positive
  • User:Ucucha/collapse.js getElementsByTagName( "tr" ); for ( var i = 0; i < Rows.length; i++ ) { if ( hasClass( Rows[i], "row-collapsebutton" ) ) { /* only add button and... 3 KB (246 words) - 04:41, 4 January 2011
    • 0 users
  • User:Verdy p/common.js getElementsByTagName("table"); for (var i = 0; i < Tables.length; i++) { if (hasClass(Tables[i], "collapsible")) { /* only add button and increment... 3 KB (326 words) - 20:24, 30 December 2021
  • User:Gary/script installer source.js (haystack[i] == needle) return true; } } return false; }; function hasClass(element, classToCheck) { if (typeof(element) == 'undefined' || !element... 52 KB (5,679 words) - 02:36, 29 November 2021
    • ☒N false positive
  • User:PrimeHunter/Diaporama.js DiapoState = Diaporama.Params.Paused[index]; if( (hasClass("Play", Span) && DiapoState == false) || ( (hasClass("Pause", Span)||hasClass("Stop", Span))&&DiapoState==true)... 10 KB (981 words) - 17:46, 18 May 2013
  • User:Cpiral/monobook.js if( !document.getElementById('mw-dismissible-notice') && !(cnote && hasClass(cnote, 'expanded'))) return; appendCSS('#bodyContent { position:relative;... 6 KB (751 words) - 07:03, 5 February 2021
  • User:Ilmari Karonen/test.js if ( hasClass( xNavChild, 'xNavPic' ) ) { xNavChild.style.display = 'none'; } if ( hasClass( xNavChild... 4 KB (379 words) - 20:14, 23 September 2008
    • 0 users
  • User:Icqa/Collapsing.js collapseColsOptout ) { if ( !hasClass( Rows[i], 'nocollapse' ) && !( hasClass( Rows[i], 'sortbottom' ) && !hasClass( Rows[i], 'collapsible' )... 5 KB (542 words) - 21:49, 3 February 2014
    • 0 users
  • User:Equazcion/DiaporamaFrench.js DiapoState = Diaporama.Params.Paused[index]; if( (hasClass("Play", Span) && DiapoState == false) || ( (hasClass("Pause", Span)||hasClass("Stop", Span))&&DiapoState==true)... 10 KB (981 words) - 18:50, 22 October 2013
    • 0 users
  • User:AvicPublic/HotCatMod.js (href.substring (prefix.length)); } return null; } function hasClass (elem, name) { return (' ' + elem.className + ' ').indexOf (' ' +... 109 KB (11,957 words) - 13:39, 21 February 2021
    • 0 users
  • User:Flatscan/showCCI.js getElementsByTagName("span"); for (var i = 0; i < spans.length; i++) { if (!hasClass(spans[i], CCI_item_hide_class)) { continue; } var itm = spans[i];... 2 KB (156 words) - 23:33, 6 February 2021
  • User:Gary/functions.js vars['revisions'] = vars['page']['revisions']; } return vars; } function hasClass(element, className) { if (!element || !element.className) return false;... 2 KB (269 words) - 03:55, 21 February 2014
    • ☒N false positive
  • User:Fred Bradstadt/show all collapsed tables.js getElementsByTagName( "table" ); for ( var i = 0; i < Ta.length; i++ ) { if ( hasClass( Ta[i], "collapsible" ) && document.getElementById( "collapseButton" +... 381 bytes (44 words) - 16:41, 27 May 2008
    • 2 users
  • User:TjBison/Collapsing.js collapseColsOptout ) { if ( !hasClass( Rows[i], 'nocollapse' ) && !( hasClass( Rows[i], 'sortbottom' ) && !hasClass( Rows[i], 'collapsible' )... 5 KB (542 words) - 08:09, 23 July 2017
    • 0 users
  • User:EdoDodo/hotcat.js (href.substring (prefix.length)); } return null; } function hasClass (elem, name) { return (' ' + elem.className + ' ').indexOf (' ' +... 99 KB (10,801 words) - 13:40, 21 February 2021
    • 0 users
  • User:Gary Queen/layout.js previousSibling; if ((two && hasClass(two, leftAlignedThumb)) || (three && hasClass(three, leftAlignedThumb)) || (four && hasClass(four, leftAlignedThumb)))... 20 KB (2,241 words) - 23:49, 6 March 2021
    • 0 users
  • User:Samuel Wiki/navonce.js ONCE_NavChild = ONCE_NavChild.nextSibling) { if (hasClass(ONCE_NavChild, 'NavPic') || hasClass(ONCE_NavChild, 'NavContent')) { ONCE_NavChild... 7 KB (716 words) - 13:52, 26 January 2016
    • 0 users
  • User:Dr Brains/RightClicMenu.js for(i=0;i<Navig.length;i++){ if ((hasClass(Navig[i], "portlet" )) || (hasClass(Navig[i], "mw_portlet" )) || (hasClass(Navig[i], "portal" )) ){ ... 132 KB (11,496 words) - 23:34, 6 March 2021
    • 0 users
  • User:Kornatice/vector.js continue; if ((mw.config.get('wgAction') == "history") != hasClass(link, "mw-userlink")) continue; if (link.hostname... 8 KB (845 words) - 23:24, 15 March 2021
  • User:Giudark/vector.js collapseColsOptout ) { if ( !hasClass( Rows[i], 'nocollapse' ) && !( hasClass( Rows[i], 'sortbottom' ) && !hasClass( Rows[i], 'collapsible' )... 5 KB (542 words) - 22:27, 22 January 2016
  • User:Kawawish/common.js search(nspat) >= 0) continue; if ((wgAction == "history") != hasClass(link, "mw-userlink")) continue; if (link.hostname... 7 KB (802 words) - 02:11, 7 February 2021
  • User:Dr Brains/Utilities.js insertBefore(node, referenceNode.nextSibling); } } if(typeof(hasClass)=="undefined"){ function hasClass(node, className) { if (node.className ==... 4 KB (353 words) - 20:22, 21 August 2010
    • ☒N will be unaffected
  • User:Evad37/qunit-2.8.0.js while (i--) { addEvent(elems[i], type, fn); } } function hasClass(elem, name) { return (" " + elem.className + " ").indexOf(" " + name... 183 KB (20,148 words) - 15:50, 1 January 2019
    • ☒N false positive
  • User:Nemoi/common.js getElementById('mw-hidden-catlinks')) ) return; if( hasClass(hc, 'mw-hidden-cats-user-shown') ) return; if( hasClass(hc, 'mw-hidden-cats-ns-shown') ) addClass(hc... 2 KB (191 words) - 02:21, 7 February 2021
  • User:V.narsikar/common.js i < tableIndex; i++ ) { if ( hasClass( NavigationBoxes[i], 'collapsed' ) || ( tableIndex >= autoCollapse && hasClass( NavigationBoxes[i], 'autocollapse'... 15 KB (1,736 words) - 21:25, 27 February 2022
  • User:Kimdime/vector.js getElementsByTagName('div'); for(var a=0;a<Divs.length;a++){ if(hasClass(Divs[a],"thumbinner")){ var DivThumb = Divs[a]; ... 15 KB (1,368 words) - 21:36, 6 February 2021
    • 1 user

If anyone's interested, the simple way to migrate uses is to replace hasClass(A, B) to $(A).hasClass(B). – SD0001 (talk) 11:49, 2 June 2024 (UTC)

SD0001, did you mean to ping me or PrimeHunter? Primefac (talk) 12:22, 2 June 2024 (UTC)
oops! – SD0001 (talk) 12:32, 2 June 2024 (UTC)
I have deleted User:PrimeHunter/Diaporama.js which used hasClass but was just an old unused test. PrimeHunter (talk) 12:48, 2 June 2024 (UTC)
I believe we can remove lines 26–33. Essentially zero usage. – SD0001 (talk) 10:34, 16 June 2024 (UTC)
 Done I was paranoid and edited a few user JS pages to migrate them myself, because it seemed wrong to deliberately break things for a few people when we could avoid doing so. See inline comments above. * Pppery * it has begun... 01:23, 18 June 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_23&oldid=1237173096"