MediaWiki talk:Common.js/Archive 22

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

Default to moving subpages when moving a page

Tracked in Phabricator
Task T141545

There is consensus that when moving a page with admin or page mover rights, the default action should be to move all subpages. See discussion here: Wikipedia talk:Page mover#Moving subpages should be the default action. The confusion arises for example when moving an article whose Talk page has archives: the talk page itself and subpages of the article, if any, are moved, but subpages of the talk page are not, and this creates lots of work to detect the mistake and correct it after the fact, especially when talk pages have long archives. A personal setting in common.js has been made available, and we would like to apply a similar technique to the global common.js, so that the relevant checkbox is ticked by default. — JFG talk 13:33, 28 July 2016 (UTC)

This seems like something that should be solved in the configuration of the software and not in Common.js. Next to that, javascript that is only delivered to a single page, should generally not be part of Common.js, which is for things delivered to ALL pages. Please file a phabricator ticket. —TheDJ (talk • contribs) 15:51, 28 July 2016 (UTC)

Convert watchlist notices into a Resource Loader module

What about moving this script to a (default) gadget, such as MediaWiki:Gadget-watchlist-notices.js, so that its code can be minified and loaded by Resource Loader? This would be similar to what we did with MediaWiki:Gadget-geonotice-core.js. Helder 12:31, 26 June 2016 (UTC)

Sounds like a good idea. Same could be said for MediaWiki:Common.js/edit.js. -- [[User:Edokter]] {{talk}} 12:39, 26 June 2016 (UTC)
Sounds like a good idea (to keep this thread alive), but finding an admin to do it might be a bit tough. Enterprisey (talk!) (formerly APerson) 01:13, 9 July 2016 (UTC)
@Enterprisey and He7d3r: Maybe you can ask on WP:VPT? I have had success at getting JavaScript knowledgeable people there.Jo-Jo Eumerus (talk, contributions) 20:23, 28 July 2016 (UTC)

The procedure would be like this:

  1. Remove from MediaWiki:Common.js:

    else if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Watchlist' ) {
    /* watchlist scripts */
    mw.loader.load( '/w/index.php?title=MediaWiki:Common.js/watchlist.js&action=raw&ctype=text/javascript' );
    }

  2. Create MediaWiki:Gadget-watchlist-notice.js with

    if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Watchlist' ) {
    mw.loader.load( 'ext.gadget.watchlist-notice-core' );
    }

  3. Move MediaWiki:Common.js/watchlist.js to MediaWiki:Gadget-watchlist-notice-core.js
  4. Add to MediaWiki:Gadgets-definition:

    * watchlist-notice[ResourceLoader|default]|watchlist-notice.js
    * watchlist-notice-core[ResourceLoader|hidden|rights=hidden]|watchlist-notice-core.js

  5. Describe the gadget at MediaWiki:Gadget-watchlist-notice. E.g.:

    Add dismiss buttons to watchlist notices.

Helder 17:59, 7 August 2016 (UTC)

Done I've converted both MediaWiki:Common.js/watchlist.js and MediaWiki:Common.js/edit.js into gadgets. The former is at MediaWiki:Gadget-watchlist-notice.js and MediaWiki:Gadget-watchlist-notice-core.js, and the latter is at MediaWiki:Gadget-extra-toolbar-buttons.js and MediaWiki:Gadget-extra-toolbar-buttons-core.js. — Mr. Stradivarius ♪ talk ♪ 07:53, 23 August 2016 (UTC)
Thanks Mr. Stradivarius!
I noticed the MediaWiki:Gadget-extra-toolbar-buttons-core.js contains a small code which is unrelated to toolbar buttons (search for "Fix edit summary prompt for undo", at the end of the file). Was that intended? Helder 17:23, 7 September 2016 (UTC)
@He7d3r: I just moved the page without touching the code, as I assumed that everything in the file should run as it had before. It might be neater to put that snippet into another default gadget, I agree, as it's confusing for something labled as "additional edit buttons" to have unrelated functionality. — Mr. Stradivarius ♪ talk ♪ 00:20, 8 September 2016 (UTC)

Add editnotice

Following this unopposed proposal, {{Wikipedia information pages talk page editnotice}} was created and and manually applied to all pages in Category:Wikipedia information pages. However, the notice does not automatically appear on pages that are added to the category, which was my intent. I'm told that requires the addition of this script to common.js. Can someone please do this? Thanks, —swpbT 20:10, 19 January 2017 (UTC)

 Not done swpb please establish a consensus here first (for using the site wide javascript to implement this). — xaosflux Talk 15:37, 20 January 2017 (UTC)
Can't a bot just throw it on those pages, why abuse the master javascript for something that will not impact most people? — xaosflux Talk 23:15, 19 January 2017 (UTC)
To editors Xaosflux and Enterprisey: I don't care how it's done, I just want it done. I already got a consensus for the behavior; it's very frustrating that it's this hard to get it implemented. If you think a bot is the best solution, I'll pursue that. —swpbT 16:07, 20 January 2017 (UTC)
The "unopposed" proposal appears to have been contributed to by 2 editors, that is a bit lacking for updating the configuration that is used for every single reader and editor on every single page. Enterprisey do you have more insight in to this? — xaosflux Talk 18:47, 20 January 2017 (UTC)
Uh, sure. I originally thought a gadget would also have worked well for this job, since that automatically makes it configurable by users (if we decide not to make it hidden). Either way (gadget or common.js change), I think we at least need a VPT consensus, since this does impact quite how quite a few pages display. Enterprisey (talk!) 18:57, 20 January 2017 (UTC)
This is just a edit notice right? It can easily be added to the 200 pages as a template, no? — xaosflux Talk 19:00, 20 January 2017 (UTC)
The idea was to have it automatically appear, in the style of our existing "magic editnotices". Using a template is fine by me, if a little labor-intensive. Enterprisey (talk!) 22:00, 20 January 2017 (UTC)
Exactly. The existing {{Disambig editintro}} suggested to me that this would not be a problem. I'm perfectly happy to have this implemented by bot, gadget, or whatever. What I'm not happy with is for it to be held up on the basis of insufficient consensus, as I've said on my bot request. —swpbT 15:32, 23 January 2017 (UTC)
The existing disambig (and blp) intro is there because doing it differently would be rather disruptive considering how many disambiguation pages and blp's we have. They are however also extremely annoying and from a long term technical support point of view, and we should avoiding new ones. Basically they are notices that we probably at some point have to fix inside the core software, and the more of them we have, the more migration cases we would likely end up with. —TheDJ (talk • contribs) 16:14, 23 January 2017 (UTC)
The sub cat Category:Wikipedia how-to shuold also have this.--Moxy (talk) 01:46, 8 March 2017 (UTC)

Protected edit request on 13 March 2017

please add the following code to MediaWiki:Common.js. it will replace <span class="insertusername"></span> with the user's username which can in turn be encorporated into the username template so it can be accessed with {{USERNAME}} this code is in action on The minecraft how-to wiki and loads the username when the page finishes loading Thank you Minion3665 

/* Any JavaScript here will be loaded for all users on every page load. */
/* Replaces {{USERNAME}} with the name of the user browsing the page.
   Requires copying Template:USERNAME. */
function UserNameReplace() {
    if(typeof(disableUsernameReplace) != 'undefined' && disableUsernameReplace || wgUserName === null) return;
    $("span.insertusername").html(wgUserName);
 }
 addOnloadHook(UserNameReplace);
 
/* End of the {{USERNAME}} replacement */

Minion3665 (talk) 21:12, 13 March 2017 (UTC)

Not done: Consensus exists against its implementation — Train2104 (t • c) 21:23, 13 March 2017 (UTC)

Adding en.wp inner/outer/autocollapse to mw-collapisble

Please add the following fragment: 

/**
 * Add support to mw-collapsible for autocollapse, innercollapse and outercollapse
 *
 * Maintainers: TheDJ
 */
function mwCollapsibleSetup( $collapsibleContent ) {
	var $element,
		autoCollapseThreshold = 2;
	$.each( $collapsibleContent, function (index, element) {
		$element = $( element );
		if ( index > autoCollapseThreshold && $element.hasClass( 'autocollapse' ) ) {
			$element.data( 'mw-collapsible' ).collapse();
		} else if ( $element.hasClass( 'innercollapse' ) ) {
			if ( $element.parents( '.outercollapse' ).length > 0 ) {
				$element.data( 'mw-collapsible' ).collapse();
			}
		}
	} );
}

mw.hook( 'wikipage.collapsibleContent' ).add( mwCollapsibleSetup );

Right below where it says: 

mw.hook( 'wikipage.content' ).add( createCollapseButtons );

This will enable the core collapsing code to support the English Wikipedia specific collapsing structures. With this in place, we may at some time in the future begin to finally get rid of all the custom collapsing code we use in English Wikipedia. (long term goal, expect it to take years) —TheDJ (talk • contribs) 21:39, 18 October 2016 (UTC)

@TheDJ: done. Maybe time to request your admin tools back? — Martin (MSGJ · talk) 11:21, 20 October 2016 (UTC)
From what I can tell, this doesn't work. See here for an example. Any idea why? --Porplemontage (talk) 07:54, 25 March 2017 (UTC)
@Porplemontage: You are right, I had made a mistake in my interpretation of the original logic. Should be fixed now. —TheDJ (talk • contribs) 12:43, 25 March 2017 (UTC)
Cool, it works now. Just a heads up, if you want them both to trigger at 2, do $collapsibleContent.length >= autoCollapseThreshold. --Porplemontage (talk) 21:20, 25 March 2017 (UTC)

BTW. I've been looking into this a bit.. I wonder if it's not smarter to get rid of the autocollapse class. Maybe it is better to just have this behavior automatically on navbox'es and maybe of some tables if they are children of infobox or something. The whole autocollapse routine was always really weird in that it basically doesn't care about what you are collapsing. That's bad, because it means that one extra navbox at the bottom of a page, can suddenly collapse something totally unrelated in an infobox if you aren't careful. It's always annoyed me. —TheDJ (talk • contribs) 14:26, 25 March 2017 (UTC)

Broken JavaScript

MediaWiki developers found that this page probably breaks JavaScript for users (example: not seeing the buttons when editing a page). You probably need to edit this .js page and/or MediaWiki:Gadgets-definition as in the examples at phabricator:T122755. List more pages to check.

If you have questions or need help, please ask at phabricator:T164242. You can login with your wiki account. Best wishes, Nemo 09:49, 14 May 2017 (UTC)

Remove deprecated functions

There are still three deprecated functions being mapped to their modern versions (addPortletLink, getURLParamValue and hasClass). These have been there for over two years minimum, if not three. Can they finally be removed now? -- [[User:Edokter]] {{talk}} 19:34, 26 March 2016 (UTC)

Im checking with Krinkle if by any chance we have log events collected for these as well.I doubt they are still much in use, but if we do have those log events, it might allow us to confirm this before we disable. —TheDJ (talk • contribs) 18:37, 1 April 2016 (UTC)
I've now removed them. Most stuff got a lookover when we recently dropped all the other old stuff, so might as well bite the bullet. —TheDJ (talk • contribs) 19:42, 11 July 2017 (UTC)

Unused dependency

jquery.client is no longer required--Dixtosa (talk) 07:01, 14 August 2017 (UTC)

@Dixtosa: thx for reporting. —TheDJ (talk • contribs) 13:29, 8 September 2017 (UTC)

Bug or incompatibility between the Monobook skin and the Infobox template

I believe that there is a bug or incompatibility between the Monobook skin and the Infobox template. When I use Monobook, it messes up Template:Infobox. When I switch to another skin, the issue disappears.

— goethean 19:58, 22 November 2017 (UTC)

I'm in monobook and not having any issues with those pages. — xaosflux Talk 20:21, 22 November 2017 (UTC)
Try disabling your custom monobook enahncements at User:Goethean/monobook.js. — xaosflux Talk 20:22, 22 November 2017 (UTC)
Removing my custom monobook.js and then bypassing the cache seems to have fixed the issue. — goethean 21:42, 22 November 2017 (UTC)

WikiMiniAtlas

Tracked in Phabricator
Task T185797
Resolved

I'm disabling meta:WikiMiniAtlas for now as the server is crashed. Feel free to revert when service is restored. — xaosflux Talk 15:33, 27 January 2018 (UTC)

Edit Request

It seems that the JS that was removed in #Remove_deprecated_functions was added back, could it be removed? --Terra (talk) 22:55, 11 June 2018 (UTC)

TheDJ reverted himself because the functions are still widely used, shortly after he made that talk page edit, so it was never really removed. --Izno (talk) 23:21, 11 June 2018 (UTC)
Ah, thanks for explaining it. --Terra (talk) 23:28, 11 June 2018 (UTC)
We should really try that again sometime.. But i'm not sure if I have the time —TheDJ (talk • contribs) 09:10, 12 June 2018 (UTC)

Switching watchlist notices to use web storage instead of cookies

See: MediaWiki talk:Gadgets-definition#Switching_watchlist_notices_to_use_web_storage_instead_of_cookies. —TheDJ (talk • contribs) 09:02, 14 June 2018 (UTC)

Collapsing

So I have now replaced the collapsible code with a shim that transforms the older collapsibles to mw-collapsible code. I've been working on this and testing it out on test.wikipedia.org for quite a while and this should save us quite a bit of code. Replacing NavFrame is still not quite there yet, as I try to figure out the right way to deal with positioning the toggle. I hope to finish that somewhere in the next few weeks. The deprecation warnings I kept disabled for now, as I want to make sure this transition works 100% before encouraging people with such messages to switch the template code. —TheDJ (talk • contribs) 18:40, 2 June 2018 (UTC)

now reverted as there seems to be slight differences. Mw-collapsible positions the toggles in the right most cell of a table row, whereas collapsible seems to use the first th cell. I dont find that particularly logical but it seems that we have a few pages that depend on it and i cant fix that. Guess this will have to wait a couple more months —TheDJ (talk • contribs) 11:02, 3 June 2018 (UTC)
This refers to a discussion at Talk:List of highest-grossing films#Franchise table. PrimeHunter (talk) 12:13, 3 June 2018 (UTC)
I've figured out a workaround. This won't make it possible to use this technique when you convert it to mw-collapsible, but also doesn't break the shim. For now... —TheDJ (talk • contribs) 13:15, 3 June 2018 (UTC)
Thanks TheDJ. For the record, Impru20 made a possibly related report [1] with no example after your first edit and reverted after your second edit with summary "Nevermind, this has seemingly been solved". He edited Opinion polling for the next Spanish general election earlier so maybe it was about that. It seems OK now and looks best with show/hide in the first column as now. A minor issue: Some of the header cells use rowspan to display a color code for parties and this causes the tables to render with no bottom border for me in Firefox when they are collapsed and the second header row with the color codes is hidden. Example:
I don't know whether this behaviour is new. I see a bottom border in the same example when rowspan and second header row is removed:
Other browsers may ignore the issue and display normal borders in both cases. This happens in Microsoft Edge and Internet Explorer. I don't know whether any browser or other software does anything worse than omit the bottom border in a one-row table with rowspans. I guess the issue could be avoided if the collapse code removed rowspans from the remaining row but it may not be worth the effort. PrimeHunter (talk) 14:22, 3 June 2018 (UTC)
I cannot be certain without reverting, but based on interpreting the logic, it shouldn't be new behavior. This is border collapsing at play. Due to the hidden rows, which are part of the 'rowspan' block, an incomplete table is created if you hide those colorcodes and this will trigger undefined behavior of the border collapsing, creating this problem. You shouldn't use collapsible code on rowspans as collapsible only knows about the first row and the subsequent rows. —TheDJ (talk • contribs) 15:34, 3 June 2018 (UTC)

@TheDJ: Is the issue reported at User talk:Hhkohh#Squad templates related to this change? — JJMC89 (T·C) 04:05, 24 June 2018 (UTC)

@JJMC89: I dont know. Do you have a link to a page/revision with a specific template invocation where this occurs ? Because apparently half of the problems were fixed, making it hard for me to look at the problem. —TheDJ (talk • contribs) 06:44, 24 June 2018 (UTC)
@TheDJ: The navboxes at the bottom of Mihai Roman (footballer, born 1992) are both expanded instead of autocollapsed. — JJMC89 (T·C) 06:50, 24 June 2018 (UTC)
@JJMC89: Yes it was related. I previously interpreted the code as autocollapse kicking in at more than 2 collapsible elements, but it is actually 2 or more. Should be fixed now. —TheDJ (talk • contribs) 10:50, 24 June 2018 (UTC)

Stop using collapse shim

Should a bot be ran to update all remaining uses of collapse and etc mw-collapse so the shim can be removed from the common.js? — Preceding unsigned comment added by TerraCodes (talk • contribs) 11:11, 21 November 2018 (UTC)

In the mainspace, there are on the order of 50k uses. Those should probably be removed entirely per WP:MOSCOLLAPSE, not converted. --Izno (talk) 13:23, 21 November 2018 (UTC)
TerraCodes, eventually.. maybe.. I don't know. There is no real rush and template usages should probably be fixed before any other usages. But sometimes it can be difficult, as usages of the templates can often override the behavior via a parameter, so that would have to be taken into account. —TheDJ (talk • contribs) 13:54, 21 November 2018 (UTC)

Getting rid of deprecations

So it's very hard finding scripts that break, because we don't know who is using what. There are deprecation warnings in the console these days, but most users never see these of course, causing a particularly long and invisible long tail of failures for users. I've been thinking about this for a while now, esp. in order to get rid of the current getParamValue, hasClass and addPortletLink methods that we still have in our MediaWiki:common.css. So what I was thinking, is to send out popup notifications, with a link to a preloaded edit section on a dedicated noticeboard.

The following code shows an example for doing that for addPortletLink. 

function localDeprecate(obj, key, val, msg, logName) {
	mw.notify( $.parseHTML('Your wiki Javascript will soon stop working because it is using the outdated '
		+ encodeURIComponent( key )
		+ '. You can report at the <a href="/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard/helpme&action=edit&section=new&preload=Wikipedia:Interface_administrators%27_noticeboard/deprecationsTemplate' 
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( mw.config.get('wgUserName') )
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( key )
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( msg )
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( mw.config.get('skin') )
			+ '">noticeboard</a> to request assistence.'), {
		autoHide: false,
		type: 'warn'
	} );
    mw.log.deprecate( obj, key, val, msg, logName );
}

mw.loader.using('mediawiki.util', function() {
	localDeprecate( window, 'addPortletLink', mw.util.addPortletLink, 'Use mw.util.addPortletLink instead' );
	addPortletLink();
})

Opinions ? Improvements ? —TheDJ (talk • contribs) 13:28, 6 November 2018 (UTC)

Searching "insource:/[^\.]addPortletLink/ intitle:/\.js/" in userspace seems to work well enough to find uses of addPortletLink. There are quite a few uses, and IMO they should be reduced - at-least the most used scrips (like User:AndyZ/peerreviewer.js used by ore than 500 people) should be fixed - before anything like this is done to not cause a wave of annoyance. Maybe an intadmin can AWB/Bot over the 3000 pages found by the search replacing "addPortletLink" with "mw.util.addPorletLink"... Galobtter (pingó mió) 13:51, 6 November 2018 (UTC)
The problem is that many of these people and scripts aren't active any longer, making much of those pages a waste of effort to go through. The peerreview script you refer to is a prime example, where it's only mentioned in a comment for instance. And it's not a simple replacement either. You need to ensure mediawiki.util is loaded, and that the pageready hook has fired as well. That was the whole point, to reduce the load by focusing on those people actually affected by the problem. —TheDJ (talk • contribs) 16:11, 6 November 2018 (UTC)
Oops on that; but still, there are reasonably widely used scripts (User:Lifebaka/closedrv.js and User:Dr_pda/prosesizebytes.js, used by ~100 people each) that should be fixed first. Also, this code would appear to pop-up on every page that a portlet link is added? That would be pretty irritating if one has a script that adds a portlet link on most pages, and so you'd also have to explain how to remove the script from one's js until the portlet link issue is fixed. Galobtter (pingó mió) 20:14, 6 November 2018 (UTC)
This seems like a reasonable approach. Another approach would be to get a list of the most active users, get a list of those user's Javascript pages, and then scrape those for other scripts being loaded (with whatever calling functions) + direct calls to deprecated functions (and of course, consolidate final data so you have some final list of scripts to change). This is more work but takes care of the 95% of people who log in regularly. --Izno (talk) 23:21, 6 November 2018 (UTC)

According to the mwgrep tool there are 72 occurences in the MediaWiki namespaces (see Phab:P7768), and 9,567 occurences in user namespaces. ESanders (WMF) (talk) 19:39, 6 November 2018 (UTC)

I started some related work at User:TheDragonFire/Removing deprecated functions back in June if someone wants to collaborate. TheDragonFire (talk) 11:04, 22 December 2018 (UTC)

Interface-protected edit request on 21 December 2018

Please add the following code snippet to MediaWiki:Mobile.js. 

$('document').ready(function (){
var pageName = $('#mw-mf-diff-info a').text();
$('#mw-mf-diff-info a').attr('href',mw.util.getUrl(pageName));
});

This code snippet will get rid of an annoying bug which was introduced about a month or two ago into Special:MobileDiff where the link labelled as the page name led to an older version of the article instead of the article itself.  — fr + 08:18, 21 December 2018 (UTC)

Is there a consensus that this behavior is a bug/should be changed? It doesn't seem unreasonable that the link in the diff header takes you to the revision of the page in question; in fact, I wrote a script to do this myself for non-mobile diff pages. Writ Keeper ⚇♔ 22:36, 21 December 2018 (UTC)
WK, there isn't much of a consensus in the sense of the word but there have been two posts at WP:VPT, one by Capankajsmilyo [here] and by User:Ɱ [here] both of whom have asked for it to be changed. Additionally, I am sure that there are a lot of other people who would want this change because the introduction of this "feature" has disrupted certain workflows in the mobile interface. — fr + 10:44, 22 December 2018 (UTC)
I'm inclined to agree with Writ Keeper — I think this behavior is desired, and makes sense to me. It takes you to the full view of the page as of that revision, which seems like expected behavior. This proposal does, however, seem like a reasonable temporary fix for phab:T200969 until that gets fixed. ~ Amory (u • t • c) 10:57, 22 December 2018 (UTC)
As a frequent mobile contributor I find it quite useful to view specific revision of page, which was not possible before without going to desktop view, so I guess it's not a bug. Also latest revision can be visited by clicking page name in history. ‐‐1997kB (talk) 11:32, 22 December 2018 (UTC)
1997kB, whenever I use my phone, the first thing I do is to check my watchlist. When I click on the diff, I sometimes find that I would like to refine an editor's edit. However, I am unable to do that in one step, rather I have to make multiple clicks to get to an editable version of the article, which is not desirable. I agree that having a link to the specific revision is useful, but not in this poorly implemented format  — fr + 12:05, 22 December 2018 (UTC)
@FR30799386: I see, but instead of removing it we should request adding both link in diff viewer. ‐‐1997kB (talk) 12:27, 22 December 2018 (UTC)
 Not done: please establish a consensus for this alteration before using the {{edit interface-protected}} template. Izno (talk) 14:44, 22 December 2018 (UTC)
Izno, will I have to open a discussion at WP:VPT ? — fr + 17:40, 23 December 2018 (UTC)
FR30799386, that's one way. You can leave a comment there inviting editors here too. --Izno (talk) 02:09, 24 December 2018 (UTC)

Interface-protected edit request on 15 May 2019

Suggest adding the following: 

// Show diffs of modules and scripts in monospaced font
if( ['javascript', 'css', 'Scribunto'].indexOf(mw.config.get('wgPageContentModel')) !== -1 ) {
    $('td.diff-addedline, td.diff-deletedline, td.diff-context').css('font-family',"Consolas, 'Courier New', monospace");
}

It is easy for the eyes to look at diffs of code pages (CSS/JS/Scribunto) in monospaced font. All code editors use monospaced fonts after all. I've been using this in my common.js for quite some time. Felt that this would be useful for everyone. SD0001 (talk) 10:04, 15 May 2019 (UTC) SD0001 (talk) 10:04, 15 May 2019 (UTC)

not done. Things that are useful for such a small group of users should not require Js on every single page of the wiki. Pure CSS options or a patch to the core software seem much more suitable for this. —TheDJ (talk • contribs) 10:34, 15 May 2019 (UTC)
@TheDJ: Opened phab:T223429. SD0001 (talk) 09:38, 16 May 2019 (UTC)

Interface-protected edit request on 13 July 2019

I suggest importing meta:User:FR30799386/undo.js since mobile version of Wikipedia lacks undo feature. I originally nominated it to be a gadget on WP:VPT#Undo script. All information regarding it can be find on WP:VPT. Thanks. Masum Reza📞 09:16, 13 July 2019 (UTC)

I do not think that discussion indicates consensus to add additional Javascript to every mobile page load for all users. --Izno (talk) 13:20, 13 July 2019 (UTC)
In fact, given the sparse response, I'm pretty sure there's no consensus to add it even as a gadget. --Izno (talk) 13:23, 13 July 2019 (UTC)
 Not done mobile.js is loaded for every reader so adding functionality only useful for editors (and really not just the casual mobile 'fix something small' type editors) is overkill here. Continue your discussion to see if anyone wants it as an opt-in gadget first. — xaosflux Talk 13:38, 13 July 2019 (UTC)

Interface-protected edit request Mobile.js

The code in MediaWiki:Mobile.js relating to purging is outdated and should have been removed a long time ago. Jdlrobson (talk) 03:41, 15 July 2019 (UTC)

 On hold this was only added a few months ago, @Jon (WMF): can you respond to this? — xaosflux Talk 12:58, 15 July 2019 (UTC)
Xaosflux, he's the one requesting it ;) —TheDJ (talk • contribs) 13:21, 15 July 2019 (UTC)
@TheDJ: lol - @Jdlrobson: you added this with your staff account - do you want the entire script removed or only a part of it? If only a part, can you provide a sandbox of the new revision? (Or just revert your staff action with your staff account). — xaosflux Talk 14:19, 15 July 2019 (UTC)
it can be completely blanked. I wasn't at work yesterday so didn't have access to my staff account and this account doesnt have the sufficient permissions. Jdlrobson (talk) 19:37, 15 July 2019 (UTC)
Thank you,  Done — xaosflux Talk 19:39, 15 July 2019 (UTC)

MetadataPanel date fix

Tracked in Phabricator
Task T243160

Please add the following lines toward the end of the file: 

mw.loader.using( 'mmv' ).then(function() {
    mw.mmv.ui.MetadataPanel.prototype.formatDate = function ( dateString ) {
		var date,
			lang = mw.config.get( 'wgUserLanguage' );
		if ( lang === 'en' ) { lang = 'en-GB'; } // for D MMMM YYYY format
		date = new Date( dateString );
		try {
			if ( date instanceof Date && !isNaN( date ) ) {
				date.setMinutes(date.getMinutes() + date.getTimezoneOffset());
				return date.toLocaleString( lang, {
					day: 'numeric',
					month: 'long',
					year: 'numeric'
				} );
			}
		} catch ( ignore ) {}
		// fallback to original date string
		return dateString;
    };
});
Background
  • Bug report here: phab:T245919. Summary: the MediaViewer doesn't take into account timezone when reporting date.
  • Anybody with <= -1 UTC will get an off by one error for most images.
  • Example: File:Notorious_(1946_film_poster).jpg has a listed date of 1946, but the Mediawiki viewer reports it as December 31, 1945. Click here to see.
Technical description
  • This is an exact copy of the exiting prototype, but adds a single line: date.setMinutes(date.getMinutes() + date.getTimezoneOffset());.
  • In order to ensure forwards compatibility, it was not possible for me to call the existing method. I had to override the entire thing.
Further action
  • Once the WMF fixes this, we can remove this patch.
Caveats
  • I am perfectly OK with this script going in another file if convention calls for it. However I do believe it should be global.
How can the reviewing administrator be sure this is safe?
  • I am a professional front-end developer.
  • I am a long-time community member who runs lots of bots.
  • Copy and paste the code directly out of Github and make the same change.
  • Test it on your own, of course.
Why is this critical enough for a patch
  • It's a bug and a poor user experience.
  • Users are creating their own workarounds by inserting bad data on Commons. For example, adding the date as 1521-01-02. So we want to nip this in the bud ASAP.

Thank you. Magog the Ogre (t • c) 17:27, 22 February 2020 (UTC)

 On hold @Magog the Ogre: at the very least, this needs more discussion. Forcing in a javascript hack for every single reader on every page load is not the right way to fix this. You said this is "critical", however phab:T243160 isn't event triaged yet. Assuming this is critical it is certainly a global problem (at least across all WMF projects), so should be fixed upstream in mw:Extension:MultimediaViewer. If there is a patch ready to go, and we were only waiting for the deployment train a temporary workaround may be useful. — xaosflux Talk 17:44, 22 February 2020 (UTC)
@Xaosflux: Did you even bother to read what I wrote before you rejected it? No, I know you didn't, because all the concerns you just brought up are addressed in the ticket. I already plan to push this upstream. This isn't a "hack". This already is a temporary fix, which I made abundantly clear here and in the ticket. And I already crossposted it to VPT and am waiting for discussion. What else do you want? Do I need to go over your head and request access on BN? Because I'm more than qualified to have this right. Magog the Ogre (t • c) 18:24, 22 February 2020 (UTC)
Well, for starters, xaosflux was saying discussion needed to happen first; you started one, but there hasn't actually been any yet. With the post at VPT, it's not really useful to have this request open, since you've requested discussion. I happen to agree with xf — I wouldn't call a minor date issue on the media viewer critical to en.wiki. Doing it here certainly won't help anything on Commons. In particular, I would think loading this for every single page load is beyond overkill; is there really no way to limit it to when the media viewer is actually used? Otherwise it's almost entirely deadweight added to page loads. ~ Amory (u • t • c) 18:45, 22 February 2020 (UTC)
@Magog the Ogre: I read every word, read your bug report, followed it to the earlier ticket as well and also read that. Very notably this discussion has not been "closed" or "rejected" - simply that the immediate edit request has not been implemented, specifically asking for more discussion. This is that discussion, which is open and active and anyone is welcome to contribute to it. Should this discussion close with a consensus to proceed with your proposal please feel free to reactivate the edit request. — xaosflux Talk 20:53, 22 February 2020 (UTC)`
@Xaosflux No, no you didn't. Your words speak for themselves. You talked about an upstream patch and doing a temporary fix here as if that was some novel idea, when I clearly spelled out both here and there.
@Amory This has nothing to do with Commons. This is a bug sitewide, and I am implementing a local fix because English Wikipedia is the most used wiki.
You guys are focusing on the "critical" wording to pick a part the request because you don't want to fulfill it. Frankly, that is a stupid reason not to do a fix.
No, this isn't deadweight. Have you ever worked in Javascript in your whole life? It is a single hook added at the end of the page on a site with thousands of hooks. This affects user experience.
I have worked with files and images more than anybody on this entire wiki. I mean that literally. I have written bots and scripts on this wiki and others. I am a long-serving administrator here and a checkuser on Commons. I've been a web developer for 20 years, much of it professional. I have people working under me, and I work in large teams. I am the second highest web developer for a Fortune 500 company. I know what deserves a patch and what doesn't.
I then take my entire morning, in my free time, and not only report a bug (that users complaining about!), but write a fix. I follow the entire procedure, I open a discussion as required. And then you come along close my request and you won't even the discussion a few days to go through?
You know what? Fuck it. I'm out. If that's how this site is going to treat its contributors, I want nothing to do with it. Forget my pull request which I was going to make. I will also take my hundreds if not thousands of hours of botwork and go home. Goodnight. Magog the Ogre (t • c) 22:55, 22 February 2020 (UTC)
Sorry this has gotten so heated, from the start of this discussion my primary concern was that this needs more discussion prior to making the change. I'm not claiming to be the ultimate decider. I am also very supportive of keeping up with Category:Requested edits, as it is an important check against the protection policy; at no point did I mean to suggest that deactivating the edit request meant this shouldn't be considered, I should have used a longer edit summary. — xaosflux Talk 00:32, 23 February 2020 (UTC)
Neither of us was trying to impugn your intent or devotion, and I'm sorry for frustrating you. I'll gladly enact it if there's consensus to do so, I'm no authority You asked for input and I gave my two cents, and that's all we have; a simple disagreement among three editors. I don't think there's a need for hostility, but I am sorry for making you feel mistreated, it really wasn't my intent. ~ Amory (u • t • c) 01:23, 23 February 2020 (UTC)
OK, guys. I'm really sorry for my absolute shitfit yesterday. I will make no excuses: when I get upset, I have the self-control and emotional maturity of a child.
Regardless, I stand by my assessment. I will create my pull request, but how many months do we need to let this stay broken until it gets pushed to production? I don't know Mediawiki's development schedule but most companies go months between releases. Magog the Ogre (t • c) 16:32, 23 February 2020 (UTC)
@Magog the Ogre: thanks for the note, looks like the discussion is continuing below. Putting in work-arounds does happen, and it is good if they are linked to a fix that is planned so we can ensure to follow up on them. I think we both agree that the best way to push this out would be to fix the faulty code that is running on every project, not to mention third party installations (but agree that can be a slow process - though the slowest part is normally the time it takes someone to create a new patch, not the deployment train). From what is continuing it appears that the largest discussion is about adding to page loads vs the benefit of this fix. Do you know if this is also occurring on mobile (as they would need separate work-arounds). — xaosflux Talk 19:19, 23 February 2020 (UTC)
@Magog the Ogre: For me (Firefox 73 Linux), mw.loader.using( 'mmv' ) causes this request. That's 232KB of JS, or about 63KB compressed. I get roughly similar results from a new private browser window, so it's not just something peculiar about my account. By contrast, loading the MP logged out with an empty cache requires a total of 933KB (356KB compressed). So unless I'm mistaken, we're talking about an increase of 24% or 17% for every reader who visits Wikipedia with an empty cache (hardly implausible), which seems a bit much to fix a timezone bug. Is there some way for this to load only after MediaViewer starts up? Suffusion of Yellow (talk) 17:33, 23 February 2020 (UTC)
Magog the Ogre, how is it now ?? —TheDJ (talk • contribs) 21:21, 16 March 2020 (UTC)

"Wikipedia:Monobook.js" listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Wikipedia:Monobook.js. Please participate in the redirect discussion if you wish to do so. — J947 [cont] 06:24, 14 April 2020 (UTC)

Extra jump after collapsing

In the mwCollapsibleSetup function, could we include an extra jump to the section header in window.location, if any? I think that might help with the issue of auto-collapsed sections moving the content on the page around after the user has already navigated to a heading. Enterprisey (talk!) 02:07, 16 May 2020 (UTC)

Enterprisey, I don’t understand your proposal. Can you give more details ? —TheDJ (talk • contribs) 09:29, 16 May 2020 (UTC)
TheDJ, sure. I frequently encounter this problem: I click on a link to a section header at the bottom of a page with auto-collapsing sections, such as a link to the final discussion on WP:AN. When the page initially loads, the section is in view. However, as the mwCollapsibleSetup function (and other code) runs, the page will jump around as elements are added and removed outside of the visible section of the page. I have added the following code to my common.js, which seems to help somewhat with the problem: 
mw.hook("wikipage.collapsibleContent").add(function() {
  var e = document.getElementById(decodeURIComponent(window.location.hash.substring(1)).replace(/ /g, "_"));
  if (e) e.scrollIntoView();
});
This just waits for mwCollapsibleSetup to finish and call the wikipage_collapsibleContent hook, and then jumps again to the section specified by window.location. I would like a similar fix to be implemented in mwCollapsibleSetup itself. Enterprisey (talk!) 20:16, 16 May 2020 (UTC)
At least for me auto collapsed sections appear collapsed as soon as the page is rendered so I don't see much jumping around. Galobtter (pingó mió) 00:09, 19 May 2020 (UTC)
Enterprisey, the downside to this would be that if you already started scrolling it might actually scroll you back. Also hash encoding... is a mess so this would have to be tested a bit cross browser. My overall advice is to simply avoid autocollapse. I really don't see why we 'need' autocollapse any longer honestly, and have long considered changing the .autocollapse selector to solely work on navboxes. —TheDJ (talk • contribs) 08:18, 19 May 2020 (UTC)
The bigger problem with collapse jumping these days is actually the centralnotice in my experience (which is JS loaded because of strongly cached html of anonymous usage of the site). —TheDJ (talk • contribs) 08:22, 19 May 2020 (UTC)
Another idea I just had is to autocollapse the boxes using CSS instead of JS (maybe with display: none in the autocollapse-collapsed class (or whatever it's called)), with appropriate use of <noscript> to avoid regressions in no-JS environments. Enterprisey (talk!) 22:29, 19 May 2020 (UTC)
Enterprisey, that essentially means moving the auto collapse logic into the wiki text parser, because you need to know the position and count of such items in order to apply the right css, which you can only modify by post processing the HTML dom, before it arrives with users. —TheDJ (talk • contribs) 06:41, 20 May 2020 (UTC)

Redirect_skin.js hack broken - remove?

Tracked in Phabricator
Task T71555
Declined

Looks like the Redirect_skin.js hack (c.f. mw:Snippets/Redirect skin.js) hack isn't working anymore, if someone wants to work on it I guess that's good - else we should just remove this section. — xaosflux Talk 13:49, 30 April 2020 (UTC)

N.B. phab:T71555 was declined to make this a mediawiki feature. — xaosflux Talk 14:35, 30 April 2020 (UTC)
Changing the two instances of titleParts.slice( -1 ) to titleParts[0] will make it work. But the original looks so wrong that I've no idea how it even worked all this while. SD0001 (talk) 15:12, 30 April 2020 (UTC)
I fixed it based on the mediawiki version. (Looks like ESanders (WMF) inadvertently broke it in https://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=951283949&oldid=951283353 as the === causes the slice to no longer be automatically converted to a string for the comparison, serving as an excellent example of why you shouldn't use ==.)
I agree that people shouldn't really be installing scripts in their skin.js but a lot of people already have and frequently people have no idea where their broken scripts are so the redirect is fairly helpful for that. Galobtter (pingó mió) 17:08, 30 April 2020 (UTC)
I wonder if this really needs to be in common.js tho; there are only 283 uses and the script only makes sense for the current user. Maybe narrow to only work if you are looking at your own skin.js and move to MediaWiki:Group-user.js? Galobtter (pingó mió) 17:39, 30 April 2020 (UTC)
@Galobtter: preferably, we should ditch this all together - but it is useless for logged out users, so there is no need to keep it in common.js. — xaosflux Talk 18:50, 30 April 2020 (UTC)
Moving from MediaWiki:Common.js to MediaWiki:Group-user.js is sensible, since it's not useful for logged-out users. I don't think we should ditch it altogether - when you're helping somebody with their custom .js or .css, it's useful for indicating where code may be placed, and you don't know which skin the other person is using. See for example this edit. --Redrose64 🌹 (talk) 21:35, 30 April 2020 (UTC)
i support moving this to group-user —TheDJ (talk • contribs) 09:21, 7 May 2020 (UTC)
I've gone and done this. ~ Amory (u • t • c) 17:24, 7 June 2020 (UTC)
@Xaosflux and Redrose64:, I made {{skin}} which uses the ability to load js with withJS to do this without code in common.js (the code is at MediaWiki:Redirect skin.js). I think we can replace past uses with {{skin}}, notify people on WP:VPT about the template, and remove the code from common.js. Galobtter (pingó mió) 03:57, 7 May 2020 (UTC)
The actual number of existing uses is 909 + 416. Also, the template makes the link coloured like an external link. SD0001 (talk) 15:59, 9 May 2020 (UTC)
I don't see how using a template helps. Currently anyone making use of this feature gets their custom css/js loaded on every page. Using a template means their custom css/js will only be loaded on pages that transclude the template. Moving it to MediaWiki:Group-user.js makes a lot more sense as it keeps the existing functionality. --Prh47bridge (talk) 06:29, 11 May 2020 (UTC)
This redirect skin code and the template is only about creating links to people's skin javascript through Special:MyPage/skin.js. The actual custom javascript/css is loaded regardless. Galobtter (pingó mió) 06:36, 11 May 2020 (UTC)
This. The only people that need to know about what is really going on are people providing technical support to other people that have no idea what is going on anyway. — xaosflux Talk 02:43, 16 May 2020 (UTC)
To build off this, the hack is also incredibly misleading if not used with Special:MyPage, since it loads whatever the current user's skin, not the userspace in question; Template:Skin should not recommend {{skin|js||Example}} (cc Galobtter). The template is an improvement, but not sure that archives need over-editing? ~ Amory (u • t • c) 17:36, 7 June 2020 (UTC)
Amorymeltzer, Removed from doc; I was just trying to document all the functionality but I agree 100% that it should not be used with a specific user name for the reasons you mentioned. I think we should generally avoid breaking old links thus my suggestion of replacing past uses with {{skin}}. But at the very least non-archive uses should either be fixed or removed (since common.js is the best place for scripts). Galobtter (pingó mió) 22:29, 7 June 2020 (UTC)
  • Why are we directing users to their skin-specific pages anyway? If they don't understand these pages well enough to find the right page for themselves, then common.js/common.css is almost always to correct place. The only exception would be loading a script that only works in a particular skin, in which case you need to know what skin they're using before you can help them. This whole setup seems like a relic from the days before the "common" pages. Suffusion of Yellow (talk) 02:50, 16 May 2020 (UTC)
    I agree that we should not be directing people to install stuff in their skin.js/css. I think there is some use in helping people who already have scripts installed in their skin.js/css to remove it, but we should definitely be moving towards directing people to install stuff in their common.js/css. Galobtter (pingó mió) 04:59, 16 May 2020 (UTC)

MonoBook currently has two "Wikidata item" links

MonoBook currently has two "Wikidata item" links (example) after phab:T254485 was fixed today. The second link is made by a temporary fix [2] which can now be reverted. This assumes todays MediaWiki changes aren't rolled back due to phab:T255179. PrimeHunter (talk) 20:25, 11 June 2020 (UTC)

I have added {{edit interface-protected}} to my post. PrimeHunter (talk) 09:31, 12 June 2020 (UTC)
 Done — Martin (MSGJ · talk) 10:53, 12 June 2020 (UTC)

BLP editintro broken on VE

The "addEditIntro" does not seem to work on VE. Hence particularly problematic with this part: addEditIntro( 'Template:BLP_editintro' ); which is the most common usage of editintros. It works if you open the link in a new tab, but if you just click it then it seems the parameter is stripped so it doesn't show up. A skim of the VE source suggests it may be due to the behaviour of when the ve link is clicked - it seems the VE JS may be ignoring the href on the link. ProcrastinatingReader (talk) 16:08, 5 June 2021 (UTC)

Probably phab:T56029. --Izno (talk) 22:24, 5 June 2021 (UTC)

Export to Wikimedia Commons button

Tracked in Phabricator
Task T232542

Some time ago an "Export to Wikimedia Commons" button was added to all files. While this is great for most content, we do have at least two categories of images which should not be exported to Commons, Category:All non-free media (edit | talk | history | links | watch | logs) and Category:Wikipedia files not suitable for Commons (edit | talk | history | links | watch | logs). With that in mind, I was going to write something to disable this for those categories, but in doing some research I discovered the Farsi Wikipedia already has something that does this in their Common.js: [3]. The relevant code is below, modified for our use. If additional categories are determined to be relevant to this, it's simple to add it to the filter array (line 3 below, which you can see they do in the Farsi version). 

// Hide the FileExporter portlet link if the file is not free content
$(function() {
  if ($('#ca-fileExporter').length == 1 & $(mw.config.get('wgCategories')).filter(['Wikipedia files not suitable for Commons','All non-free media']).length > 0) {
  	$('#ca-fileExporter').hide();
  }
});

I tested this in my userspace common.js, where it appeared to function correctly. Is there a better way to do this that I may have missed? If not, thoughts on this request? I'll be linking this discussion from WP:VPT. —Locke Cole • t • c 16:57, 23 May 2021 (UTC)

FileImporter looks like it's already configured at mw:Extension:FileImporter/Data/en.wikipedia to disallow importing files from Category:All non-free media (and Category:Wikipedia files not suitable for Commons could be added), but it'd make sense to hide the button when all it's (presumably, haven't tried it) going to do is give you an error message. – Rummskartoffel (talk • contribs) 17:27, 23 May 2021 (UTC)
Yeah, it gave me an error message on the few I tried (though I don't think I triggered the category block; the first few had deleted revisions which blocked it, and the others were incompatible with the license; I think the only way to trigger the category error would be to have a poorly tagged/licensed file). Agreed that the goal is to not present an option that ultimately won't work. —Locke Cole • t • c 17:47, 23 May 2021 (UTC)
Is there a bug filed for hiding the button? I don't think we should be adding Common.js hacks for things that should be straightforward and quickly fixed in the software. Legoktm (talk) 18:58, 23 May 2021 (UTC)
There doesn't appear to be. It seems the author is Addshore, but looking at the source for the extension the functionality appears to be fairly basic: check if the page exists, check that it's in the file namespace, and check that the user is not a "newbie". As you said, it should be simple to add a category check, and settings that each Wiki can adjust as needed (similar to how FileImporter has settings for each Wiki). —Locke Cole • t • c 19:36, 23 May 2021 (UTC)
Tracked in Phabricator
Task T283467
@Legoktm: I went ahead and opened a ticket though. —Locke Cole • t • c 19:54, 23 May 2021 (UTC)
A ticket is the way to go, have that extension have a blacklist - don't work around it with javascript hacks on only enwiki. — xaosflux Talk 02:03, 24 May 2021 (UTC)
Well, like I said at the start, this code is already live on the Farsi Wikipedia, but I agree, the extension modification would be preferred. =) —Locke Cole • t • c 06:29, 24 May 2021 (UTC)
Sounds like a good idea. I left a comment on the phab task asking how configuration might look like! ·addshore· talk to me! 17:34, 11 June 2021 (UTC)

Going to stop working around T18962

Plan on removing this section, no objection when posted to: Talk:Main_Page/Archive_203#Removing_redundant_"Complete_list"_link. Opening here for any comments. Ping to listed "section maintainer" @AzaToth: if there is any other special reason we need to keep doing this. — xaosflux Talk 15:22, 24 January 2022 (UTC)

I don't remember this code at all, but if it's not needed anymore, then go ahead remove it. →AzaToth 20:13, 24 January 2022 (UTC)
@AzaToth: it still functions in that it inserts that text there, but I think it is redundant to the link we have in the middle of the page - and it doesn't show with certain skins and in certain collapsed states of the language link now. — xaosflux Talk 14:44, 25 January 2022 (UTC)
 Done — xaosflux Talk 00:33, 27 January 2022 (UTC)
Followup edit at Common.css. Izno (talk) 00:51, 27 January 2022 (UTC)

Interface-protected edit request on 1 February 2022

Please change "The script itself is located on meta because it is used by many projects." to "The script itself is located on Meta because it is used by many projects." (bold emphasis mine). 🐶 EpicPupper (he/him | talk) 18:29, 1 February 2022 (UTC)

 Done-ish, used "the Meta-Wiki". — xaosflux Talk 19:05, 1 February 2022 (UTC)

supportsUrlLoad

If there is anyone sufficiently enterprising at present, I'd like to get withJS/withCSS removed from MediaWiki:Common.js, which is possible now (see WP:VPT#Tech News: 2022-05). I think the list of pages that must be updated is roughly this set (and with several more in other namespaces/page titles). Izno (talk) 20:00, 1 February 2022 (UTC)

I think the effort looks roughly something like:
  1. Make a gadget version of the withX scripts being loaded.
  2. Update MediaWiki:Gadgets-definition
    • I think probably these should be hidden gadgets so that users are not confused by their use
  3. Replace uses of withJS/CSS
  4. Repeat above steps per gadget until no uses remain
  5. Remove from Common.js
--Izno (talk) 20:02, 1 February 2022 (UTC)
@Izno: Sorry for my ignorance, but I couldn't find anything about this: is there a way for the withgadget URL param to load more than one gadget? Some of the examples I'm seeing (such as UTCLiveClock from Help:URL) are already gadgets, but have separate JS and CSS gadgets, that I'm guessing both need to be loaded. Previously, we could load them since withJS and withCSS are separate, but what about now? Looking at the code, it doesn't look like this is supported, but I might be missing something. Writ Keeper ⚇♔ 21:50, 1 February 2022 (UTC)
The gadget already declares its dependencies, so I guess nothing needs to change. We can try with this one and see what happens. :) Izno (talk) 22:08, 1 February 2022 (UTC)
Seems to work. :) Though on reflection, that page is just using it as an example of withgadget usage, so we probably could've picked *any* gadget. Oh, well, this works. Writ Keeper ⚇♔ 22:41, 1 February 2022 (UTC)
Right. Izno (talk) 23:16, 1 February 2022 (UTC)
So to follow that up, perhaps that specific page should point to one our needed cases of use rather than the particular gadget which isn't nominally for 'arbitrary' use. But maybe for down the road. Izno (talk) 23:48, 1 February 2022 (UTC)
Asked about multiple loads in phab:T29766. — xaosflux Talk 01:57, 2 February 2022 (UTC)
Gadgetizing all of those withX scripts, even the adhoc low-use ones like MediaWiki:Get-my-ip.js, is probably not a good idea. Whatever is saved from common.js would be at the expense of the startup module which carries the RL registration entries for all gadgets. It's more important to keep the startup module leaner as it blocks loading of all other javascript and has a maxage of just 5 minutes. In contrast, Mediawiki:Common.js is part of the 'site' module which is cached for as long as 30 days (edits invalidate the cache) and doesn't stand in the way of other JS being loaded. – SD0001 (talk) 17:52, 17 February 2022 (UTC)
The tradeoff is the better security and the fact that Common.js is not available on mobile (that's current MediaWiki:Mobile.js), so all those ad hoc scripts don't execute on the mobile domain. Which is 2/3 of our readership. I'd rather make the names available today, which would probably be in the realm of 100-200B of startup text or so (+- compression).
Never mind that we should not support two different methods of loading ad hoc things. That's just categorically worse.
If I get the list of names with AWB, here's the ones we need today:
That's a reasonable list that I don't expect to grow too much.
These are being provided with withJS on a handful of pages and I don't think I'm really a fan of that - people should log in to get access to full gadgets and user-specific items. But we can add those names too if we want. Izno (talk) 20:12, 17 February 2022 (UTC)
withJS not loading on mobile is a problem easily solved by adding the code to MediaWiki:Mobile.js.
... I don't expect to grow too much. More than half of those were created within the past year or so. I would expect it to grow. A lot of our workflows still use crappy wikitext preloads which should be replaced with intuitive JS forms. It doesn't scale to add a startup module entry for every workflow page script that would ever be created. After minification, the withJS code is 582 bytes; it can be reduced to 382 bytes if the mw.notify display is removed (which isn't really needed). The startup manifest has 108 gadgets which take 4904 bytes, which is ~45 bytes/gadget. That leaves us space for 382/45 ~ 9 withgadget modules before all savings are offset. Although gzip compression would be better for the manifest due to repetition of "ext.gadget", bytes in startup come at a bigger premium than bytes in common.js as I mentioned above. – SD0001 (talk) 03:55, 18 February 2022 (UTC)
Ok, still leaving the security enhancement. That's even if I thought the savings were the crucial point here.
Kinda' confused why you added support for the feature if you're (seemingly) going to oppose its use here. :) Izno (talk) 04:53, 18 February 2022 (UTC)

Interface-protected edit request on 23 August 2022

Please remove the definitions of importScript and importStyleSheet (along with the comments) from here. These overrides disable the functionality which as of this commit are fully supported and work on mobile as well.

The claim that these functions are deprecated on desktop was never true to begin with (see phab:T27845#8135189 and migration guide diff). The source code in legacy.wikibits.js explicitly stated otherwise. They were once marked as deprecated in 2015, only to be promptly undone a week later. – SD0001 (talk) 18:16, 23 August 2022 (UTC)

I'm planning to push back upstream on the discussion on that task and the diff in question. Izno (talk) 18:37, 23 August 2022 (UTC)
Just a minute before you posted, I updated the comment with additional gerrit links. The discussion regarding deprecation is phab:T95964 which indicates consensus for not deprecating. – SD0001 (talk) 18:41, 23 August 2022 (UTC)
See phab:T265132 which was declined also. I get the sense the left hand is decidedly not talking to the right hand. Izno (talk) 18:46, 23 August 2022 (UTC)
As for work on mobile as well I continue to see reports that X script doesn't work both on and offwiki and pointing out importScript almost always fixes it. Common.js does not load there, so whether these are in this page is irrelevant to that concern. It continues not to be loaded/delivered there. Izno (talk) 18:44, 23 August 2022 (UTC)
This edit request is for Mobile.js, not common.js. Verification for importScript working on mobile: visit https://en.m.wikipedia.org/wiki/Main_Page?safemode=1 (safemode disables Mobile.js which currently contains the overrides which disable importScript), and enter importScript in the console. – SD0001 (talk) 18:48, 23 August 2022 (UTC)
... so it is.  Done Izno (talk) 19:04, 23 August 2022 (UTC)

Oct 2022 Group-user.js live testing

@Krinkle: how long does this "temporary" script you've loaded in to MediaWiki:Group-user.js need to be running? Can you provide more information about why this is needed? — xaosflux Talk 00:39, 13 October 2022 (UTC)

@Xaosflux: I'll remove it in 2-3 days. It's visualised in Grafana to better understand window width habits, which I noticed being discussed at Wikipedia:Requests for comment/Deployment of Vector (2022). --Krinkle (talk) 23:47, 13 October 2022 (UTC)
Thank you for the update. — xaosflux Talk 23:52, 13 October 2022 (UTC)

Odd autocollapse behaviour on preview

Navboxes are autocollapsed by default so they should display expanded when they are alone on a page. While editing {{UN Charter}} I noticed it's expanded on the rendered page but collapsed in preview. I reduced it to the example in User:PrimeHunter/Odd autocollapse behaviour: 

{{Navbox
|title = Example
|below = {{Portal-inline|Politics}}
}}

Special:ExpandTemplates says {{Portal-inline|Politics}} produces:

[[File:A coloured voting box.svg|border|alt=icon|class=noviewer|32x28px]] [[Portal:Politics|Politics portal]]

If I preview with that code instead then it's expanded on preview: 

{{Navbox
|title = Example
|below = [[File:A coloured voting box.svg|border|alt=icon|class=noviewer|32x28px]] [[Portal:Politics|Politics portal]]
}}

I don't know what causes the difference but can it be fixed? It's a little annoying to have to click "show" when previewing a navbox edit, and you may think the autocollapse is not working. Tested in Firefox and Microsoft Edge, both logged in (Vector legacy) and out. PrimeHunter (talk) 16:05, 9 January 2023 (UTC)

@TheDJ as the last one to look in on autocollapse. Izno (talk) 19:24, 9 January 2023 (UTC)
I tested it on this very page, with live preview (Show preview without reloading the page) enabled to ease debugging. The wikipage.collapsibleContent hook (which is used by autocollapse) is called six (!) times per preview:
  • twice with empty jQuery objects;
  • once with a jQuery object containing a div.mw-editfooter-list (“templates used in the preview” list);
  • once again with an empty jQuery object;
  • once with a jQuery object containing a div.preview-limit-report-wrapper (parser limit report table);
  • and finally once with a jQuery object containing two navboxes (the navbox on the top of the page, with its child navbox).
I can imagine that without the live preview, some or all of these are collapsed in one hook firing. If some of the interface collapibles (like the template list or the constraint report) make their way to the same jQuery object that contains the content collapsibles, they make our code think there are more collapsibles on the page than there really are – but only during preview, since these parts of the interface are not present on page view. As autocollapse is a ubiquitous feature present on many wikis, IMO this bug should be fixed in MediaWiki by not mixing content and interface rather than in the Common.js of each and every wiki that provides autocollapse. – Tacsipacsi (talk) 10:13, 10 January 2023 (UTC)
Yes, that would cause the issue. However, autocollapse is our choice to have. I don't agree that it's reasonable for core to work around it. Izno (talk) 18:17, 10 January 2023 (UTC)
Conceptually it may be cleaner to fix it locally (as the documentation doesn’t promise to separate content and interface, so it was the local code which made a wrong assumption); in practice, however, this very same code is used in dozens of wikis, while a general autocollapse search returns almost 300 wikis, which means that a local fix would mean fixing it locally in dozens if not hundreds of wikis. Since the documentation doesn’t promise either that it’ll mix content and interface, fixing it in core wouldn’t break any contracts. —Tacsipacsi (talk) 02:44, 11 January 2023 (UTC)
Most of those 300 uses are for wikis using old collapsing rather than the collapsing based on mw-collapsible, so aren't affected today; it's just the other 60. I don't think core is going to support differentiating sufficiently for this issue, but you can try upstreaming a task.
That it hasn't been noticed until now leads me to believe that either no-one else will and it's Fine enough as-is, or they'll notice at some point later and come looking to see if a change has been made here. (Which it will have been.) Izno (talk) 03:17, 11 January 2023 (UTC)

Should we keep the T10912 hack

This hack is so that if you use "undo" and don't include any original text in the edit summary it is treated like other edit "empty" type of edit summaries and will warn a user if they have opted-in to the preference to warn them if they don't use an edit summary. Notably, this is not the default so is not used for IP editors. phab:T10912 was closed, effectively rejecting making that exempt on the back end - that this should be the expected behavior. If this is still desired, we may migrate it to MediaWiki:Group-user.js for logged-in users only (since it has no impact for readers and IP editors). Another option would be to reject the phab closure and reopen it. Thoughts? — xaosflux Talk 21:20, 15 February 2023 (UTC)

I would personally be annoyed if we were to remove this :).
  1. I have no issue with moving to group-user.js in some interim - that probably should happen regardless to start.
  2. I would also have no issue with attempting to reopen the task, though that usually faces a high bar. (And I think it is somewhat difficult to argue with jdforrester's comment regarding the default behavior, so if we were to go that route, we would need to have more than just "I disagree with closing this resolved". I think consistency is more or less a good one but consistent with what?)
  3. I would also not mind if this were moved to a gadget that people opted into, then the cost is paid only by those who want it. We would naturally need to advertise it. It would make it more clear how many people actually expect this behavior to have an opted-in gadget rather than loading by default.
Izno (talk) 21:42, 15 February 2023 (UTC)
If we move to a gadget, we can update the label at MediaWiki:Tog-forceeditsummary to tell people about it, so if they opt in to one, they would opt in to the other (this is for new users not currently using it though). — xaosflux Talk 00:51, 16 February 2023 (UTC)
Migrated the autosummary hack to MediaWiki:Group-user.js. — xaosflux Talk 21:13, 21 February 2023 (UTC)

Interface-protected edit request on 29 April 2023

Please change the block 

				if ( $toggle.parent()[ 0 ].style.color ) {
					$toggle.find( 'a' ).css( 'color', 'inherit' );
				}

to 

				if ( $toggle.parent()[ 0 ].style.color ) {
					$toggle.css( 'color', 'inherit' );
					$toggle.find( '.mw-collapsible-text' ).css( 'color', 'inherit' );
				}

This fixes the styling of the brackets and of the show/hide text to once again match the text color of the parent content (if different from the default). This is necessary as the HTML structure of the collapsible elements has been modified after phab:T333357. —TheDJ (talk • contribs) 12:56, 29 April 2023 (UTC)

 Done Izno (talk) 15:12, 29 April 2023 (UTC)
@Izno: You added one line, but TheDJ asked you to replace one line with two that are different. --Redrose64 🌹 (talk) 22:35, 29 April 2023 (UTC)
 Done — xaosflux Talk 00:08, 30 April 2023 (UTC)

Replacing magic editintros with editnotices and Lua

I think editintros can be replaced by a simple change to Template:Editnotice to check if the page is in the category and display the notice. I've mocked this up at User:Galobtter/Category editnotice test - hit edit there to see the automatically generated editnotice. The code used is at Module:Sandbox/Galobtter. This isn't perfect since Lua can't technically detect if a page is in a category or not, but since Category:Living people should be present in the wikitext of all living people, this works for that case. The disambiguation case is trickier since the category emitted is done by a template, but it is probably doable.

Currently the implementation of editintros is extremely brittle and does not work for the visual editor (phab:T56029) or the mobile view. This would fix that. Galobtter (talk) 06:11, 30 April 2023 (UTC)

This would be a lot easier if someone were to implement phab:T50175. —TheDJ (talk • contribs) 08:47, 1 May 2023 (UTC)
Yeah that'd be really useful in general. Galobtter (talk) 09:05, 1 May 2023 (UTC)
The match would be much more accurate if the templates were expanded: 
	local content = mw.getCurrentFrame():expandTemplate{ title = mw.title.getCurrentTitle() }
– this would match all categories specified either directly on the page, or within a template, except for those that are within extension tags like <ref>. On the other hand, your pattern is a too naïve and matches things it shouldn’t, like plain, unlinked Category:X appearing on the page (which is unlikely in articles, though, but would be a problem, should this module be used in discussion namespaces). It also matches commented-out categories (which may very well be a concern in articles – if it’s unclear whether someone died, the category may be kept temporarily commented out), but that would be automatically solved by using expandTemplate, as that removes HTML comments. —Tacsipacsi (talk) 23:23, 1 May 2023 (UTC)
Ooh I forgot about expandTemplate. Yeah it definitely matches more than it should, that's just a prototype to demonstrate that it can be done. Galobtter (talk) 23:28, 1 May 2023 (UTC)
I have updated code at Module:Category editnotice. I think that should work great. Galobtter (talk) 00:10, 2 May 2023 (UTC)
Nevermind, it's too slow right now, which I was worried about. I just tried it with a large article and it choked the edit. Galobtter (talk) 00:17, 2 May 2023 (UTC)
Okay, it works quickly and is fine without the expandtemplates which makes sense. I still wonder if there any performance implications but not sure how to check that. Galobtter (talk) 00:24, 2 May 2023 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_22&oldid=1217404909"