Jump to content

MediaWiki talk:Gadget-popups.js/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3

Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at bugzilla:63725. Regards, Nemo 09:45, 10 April 2014 (UTC)

Edit request

Change var soxredToolUrl='//tools.wmflabs.org/xtools/pcount/index.php?name=$1&lang=$2&wiki=$3'; to var soxredToolUrl='//tools.wmflabs.org/supercount/index.php?user=$1&project=$2.$3'; JV Smithy (talk) 15:40, 21 April 2014 (UTC)

Done — Mr. Stradivarius ♪ talk ♪ 10:03, 22 April 2014 (UTC)

Deprecated functions

Resolved

The lines 

hookEvent('load', setupPopups);
addOnloadHook(autoEdit);

causes the following warnings:

  • Use of "hookEvent" is deprecated. Use jQuery instead.
  • Use of "addOnloadHook" is deprecated. Use jQuery instead.

Could someone fix them? Helder.wiki 15:26, 19 May 2014 (UTC)

Protected edit request on 16 June 2014

Please replace: 

var h='<hr><tt>' + download.data.entify().split('\\n').join('<br>\\n') + '</tt>';

With: 

var h='<hr /><span style="font-family: monospace;">' + download.data.entify().split('\\n').join('<br />\\n') + '</span>';

To remove deprecated <tt> element and replace them with the equivelent css enriched span. — {{U|Technical 13}} (e • t • c) 20:24, 16 June 2014 (UTC)

What's wrong with using <code>...</code>? That's what we've been doing elsewhere, as advised at http://www.w3.org/TR/html5/obsolete.html#tt --Redrose64 (talk) 22:23, 16 June 2014 (UTC)
It's not a one-to-one replacement, as <code>...</code> tags force a white background as well as a monospace font. So it depends what the <tt>...</tt> tags were being used for. In this case it looks like it's used for previewing template code, so switching to code tags is probably ok. Technical 13, what do you think? — Mr. Stradivarius ♪ talk ♪ 03:20, 17 June 2014 (UTC)
I avoided requesting this switched to code tags because the navigational popups have a yellow background. — {{U|Technical 13}} (e • t • c) 03:49, 17 June 2014 (UTC)
Done That's a good point. — Mr. Stradivarius ♪ talk ♪ 04:51, 17 June 2014 (UTC)
It's possible to use <code style="background: inherit;">...</code>: Popup Code Popup That way, the semantic use of the code element - to represent a fragment of computer code - is indicated. The span element just changes the appearance, it does not convey meaning. --Redrose64 (talk) 10:33, 17 June 2014 (UTC)

Not working on user contributions

The script suddenly stopped working on Special:Contributions. Can someone look into that? Thanks. —howcheng {chat} 17:03, 6 August 2014 (UTC)

It turned out there was a bug in User:Ais523/topcontrib.js. Since that editor has since retired, I rewrote his script in jQuery and fixed the bug. —howcheng {chat} 02:29, 10 August 2014 (UTC)

Bug popupModifier

This option is annoying and not really working. If tested all mod keys (except of meta) and none of them are really usable. I get the problem which was already mentioned here : 2009 also my browser get always freezed after some time (FF and Chrome on Win 7). So I propose the stroke this option out or mark it as beta, or improve the code. Thanks for the tool, best regards → User: Perhelion  08:36, 7 August 2014 (UTC)

Show source text at modules

Hi! At templates, this script shows the source text of the page. It would be even more useful at modules, because now it shows usually just local p={}. Can somebody add it to the script (I think it's around the 550. line)? Thanks, --Tacsipacsi (talk) 11:05, 28 September 2014 (UTC)

Not done: @Tacsipacsi: Sorry, but really we need the code to be ready and working before we can enact edit requests like this one, and also not many (any?) users who are good with JavaScript patrol these edit requests. If you need help with the coding, WP:VPT is the best place to ask. Best regards — Mr. Stradivarius ♪ talk ♪ 09:05, 30 September 2014 (UTC)
Resolved

Hello. I was wondering, why the popups gadget does'nt display Special:Diff links. Special:Diff is the preferred method to link diff links since February 2014. --Ptolusque (talk) 22:55, 28 September 2014 (UTC)

I've deactivated the edit request, as edit requests aren't meant for requesting code features (see Wikipedia:Edit requests). If you have the code needed to make this work, though, feel free to reactivate the request. — Mr. Stradivarius ♪ talk ♪ 23:38, 30 September 2014 (UTC)
Understood. I was asked in the German Wikipedia to put that feature request. The Template:Diff in the German Wikipedia seems to be corrupted. Therefore its recommended to use Special:Diff. But Special:Diff doesn't comply with Gadget-popups.js. First of all, I'll discuss this issue in the German Wikipedia. If required, then I'll try to code a template addition. --Ptolusque (talk) 00:26, 1 October 2014 (UTC)
@Ptolusque: You can also try posting at the technical village pump for assistance, and we can try asking the two most active maintainers of the tool, TheDJ and Amalthea. — Mr. Stradivarius ♪ talk ♪ 00:36, 1 October 2014 (UTC)
@Ptolusque: Should be working now: Special:Diff/613903522, Special:Diff/613903522/next, Special:Diff/613903522/prev, Special:Diff/613903522/cur. Amalthea 12:13, 1 October 2014 (UTC)
Great, thank you! --Leyo 21:45, 1 October 2014 (UTC)
Excellent, Amalthea! Thanks. --Ptolusque (talk) 23:58, 1 October 2014 (UTC)

First of all, thanks for this improvement! I've been wanting this since I started using popups! I just have one question: Why does it work on Special:Diff/620573180/620804084 as a link, but selected in the source, it shows a cache key? —PC-XT+ 04:22, 14 October 2014 (UTC)

Most recent edit popup broken

This edit by Amalthea breaks the popup for the "most recent edit" action. The popup always shows the most recent edit to Main Page because getWiki() creates a URL with the title parameter set to the empty string. In this case, since oldid=cur, MediaWiki has no idea that we want a particular page's last revision, so it chooses Main Page by default. It seems like the old version of that function would've always been correct: even if given a numeric oldid for a page other than article, MediaWiki would always prefer oldid. – Minh Nguyễn 💬 04:52, 28 October 2014 (UTC)

Amalthea, please apply this fix. It fixes the "most recent edit" links and their popups while preserving the behavior of Special:Diff links. Thank you. – Minh Nguyễn 💬 10:27, 15 November 2014 (UTC)

 Done. Sorry this took so long. — Martin (MSGJ · talk) 15:56, 20 November 2014 (UTC)

Update not to reference magnify-clip.png directly

Popups references the magnify-clip.png file directly using its path, which is silly because it doesn't even need to. The file is going to be removed soon. See bugzilla:69277 and bugzilla:69678#c10.

Proposed patch:

Remove these lines Replace with these lines 
        images_fallback: '//upload.wikimedia.org/wikipedia/commons/',
        magnify_icon: 'skins/common/images/magnify-clip.png'

        images_fallback: '//upload.wikimedia.org/wikipedia/commons/'

                o += f("<div style='width:?px;'>?", 2+width*1, make_image(filename, caption, width)) +
                    f("<div class='thumbcaption'><div class='magnify' style='float:right'><a href='?' class='internal' title='Enlarge'><img src='?'></a></div>?</div>",
                        htmlescape_attr(Insta.conf.paths.articles + Insta.conf.locale.image + ':' + filename),
                        Insta.conf.paths.magnify_icon,
                        parse_inline_nowiki(caption)
                    )

                o += f("<div style='width:?px;'>?", 2+width*1, make_image(filename, caption, width)) +
                    f("<div class='thumbcaption'><div class='magnify' style='float:right'><a href='?' title='Enlarge'></a></div>?</div>",
                        htmlescape_attr(Insta.conf.paths.articles + Insta.conf.locale.image + ':' + filename),
                        parse_inline_nowiki(caption)
                    )

Matma Rex talk 20:37, 10 November 2014 (UTC)

Well it worked since 2003, so i'm not sure if that is 'silly', but it is outdated.  ;) —TheDJ (talk • contribs) 13:53, 11 November 2014 (UTC)
 Done hopefully. For future info, a sandbox diff of the required change would be appreciated! — Martin (MSGJ · talk) 16:06, 20 November 2014 (UTC)

ResourceLoader

I noticed that this gadget doesn't use ResourceLoader, so it isn't getting minified automatically. As a test, I tried enabling ResourceLoader for the Vietnamese Wiktionary's copy of NavPop and quickly ran into a couple of JavaScript errors that broke the gadget. The errors would be fixed by these changes. These changes break support for IE 4–6, which should be perfectly fine because MediaWiki no longer loads JavaScript in IE 7 and below as of MediaWiki 1.24wmf21 (deployed to this wiki in September 2014). Would an administrator please apply these three changes and enable ResourceLoader for this gadget at MediaWiki:Gadgets-definition? Thanks! – Minh Nguyễn 💬 11:12, 15 November 2014 (UTC)

Please detail the exact change you need to MediaWiki:Gadgets-definition, because I assume these two edits need toi be made simultaneously — Martin (MSGJ · talk) 16:08, 20 November 2014 (UTC)
Yes, the three edits linked above (633924853, 633925432, and 633986818), as well as the following change to MediaWiki:Gadgets-definition, are all required for this script to work with ResourceLoader:
−
* Navigation_popups|popups.js|navpop.css
+
* Navigation_popups[ResourceLoader]|popups.js|navpop.css
 – Minh Nguyễn 💬 18:07, 21 November 2014 (UTC)
Sorry I've lost the diff due to the request above. — Martin (MSGJ · talk) 20:32, 24 November 2014 (UTC)
User:Mxn/popups.js is up to date with 634705181. – Minh Nguyễn 💬 07:07, 25 November 2014 (UTC)
 Done. Sorry for the delay. I only responded to this because no one else did! — Martin (MSGJ · talk) 10:37, 25 November 2014 (UTC)
Note: MSGJ — Mxn: Please see Wikipedia_talk:Tools/Navigation_popups#Did_popups_just_stop_working.3F in which this change seems to have broken the tool. — {{U|Technical 13}} (e • t • c) 15:48, 25 November 2014 (UTC)
arrow Reverted for now — Martin (MSGJ · talk) 17:24, 25 November 2014 (UTC)
Wow, sorry for the inconvenience! I tested these changes by deploying them at the Vietnamese Wiktionary, and so far there have been no complaints. (That script is identical except for a some code at the end that localizes various strings.) – Minh Nguyễn 💬 20:39, 25 November 2014 (UTC)

Legacy JavaScript

Hello! This script has been detected as using deprecated parameters that need to be replaced with the updated version. Examples include addOnloadHook( ... ) needs to be replaced with $( function() { ... } ); all wgGlobalVariables need to be properly gotten with mw.config.get( 'wgGlobalVariable' ); and addPortletLink needs to be called with mw.util.addPortletLink. Please see MW:ResourceLoader/Legacy JavaScript for details. Thank you. — {{U|Technical 13}} (e • t • c) 20:24, 19 January 2015 (UTC)

@Technical 13: Could you draft the updated version? --Leyo 00:17, 14 April 2015 (UTC)

JSON parsing

This edit makes the module depend on RL module 'JSON'. —TheDJ (talk • contribs) 20:02, 5 July 2015 (UTC)

as far as i know, JSON.(stringify|parse) is a JS inbuilt thingy. peace - קיפודנחש (aka kipod) (talk) 16:18, 6 July 2015 (UTC)
In more modern browsers, yes. In older ones not. In vague ones not. It's better to make sure, actually, it's probably already running because of other dependencies, just not declared. —TheDJ (talk • contribs) 18:54, 6 July 2015 (UTC)
what i was trying to say is, ttbomk there is no RL module named JSON (or "mediawiki.JSON"). you are probably correct that it would have been more polite to verify that "JSON" is not null, and even better, that typeof(JSON.parse)==='function' (and maybe fallback to the previous call to eval()), but i don't think the first statement of this section is correct. peace - קיפודנחש (aka kipod) (talk) 19:28, 7 July 2015 (UTC)
Right, the module is called json, not JSON —TheDJ (talk • contribs) 11:23, 12 August 2015 (UTC)

Protected edit request on 25 August 2015

Please deploy the following version of navpopups: source diff. This fixes an error when trying to preview images that are hosted on Commons. —TheDJ (talk • contribs) 21:37, 25 August 2015 (UTC) —TheDJ (talk • contribs) 21:37, 25 August 2015 (UTC)

Done — Mr. Stradivarius ♪ talk ♪ 23:43, 27 August 2015 (UTC)

Gadget-popups.js support for global user accounts via meta global.js and / or gadject selection in meta preferences

https://en.wikipedia.org/?curid=14574453#global_user_accounts links here
re: m:MediaWiki:Gadget-popups.js and MediaWiki:Gadget-popups.css (and MediaWiki:Gadget-navpop.css)
att: / cc: @Amalthea, @Edokter, @JV Smithy, @Krenair, @Krinkle, @Legoktm, @Mr. Stradivarius, @MSGJ, @Nakon, @Salix alba, @Schnark, @TheDJ, @Waldir

Dear friends; I contact you because you have been editing the actual gadget JavaScript code or have been involved in security and other issues about the gadget.
m:MediaWiki:Gadget-popups.js (and the empty m:MediaWiki:Gadget-popups.css) allow user to select the gadget functionality by selecting the gadget in m:special:Preferences#mw-prefsection-gadgets. Unfortunatelly it will not be active at other projects via the (unified?) global user account.
https://meta.wikimedia.org/?oldid=15121460# created by simple copy and paste allowed te generation of some links but did not provide the full functionality known from w:en:, m: etc. Can you please help to get a working version running at meta supporting global accounts? Thanks in advance for all your efforts. Best regards Gangleri (talk) 07:30, 14 December 2015 (UTC)

Hi! I added code to load MediaWiki:Gadget-navpop.css at https://meta.wikimedia.org/?oldid=15130039# and was verry pleased about the work the gadget code does. In general I select the local language in preferences at every wiki where I sign in. I made a brief tour at wikt:is:, w:is:, w:tn:, testwiki: and w:arc and have find it a good start with Gadget-popups.js despite the fact that not all links have provided popup functionality. In addition the Right To Left (RTL) project in Aramaic was showing some minor directionality issues (the size in bytes is rightmost while the corresponding unit is leftmost). That is all for now. Please do not hesitate to write abouut your experience and list the issues you have detected.
Best regards user:Gangleri also aka בײַ מיר ביסטו שיין (talk) 19:29, 14 December 2015 (UTC)
kudos. one small comment to בײַ מיר ביסטו שיין: even though the title _is_ "size in bytes", the actual value navpop shows (unlike history tab) is "size in characters". peace - קיפודנחש (aka kipod) (talk) 21:58, 14 December 2015 (UTC)
Any more news here? I18n (talk) 18:45, 25 December 2015 (UTC)

@Gangleri: Any user can effectively make this gadget a global gadget for themself by adding a call to the file from their m:Special:mypage/global.js page. 

		//popups
		mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript');

the only difficulty that I have is that it fails for me with an @import of the navpop.css page to that pair. So I cheated and manually copied the whole navpop.css file to my m:Special:mypage/global.css, which works for me, though doesn't update with fixes and improvements.

As I have typed this response I have asked again about that issue to see if we can find a solution. If you need a hand to set up your stuff globally, please ping me at meta m:User talk:Billinghurst — billinghurst sDrewth 06:33, 22 February 2016 (UTC)

short, shorter and shortest url especially for pages with utf-8 titles, whitespaces, RTL characters etc.

revID: 1118466413 diff · PAGEID: 51052996 links here · W3C CSS Validator – ⧼code-rev-purge-link⧽ ↺
https://en.wikipedia.org/?curid=14574453#shortest_url links here

Hi! Since earliest WMF times wikipedians contributing to non-Latin language versions expressed their wish to have the option to use shorter urls then available through UTF-8 url encoding. The shortest variant for WMF type page urls known to me is

https:{{SERVER}}/?curid={{PAGEID}}#

I think it would be a significant improvement to add PAGEID to the available popups. PAGEID is preserved during page moves but (to my knowledge) not after undelete and for shure not after reimports. These two situalions occur quite seldom so PAGEID would be a good approach.

notes: a) The "diff"-link is intended for an exploit of diff which allows to analyse the difference between two different but same style wiki pages as in https://test.wikipedia.org/?diff=254163&oldid=254616 . It would make much more sense to create and use a further LUA module which could extract the / all "mw.config.set" values from an arbitrary wiki page and use
https://test.wikipedia.org/?diff={{REVISIONID}}&oldid={{#mw.config.set: wgCurRevisionId | template talk:4x4 type square/T065}}
Please contact me at the #kavehoyz freenode IRC channel to discuss this plan.
b) I experimented a lot with portable wiki code between all WMF projects and used interwiki links to the local wiki as in w:en:most-perfect magic square. I am not sure if the gadget code will handle this link as a link to the local wiki. It does not.
c) Local links in general and "shortest links" in particular should be handeled as normal local wiki links. Example https://en.wikipedia.org/?curid=706451# for the same page as mentioned at b).
Will be happy for any comment. Best regards Gangleri also aka בײַ מיר ביסטו שיין (talk) 01:36, 15 December 2015 (UTC) / 02:57, 15 December 2015 (UTC)
Any news here? I18n (talk) 18:44, 25 December 2015 (UTC) / I18n (talk) 06:44, 26 December 2015 (UTC)

Protected edit request on 15 April 2016

Please add the extendedconfirmed group to the list of groups that are not included in the navpop when you hover of a username. This can be done by adding 

case 'extendedconfirmed':

to the list underneath 

switch (user.groups[i]) {

Thanks Majora (talk) 01:52, 15 April 2016 (UTC)

 Done — xaosflux Talk 02:20, 15 April 2016 (UTC)

Protected edit request on 14 April 2016

I implemented this feature request. The popup that appears when hovering over a user now contains a small gender symbol in the style of userinfo.js.

Line 4328 should be changed to: 

url += 'list=users&usprop=blockinfo|groups|editcount|registration|gender&ususers=' + usernameart + "&meta=globaluserinfo&guiprop=groups|unattached&guiuser="+ usernameart;

And the following code should be inserted between lines 4631 and 4632: 

if( user.gender ) {
	switch( user.gender ) {
		case "male": ret.push( popupString( "\u2642" ) ); break;
		case "female": ret.push( popupString( "\u2640" ) ); break;
	}
}

APerson (talk!) 02:19, 14 April 2016 (UTC)

xaosflux, maybe you'd want to take a look at this? APerson (talk!) 03:11, 15 April 2016 (UTC)
APerson was this tested somewhere with someone who had set, then unset their gender (i.e. is it now a nul value, or is it some other value that this doesn't have a default to?) — xaosflux Talk 03:15, 15 April 2016 (UTC)
xaosflux, yes, I have tested this with people who haven't specified their genders. In that case, no gender symbol gets displayed. APerson (talk!) 03:19, 15 April 2016 (UTC)
APerson Did you test with someone who did specify, and then later unspecified? — xaosflux Talk 03:34, 15 April 2016 (UTC)
xaosflux, I switched my gender to unspecified, verified that the symbol didn't appear, then switched it back to male. Do you think I should ask someone on IRC to do so? APerson (talk!) 03:36, 15 April 2016 (UTC)
Just asked someone on IRC to specify and then unspecify their gender. The patch worked with no issues. APerson (talk!) 03:39, 15 April 2016 (UTC)
APerson I want to make sure I don't mess up your line numbers bringing this live, I just synced it to: User talk:APerson/jssandbox; can you make your go-live edit there and ping me back here please? — xaosflux Talk 03:44, 15 April 2016 (UTC)
xaosflux  Done. APerson (talk!) 03:50, 15 April 2016 (UTC)
 Done — xaosflux Talk 03:52, 15 April 2016 (UTC)
APerson - !! this IS the page you wanted edited correct - I think your edit request was pointing at the .css page.?? — xaosflux Talk 03:58, 15 April 2016 (UTC)
This is the correct page, yeah. APerson (talk!) 04:19, 15 April 2016 (UTC)

Protected edit request on 14 April 2016 (2)

I implemented this feature request. A "send thanks" option is now available on the action menu for diffs. A version of the code file with this feature implemented is at User:APerson/sandbox/Gadget-popups-with-thanks.js (diff from current code). Thanks! APerson (talk!) 22:14, 14 April 2016 (UTC)

Done — Martin (MSGJ · talk) 14:34, 18 April 2016 (UTC)

Protected edit request on 19 April 2016

Per this discussion, I've added an option, popupShowGender, to specify whether a gender symbol should be shown on the user popup. This diff shows the change necessary to add the new option, and this version of the script has the option implemented. APerson (talk!) 03:09, 19 April 2016 (UTC)

Done — Martin (MSGJ · talk) 08:01, 19 April 2016 (UTC)

Proposal to host on GitHub

As discussed here (permalink), this gadget should be hosted on GitHub and updates should be made using an upload script, Twinkle-style. I think this would encourage new development because edit requests are a pretty cumbersome method of requesting changes for a script like this. It would also make things like automated testing of pull requests possible. Pinging recent gadget contributors (MSGJ—Xaosflux—Legoktm—Krenair—Mr. Stradivarius—Edokter—Majora). APerson (talk!) 16:28, 19 April 2016 (UTC)

Would prefer Gerrit. --Krenair (talk • contribs) 16:48, 19 April 2016 (UTC)
So who would make the uploads here? — xaosflux Talk 20:35, 19 April 2016 (UTC)
Would edit requests still be submitted and discussed here? Or where else? -- Michael Bednarek (talk) 20:58, 19 April 2016 (UTC)
Pull requests would take the place of edit requests for changes to the code, as that's what GitHub is designed for. We could get an adminbot running to deploy from the repository, and until it starts running, we could just ping friendly admins on IRC. Gerrit would be great too. APerson (talk!) 01:42, 20 April 2016 (UTC)
I'm not sure that reducing the number of eyeballs for this widely, and far from stable, feature would be desirable. -- Michael Bednarek (talk) 02:25, 20 April 2016 (UTC)
I agree that it's important to have as many people as possible looking at suggested changes to the gadget. However, I think GitHub, Gerrit, Phab, or whatever platform we eventually use will definitely make it possible for users to track new proposed changes. APerson (talk!) 16:38, 20 April 2016 (UTC)

Protected edit request on 24 May 2016

Per this discussion, I've added a display of the last time a user has edited on the bottom of the user info pane. The updated version of the code can be found here; the diff that shows this patch being applied onto the current version of the script is here. APerson (talk!) 02:45, 24 May 2016 (UTC)

Done — Martin (MSGJ · talk) 09:19, 24 May 2016 (UTC)

FYI

Watchers of this page may be interested in WT:NAVPOP#Can we put bugs on Phabricator?, a discussion about hosting bugs (and feature requests) on Phabricator. Enterprisey (talk!) (formerly APerson) 02:16, 8 June 2016 (UTC)

Protected edit request on 11 June 2016

I started running various style checkers on the code in hopes of getting it to the point where I can start writing testcases further down the road. With this patch, I've fixed a few of the worst offenders from a stylistic perspective (e.g. I changed code of the form a && b(); to if(a) { b(); }). The updated code can be found at this version of User:Enterprisey/popups.js. Enterprisey (talk!) (formerly APerson) 04:28, 11 June 2016 (UTC)

I created a user editable js-style sandbox here: MediaWiki talk:Gadget-popups.js/sandbox and synced the main and User:Enterprisey's changes, as seen in this diff: Special:Diff/724796635. — xaosflux Talk 15:22, 11 June 2016 (UTC)
xaosflux, do you maybe have any comments on whether this change could be merged? Enterprisey (talk!) (formerly APerson) 01:04, 14 June 2016 (UTC)
 Done @Enterprisey: merged in. — xaosflux Talk 02:09, 14 June 2016 (UTC)
Cool, thanks! Enterprisey (talk!) (formerly APerson) 02:11, 14 June 2016 (UTC)

LOCKED and HIDDEN are wrong

See Wikipedia:Village pump (technical)#Locked, Hidden. PrimeHunter (talk) 22:37, 15 June 2016 (UTC)

Fixed by reverting the change in the above section. Legoktm (talk) 22:47, 15 June 2016 (UTC)

Protected edit request on 9 July 2016

Please copy the sandbox over onto the main gadget - I undid some changes I made to legacy protocols that actually broke certain menus, such as the "popups" one. Enterprisey (talk!) (formerly APerson) 03:52, 9 July 2016 (UTC)

 Done Legoktm (talk) 03:53, 9 July 2016 (UTC)

Protected edit request on 14 June 2016

Having fixed a few of the style issues in my previous edit request, I decided to fix them all in my current one. The proposed version of the code is the first one to pass a Javascript linter, which should make future improvements to the code immensely easier. (Instead of going back through the code to see what they missed, contributors can simply run the linter to point out their errors.)

The updated code can be found at this version of popups.js. I've updated the sandbox version with the proposed code, and this diff from the sandbox's history shows me applying the proposed change.

Yes, I've tested this. However, due to the extensive nature of this change (it fixes up lines spread throughout the code), I'm going to try and solicit a few current popups users to test out the code. Enterprisey (talk!) (formerly APerson) 04:12, 14 June 2016 (UTC)

Done — Martin (MSGJ · talk) 21:47, 15 June 2016 (UTC)
Sorry, I had to revert this, it was causing "LOCKED, HIDDEN" to show up for every user, and I don't really have time to review all of the other changes...
>>> a = {};
Object { }
>>> a.hidden != null;
false
>>> a.hidden !== null;
true
Legoktm (talk) 22:46, 15 June 2016 (UTC)
Legoktm and MSGJ, I fixed it by using a combination of !== undefined and simple truthiness tests. (Example: when we're testing exec() output, simple truthiness is much better than != null for clarity reasons.) Updated version has been uploaded to the sandbox. Enterprisey (talk!) (formerly APerson) 04:09, 18 June 2016 (UTC)
Legoktm, would you mind taking another look? Enterprisey (talk!) (formerly APerson) 00:43, 9 July 2016 (UTC)
And the revised code is back in the gadget; looking good for now. Enterprisey (talk!) (formerly APerson) 04:18, 10 July 2016 (UTC)

Protected edit request on 11 July 2016

The code currently at MediaWiki talk:Gadget-popups.js/sandbox (for posterity, this revision) should be copied over onto the main gadget. I fixed this bug by undoing some code cleanup changes I made. Enterprisey (talk!) (formerly APerson) 04:02, 11 July 2016 (UTC)

Done — Mr. Stradivarius ♪ talk ♪ 05:24, 11 July 2016 (UTC)

Protected edit request on 12 July 2016

Fixed T138902. Please copy the version in the sandbox (for posterity, this revision) over to the main gadget. Enterprisey (talk!) (formerly APerson) 02:03, 12 July 2016 (UTC) Enterprisey (talk!) (formerly APerson) 02:03, 12 July 2016 (UTC)

 Done — xaosflux Talk 02:14, 12 July 2016 (UTC)

Article <> talk page links not working

I don't know when it happened – not very long ago – but when using Popups by hovering on a link, choosing actions|view article or actions|talk page from its menu no longer shows the linked page: it either shows shows the same page that one is hovering on (on article talk pages), or else it tries to display page User:, Talk: or User talk: and fails. I don't suppose many people use this feature, but I do, and it used to work!  —SMALLJIM  09:06, 10 July 2016 (UTC)

Good catch. Working on a fix. Enterprisey (talk!) (formerly APerson) 20:53, 10 July 2016 (UTC)
Note to self: Title.prototype.toTalkPage, line 2419. (Fix will be made in the next few hours.) Enterprisey (talk!) (formerly APerson) 21:05, 10 July 2016 (UTC)
Edit request filed. Enterprisey (talk!) (formerly APerson) 04:03, 11 July 2016 (UTC)
Thanks! It's working this morning.  —SMALLJIM  08:19, 12 July 2016 (UTC)

max-age and ctype

I suggest replacing on line 2753 action=raw&ctype=text/css&maxage=0&smaxage=0 with plain action=raw. The reason is that these options no longer actually add any purpose. In 2016, this is probably hurting more than it used to fix in 2006 :) —TheDJ (talk • contribs) 09:06, 1 September 2016 (UTC)

Done — Martin (MSGJ · talk) 21:29, 1 September 2016 (UTC)

a.navpopup can be undefined

On line 3773 the script checks if a.navpopup is null, but does not check if it is undefined. This sometimes causes the error: in Firefox: TypeError: a.navpopup is undefined, in Chrome: Uncaught TypeError: Cannot read property 'isVisible' of undefined index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:3774. That sometimes happens to me when I point to links while the page is still loading. This error does not prevent the script from working afterwards. Please add the check for undefined. --V111P (talk) 03:04, 19 September 2016 (UTC)

@V111P: Please specify the exact change you are requesting. The easiest way is to copy the page to your userspace, make the changes, and then provide a link to that userpage. Regards — Martin (MSGJ · talk) 11:28, 19 September 2016 (UTC)
Sorry, @MSGJ: Line 3773 currently is if (a.navpopup === null) return; I request that it becomes: if (a.navpopup === null || typeof a.navpopup === 'undefined') return; The line numbers are visible when editing the code (with the Code editor), or you can search for a.navpopup === null and you'll find it. Thanks. --V111P (talk) 12:05, 19 September 2016 (UTC)
Okay, hopefully done — Martin (MSGJ · talk) 13:01, 19 September 2016 (UTC)

mw.util is sometimes undefined

There were some changes to MediaWiki recently and now when using Chrome every once in a while I'll get an error from this script in the console. To prevent this, the dependency on mw.util should be declared before using a function from it, as described here: [1] The error message in the console is: Uncaught TypeError: Cannot read property 'getParamValue' of undefined index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:1093 This error does not prevent the script from working afterwards.--V111P (talk) 03:06, 19 September 2016 (UTC)

@V111P: mediawiki.util is given as a dependency..(See MediaWiki:Gadgets-definition). Are you using this as a Gadget, or are you importing it a different way ? —TheDJ (talk • contribs) 07:33, 19 September 2016 (UTC)
I see. Yes I am using it in my global.js, so I have to do that there I guess. Thanks. --V111P (talk) 11:32, 19 September 2016 (UTC)
Well we could add some 'double' certainty into the script, but it will be slower to load it that way... Maybe we should instead check the loading state, and throw a warning to console if the libs are not loaded... that might save a few people. —TheDJ (talk • contribs) 13:55, 19 September 2016 (UTC)
Why would it slow down loading? AFAIK, mw.loader checks first if the given dependency is already loaded and doesn’t load it twice. And many users load Popups via importScript (or its mw.loader equivalent)—global, common, skin.js’s, foreign wikis’ gadgets or even site scripts. I think their (our) number exceeds the number of users who use the enwiki gadget, so in average it’s worth make sure every dependency is loaded. Once it’s loaded dynamically, we can load it only when it’s used, so in this example, mw.util will be loaded if user actually attempts to use the auto-edit feature. --Tacsipacsi (talk) 15:01, 3 October 2016 (UTC)
Not slower per se, but slower potentially. This is because you would bypass the bundled delivery and have to make a new request (this is one of many reasons that gadgets are 'better' than userscripts). Especially in browsers without full HTTP 2.0 support loading many userscripts will add up and consequently slow you down. —TheDJ (talk • contribs) 20:02, 3 October 2016 (UTC)
Then probably we could create a page which makes sure everything is loaded; users and wikis which don’t want to pay attention on regular updates can include that, and enwiki gadget and other users for whom performance is more important than convenience can include the original version. --Tacsipacsi (talk) 20:11, 3 October 2016 (UTC)

Protected edit request on 16 November 2016

"LOCKED" and "HIDDEN" seem to be broken, again. This change fixes these issues, once and for all. (I also fixed the Category:Foo thing from the previous section, because I was only modifying comments and why not.) The updated code can be found at the sandbox. Enterprisey (talk!) 22:24, 16 November 2016 (UTC)

 Done — Martin (MSGJ · talk) 12:16, 17 November 2016 (UTC)

Category:Foo

Category:Foo redirects to Category:X1. Please can this page be adjusted to remove it from the category redirect. Timrollpickering (talk) 14:08, 20 October 2016 (UTC)

MediaWiki:Gadget-popups.js is currently in Category:Foo (the category is only displayed on preview). It also transcludes Template:', ' and is in many WhatLinksHere like Special:WhatLinksHere/User:Lupin/foo3. This is all because js pages are evaluated as wikitext when link tables are made (the result is ignored when the page itself is rendered). The normal solution is to add // <!-- at the top and // --> at the bottom. This will normally make the whole page a wikitext comment to prevent it from being processed as wikitext and affect link tables. However, in this case there are already many --> which would terminate the comment. <nowiki>...</nowiki> has the same problem: Existing </nowiki> would terminate it. We could use <includeonly>...</includeonly> since the page is not transcluded as wikitext anywhere. Or we could just comment out the category code and ignore the WhatLinksHere entries. PrimeHunter (talk) 10:20, 21 October 2016 (UTC)
 Fixed, in both the main gadget and the two userspace copies I had of the gadget. Enterprisey (talk!) 01:30, 18 November 2016 (UTC)

Fixing redirects - does it work?

I posted the question at Wikipedia talk:Tools/Navigation popups#Fixing redirects - does it work? on 21 November 2016. As after a week there is still no answer forthcoming, I'm cross-posting here in hopes of receiving a response. Thanks, wbm1058 (talk) 14:49, 28 November 2016 (UTC)

Oops, didn't see the post. Responded there. Enterprisey (talk!) 02:36, 29 November 2016 (UTC)

Protected edit request on 19 December 2016

Apparently, for a while now the notification bubbles that pop up when a watch or unwatch happens have been empty. I fixed that. Updated code in this sandbox version. Enterprisey (talk!) 01:18, 19 December 2016 (UTC)

Done — Martin (MSGJ · talk) 09:24, 19 December 2016 (UTC)
Eh, this seems.. undesirable. This does it's own interpretation of a Mediawiki message, where we have perfectly good libraries to do so (so that we don't get XSS vulnerabilities everywhere). See mw:Manual:Messages_API#Using_an_API_query_from_JavaScript. Just make sure the relevant modules are loaded, and you guard against old versions of wiki potentially not having them. Also, you might as well use jQuery promises instead of callbacks. —TheDJ (talk • contribs) 09:35, 19 December 2016 (UTC)
Facepalm Facepalm I can't believe I didn't notice that particular corner of the API. Edit request filed. Enterprisey (talk!) 07:57, 23 December 2016 (UTC)

Protected edit request on 23 December 2016

I used a pretty bad and hacky method of displaying the watchlist message in my previous patch; following TheDJ's helpful suggestion, I've replaced it with a much better (and thoroughly tested) one. Updated version in this revision of the sandbox. Enterprisey (talk!) 07:58, 23 December 2016 (UTC); better link added 08:39, 23 December 2016 (UTC)

Disabling this for now, while I rework it. —TheDJ (talk • contribs) 10:57, 23 December 2016 (UTC)
This seems better to me: https://test2.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&oldid=303149 We could go even a bit further, by depending on the watch module of the api, but older versions of MediaWiki might not have that yet, and since this script is used far outside of English Wikipedia, that seems unwise. —TheDJ (talk • contribs) 12:01, 23 December 2016 (UTC)
Looks better to me as well. Obviously I still don't know about quite a bit of that section of the API :) Enterprisey (talk!) 22:51, 23 December 2016 (UTC)
OK, reenabling this request. Please deploy this version here. —TheDJ (talk • contribs) 12:26, 29 December 2016 (UTC)
 Done — Mr. Stradivarius ♪ talk ♪ 02:16, 31 December 2016 (UTC)

Global renamers?

Don't know what was changed recently @TheDJ and Enterprisey: but global renamers are no longer showing up in the "groups" area at the bottom of popups. It used to and all the other global groups still show up fine. Would either of you be able to look into this? Thanks! --Majora (talk) 03:37, 28 December 2016 (UTC)
Majora "Global renamer" is not a "global group" it is a meta: local group (that has global access). — xaosflux Talk 03:42, 28 December 2016 (UTC)
@Xaosflux: I could have sworn it used to show up on popups. Could definitely be mistaken though. Has happen before (a few times today even ). --Majora (talk) 03:43, 28 December 2016 (UTC)
Going to look into that as soon as I can. Enterprisey (talk!) 04:14, 30 December 2016 (UTC)
Apparently this isn't visible from PleaseStand's script, either, so adding this will be a bit tricky, if it ever happens. Enterprisey (talk!) 03:47, 31 December 2016 (UTC)

Feature request for files: have metadata available in pop-up

This script is used universally, and there would be value to have the following added/available to the popup display

  • where a file is linked, that the metadata of the file is available, ie. dimensions of file, the size of the file, and if a multipage file eg.djvu, the number of pages of the file.

Now, not everyone is going to want that data, so maybe it is a configurable option. Thanks if someone technically competent can manage that. — billinghurst sDrewth 06:01, 22 February 2016 (UTC)

Already tracked in T139872. Enterprisey (talk!) 04:07, 31 December 2016 (UTC)

Protected edit request on 23 December 2016 (2)

I resolved T149236, which came from this discussion. Code in this sandbox revision (which happens to be the current one). Enterprisey (talk!) 08:38, 23 December 2016 (UTC)

Disabled this for now, because of the issue one thread up. —TheDJ (talk • contribs) 12:04, 23 December 2016 (UTC)
Issue in the previous thread was resolved. Updated code is in this sandbox revision (diff with main). Reactivated request. Enterprisey (talk!) 03:57, 31 December 2016 (UTC)
 Done — Mr. Stradivarius ♪ talk ♪ 14:35, 1 January 2017 (UTC)
I have raised an issue possibly with this change here: Wikipedia talk:Tools/Navigation popups#Width problem with history view.--JohnBlackburnewordsdeeds 19:03, 1 January 2017 (UTC)

Protected edit request on 7 January 2017

Issues with the latest update were raised in this discussion, so I changed the user contribs view so that it shows (diff | hist) links instead of the old (cur | last) links, in line with the watchlist and pretty much every other interface page.

Updated code, as usual, is in the sandbox (permalink, diff with main). Enterprisey (talk!) 00:43, 7 January 2017 (UTC)

Done — Mr. Stradivarius ♪ talk ♪ 01:57, 7 January 2017 (UTC)

Protected edit request on 28 June 2017

Right now, hovering over users without any edits results in no data being shown, because the user info parsing code had a bug. I fixed it, so a bit of data is now displayed (creation date, blocked/locked status, user rights if any). Here's the diff showing the code changes, and the most recent code is in this sandbox revision. The change was originally suggested in this WT:POPUPS thread (permalink). Enterprisey (talk!) 19:32, 28 June 2017 (UTC)

 Done —TheDJ (talk • contribs) 20:26, 28 June 2017 (UTC)
That was fast! Thanks! Enterprisey (talk!) 20:33, 28 June 2017 (UTC)

Protected edit request on 23 July 2017

Can you enable the translation of the 'thank' function? Thank you.--Sakretsu (talk) 21:46, 23 July 2017 (UTC)

 Coding... Enterprisey (talk!) 04:03, 25 July 2017 (UTC)
Alright, done. The change the responding admin needs to make is the addition of a single line, shown in this diff, which should allow other wikis to change the value associated with the the send thanks key. Enterprisey (talk!) 04:06, 25 July 2017 (UTC)
Yes, it works. Problem solved, thank you from it.wiki :-) --Sakretsu (talk) 10:57, 25 July 2017 (UTC)
No problem! Going to re-enable this request real fast, because I think the enwiki version's code also needs to be changed. (This way, other language wikis can continue to use it as a template.) Enterprisey (talk!) 18:24, 25 July 2017 (UTC)

Done —TheDJ (talk • contribs) 21:39, 27 July 2017 (UTC)

guard against including twice

This Gadget behaces really weird (as in: some parts work normally, others (i.e. positioning of the popup) fail without any notice) if it’s included twice, i.e. if someone has the "manual installation" in their global.js and at the same time has a local gadget which includes this one enabled. I’m assuming it wouldn’t be difficult to check whether this script has been executed already and skip the second pass? --nenntmichruhigip (Diskussion) 20:39, 27 July 2017 (UTC)

@Nenntmichruhigip: I've fixed that for this copy, but I can't fix all the many local copies on other wiki's unfortunately :( —TheDJ (talk • contribs) 09:52, 28 July 2017 (UTC)
@TheDJ: The local gadgets are usually including this one (using the "manual installation"), so there’s no need to change something there :-) I’ve only checked a few wikis though, but I hope the others are smart enough to not use an outdated copy. If they do, it’s their fault anyway. Thank you for the quick fix! ---nenntmichruhigip (Diskussion) 20:03, 28 July 2017 (UTC)

Hello, good afternoon. It would be great if through the popup i'd be able to view a review of the article in other languages the same way i view in the original language, or at least be able to jump to another language through the popup. can someone add a link to other languages inside the popup that would enable it? melo kol haaretz kevodi (talk) 10:00, 13 January 2017 (UTC)

User:theDJ? melo kol haaretz kevodi (talk) 10:21, 7 April 2017 (UTC)
@TheDJ and Enterprisey: is this possible? melo kol haaretz kevodi (talk) 00:08, 31 July 2017 (UTC)

Bug for languages that include regex special characters in Namespace names

Hello,

We have a small bug for languages that have namespaces that include regex special characters, such as parentheses. In Portuguese, for example, the user namespace is "Usuário(a)", this breaks the calls that depend on the contribs regex, as they expect the targeted user to be the third match and with this it becomes the fourth. To solve this, we need to escape these characters. I made a naive approach over in a subpage of mine, it does seem to work with no problems. (pinging TheDJ) Chico Venancio (talk) 21:47, 16 October 2017 (UTC)

@Chicocvenancio: that will probably work, but i'd prefer this. Can you check if that works for you as well ? —TheDJ (talk • contribs) 14:40, 18 October 2017 (UTC)
@TheDJ: Yep, of course that works, and is better. I tried to look inside Popups code for a regex escape function but forgot to check mediawiki javascript modules. Thanks for the prompt attention to this. Chico Venancio (talk) 14:51, 18 October 2017 (UTC)
That still doesn't fix all problems btw, as it doesn't detect the gender specific variants of such links. For that, instead of looking at wgFormattedNamespaces, it should instead use the nsRe function, and escape possibly escape those instead... —TheDJ (talk • contribs) 15:09, 18 October 2017 (UTC)
@Chicocvenancio: How about this ? Does that trigger popups for links of all four forms ? (User, Usario, Usaria and Usario(a) ? —TheDJ (talk • contribs) 15:19, 18 October 2017 (UTC)
It fixes every link generated inside popups itself, in my experience. For onwiki links we also need to use either the canonical english page term and the localized term ("contributions" and "contribuições", for example). But this fix already improves my case use significantly. Chico Venancio (talk) 15:22, 18 October 2017 (UTC)
@TheDJ: Like this, for example. Some strings would have to be added for other pages as well, and I'm not sure this approach fails gracefully if there is no localized string registred. Chico Venancio (talk) 15:36, 18 October 2017 (UTC)
Yes, i'm aware of that problem. Lets do one step at a time indeed. I'm currently trying to weed down popups to somewhat more manageable proportions, in hopes of making it slightly easier to keep it alive.. —TheDJ (talk • contribs) 15:42, 18 October 2017 (UTC)
Deployed. —TheDJ (talk • contribs) 17:13, 18 October 2017 (UTC)
TheDJ, sorry, I think I tested a different version when I wrote that this version was ok. I blame caches.
nsRe(pg.nsUserId) does in fact solve the problem by escaping "Usuário\(a\)", but it adds another html escaped version that is not regex escaped "Usu%C3%A1rio%5C(a%5C)", so we get to the same error of creating an extra capturing group again. Chico Venancio (talk) 19:44, 19 October 2017 (UTC)
@Chicocvenancio: better now ? —TheDJ (talk • contribs) 20:11, 19 October 2017 (UTC)
Yep, thanks! Chico Venancio (talk) 20:13, 19 October 2017 (UTC)

Problem with minor edits

I noticed all edits in popup histories and contribs are being indiscriminately marked as minor. This appears to fix it. Burninthruthesky (talk) 16:26, 26 October 2017 (UTC)

Done by TheDJ — Martin (MSGJ · talk) 21:16, 26 October 2017 (UTC)

popupRedlinkAutoClick

There are currently popupRedirAutoClick and popupDabsAutoClick option that can change the button which is pressed when fixing redirects or dabs. But there is no such option for removing red links. I have modified a script to fix this by adding the popupRedlinkAutoClick option: User:Alexei Kopylov/sandbox/Gadget-popups.js (diff). Please copy it over onto the main gadget. Alexei Kopylov (talk) 08:11, 6 April 2018 (UTC)

P.S. Currently when we remove dab link, popupDabsAutoClick does not work (it is always clicked wpDiff). My next change fixes this (diff). Alexei Kopylov (talk) 09:58, 6 April 2018 (UTC)

@Alexei Kopylov: thank you for your contribution. Would you be so kind to also update the documentation for the options ? —TheDJ (talk • contribs) 11:26, 6 April 2018 (UTC)
Thanks! I've updated the documentation. Alexei Kopylov (talk) 15:57, 6 April 2018 (UTC)

Summary data and user info

I have a few suggestion:

  1. Show information about a user (like "204 edits since: 2006-09-21, last edit on 2018-04-07") before page preview, next to the page statistics (like "16.5kB, 70 wikiLinks, 14 images, 3 categories, 4 days 23 hours old"). Because now you need sometimes to scroll down to see this information.
  2. Make popupSummaryData govern whether this user info will be shown as well as the page statistics (i.e. if popupSummaryData=false then do not show user info).
  3. If simplePopups=true and popupSummaryData=true then show page statistics (including user info), but popupSummaryData should be set to false by default if simplePopups=true (so the default behavior for users who sets simplePopups=true will not change).

What do you think? Alexei Kopylov (talk) 16:48, 7 April 2018 (UTC)

Two bug fixes

I have fixed two bugs: the popup window did not close in some cases when you have set popupModifier. (One was triggered by pressing wrong modifier on the link, and then pressing right modifier outside the link; and another when the link was hided, e.g. when pressing 'edit' link on wikidata page). Please copy my fix to the main file. Alexei Kopylov (talk) 17:39, 12 April 2018 (UTC)

 Done — Martin (MSGJ · talk) 06:35, 16 April 2018 (UTC)
made a minor change to that, as non-strict comparisons are to be avoided. Thx for the bug fixes Alexei ! —TheDJ (talk • contribs) 08:57, 16 April 2018 (UTC)

Show user info when popupUserInfo=true and simplePopup=true

I have change the behavior of the script when an user set simplePopup = true, but also set popupUserInfo=true or popupCategoryMembers=true then it shows the correspondent info anyway. In this way one can enable showing short info, but disable showing full preview (diff). This also includes a small bug fix (the popup preview button did not always hide when clicked, e.g. when the target page was empty). Alexei Kopylov (talk) 02:24, 19 April 2018 (UTC)

 Done — Martin (MSGJ · talk) 06:33, 19 April 2018 (UTC)

Accept a version

I have implemented a feature that allow a accept a version (marked it as patrolled). It adds a "mark patrolled" link if

  • you are viewing a difference between the last patrolled (a.k.a. stable) version and a newer version
  • you have the 'review' right
  • popupReview option is set to true

This link is added in a section popupMiscTools that was not used. I'm planning to add more links in this section (like thank, revert, block) in the feature.

For now popupReview is false by default (so the default behavior should not change), but eventually we should set it true by default.

Please copy over: [4].

Some questions:

  • There was a menu item "marked patrolled" in the code, but it did not work (at least in Russian, German and English wikis). Should I just clean up the code or is it somehow still used in some wikis?
  • Probably instead of "marked patrolled" it should be called "accept change", I'm not sure what terminology is used in English Wikipedia, I just used an old popupString.

Alexei Kopylov (talk) 21:11, 27 April 2018 (UTC)

 Done I copied your most recent version of that sandbox, rather than the version you linked to. I hope that is correct. I am unable to answer your questions I'm afraid. Perhaps User:TheDJ would be able to comment? — Martin (MSGJ · talk) 07:08, 17 May 2018 (UTC)
@Alexei Kopylov: that patrolled link is for Help:Patrolled edit. We only have that on New pages. Not even sure if it would work there. It's all ancient ;) —TheDJ (talk • contribs) 09:23, 17 May 2018 (UTC)
@TheDJ: the old patrolled link never showed up unless you explicitly put "rcid" in the link like this: https://en.wikipedia.org/wiki/Christopher_Silber?rcid=42. However I've never seen such links in the wild. But maybe in some wikipedias they are still used? So I'm not sure what would be the best action: to remove old functionality or to leave both of them (in this case we need to have separate names for old and new functionalities ("make patrolled" and "make reviewed"?). Alexei Kopylov (talk) 22:50, 17 May 2018 (UTC)
@MSGJ: I've replaced it with the version Alexei Kopylov linked to. The only difference was Alexei had turned on some debug logging options by default, presumably for testing. It's not something everyone needs to have on by default, it just litters the console. ~ Amory (u • t • c) 15:43, 17 May 2018 (UTC)

Protected edit request on 30 August 2018

Minor documentation issue: in the lede it says Firefox: hold down the Shift key while clicking Reload; "Shift" should be "Control" and it could also mention the Ctrl+F5 shortcut. Here's the suggested whole paragraph, reformatted a bit with nifty button graphics:

Note: After saving, you have to bypass your browser's cache to see the changes:
  • Internet Explorer: hold down Ctrl while clicking Refresh/reload (the refresh/reload toolbar icon)
  • Firefox: hold down Ctrl while clicking Refresh/reload or press Ctrl+F5 or Ctrl+⇧ Shift+R
  • Google Chrome or Safari: simply click Refresh/reload
  • Others: See Bypass your cache

—[AlanM1(talk)]— 14:12, 30 August 2018 (UTC)

@AlanM1: do you just want the word changed, or are you trying to implement all these graphics, etc? For the later we will need you to specify the exact "from" and "to" (or insert 'this' at line 'x') as if you were making the edit yourself. If you just want to "discuss" an improvement, the edit request template should be deactivated. How would you like to proceed? — xaosflux Talk 15:24, 30 August 2018 (UTC)
@AlanM1: The current version is certainly wrong—it’s quite odd, but Ctrl+Reload button doesn’t do this, only Shift+Reload and Ctrl+F5. —Tacsipacsi (talk) 15:35, 30 August 2018 (UTC)
Withdrawn for now. I've confirmed Ctrl+F5 in Firefox 61, as well as Shift+Reload. Ctrl+Reload opens the page in a new tab instead, caching unknown. In Edge, it's Ctrl+F5 and Ctrl+Reload. I tried IE11 and got confusing results that require more research than I can do at the moment. Sorry for the waste of time :( —[AlanM1(talk)]— 17:01, 30 August 2018 (UTC)

Proposed change: Shortmenus style "popups" menu-item into shorter icon

Copying from Wikipedia talk:Tools/Navigation popups.

TLDR: Because it is rarely needed and gets in the way and increases the chance of linewrap, [I suggest we] change the current text "popups" into just a star/cog (UTF or image, whatever works), in the "menus" and "shortmenus" style-configurations. See current text screenshots at /Structure_examples#Menus.

Mockup: https://imgur.com/a/pW3n2XF

Thoughts? Quiddity (talk) 08:58, 16 November 2018 (UTC)

Sounds like a good idea to me. Enterprisey (talk!) 01:03, 17 November 2018 (UTC)
Ok. I propose using either ⚙ (unicode for 'gear' since 2005), or just a plain ascii '*' if there are any concerns about the former. IIUC that string is only used in the 'menus' and 'shortmenus' structures (i've updated all the screenshots to confirm), and
therefor we just need [someone] to change 'popups' to '⚙' in line 6897 of MediaWiki:Gadget-popups.js. Ping TheDJ for sanity-check and implementation. :) Quiddity (talk) 22:45, 24 November 2018 (UTC)
End of copy. (emphasis added)
Ping @MSGJ and Xaosflux: per helpfulness further above and insight to this area. :) Quiddity (talk) 02:15, 12 January 2019 (UTC)
Replied at Wikipedia talk:Tools/Navigation popups#Proposed change: Shortmenus style "popups" menu-item into shorter icon ~ Amory (u • t • c) 15:48, 15 January 2019 (UTC)
 Done changed to "*" - anyone rever me if anything broke, and discussion for future improvements is always welcome. — xaosflux Talk 02:37, 30 January 2019 (UTC)
eraser Undone - this results in a control that renders so small that it is not distinguishable from the separator dots. — xaosflux Talk 03:24, 30 January 2019 (UTC)

Minor "popupDabRegexp" edit to match portuguese disambiguation template

Hi all, on the pt: wiki I had to slightly edit the popupDabRegexp value to make the popupFixDabs feature works.
Instead of (\{\{\s*disambig(... I put (\{\{\s*d[ie]sambig(... to match the Desambiguação template.
I changed it in my personal Common.js and it works.

Thanks. --L0ll0 (talk) 09:12, 29 January 2019 (UTC)

Thanks for the note, we shouldn't have that spelling here - so I'm not seeing any local adjustment needed. — xaosflux Talk 12:33, 29 January 2019 (UTC)
L0ll0, the defaults only support the English Wikipedia. If you need settings for a local version, they should be made in the gadget of the local version of the gadget. An example of this can be found in the dutch wikipedia for instance. —TheDJ (talk • contribs) 12:33, 29 January 2019 (UTC)
I'm sorry, I didn't know it. Thank you all to point me to the right place. --L0ll0 (talk) 08:45, 30 January 2019 (UTC)

Unwanted popups in Charinsert menu

I've been seeing popups from the links in the Charinsert box below the textbox. When I put my mouse over them, they show a popup with the current page (because they have href="") rather than the tooltip for the edit menu ("Click on the character or tag to insert it into the edit window").

This has happened several user pages of mine and is happening here, though it didn't happen on MediaWiki talk:Edittools. I edited a section of Climate and it didn't happen, but then edited the whole article and it happened.

It might have to do with relative execution time of the scripts, because the bug only happens with the menu that is loaded first. When I switch to another menu, the links don't have popups. The Charinsert script inserts new HTML when a menu is selected. Maybe the Charinsert links are only popup-ified if the Charinsert script happens to insert them before the popups script is executed.

I was playing around with a modification to Charinsert, but even with that turned off the problem is still here. — Eru·tuon 09:54, 2 February 2019 (UTC)

Erutuon, fixed —TheDJ (talk • contribs) 15:55, 2 February 2019 (UTC)
@TheDJ: Thanks! Nice to know it's an easy fix if it happens anywhere else. — Eru·tuon 20:16, 2 February 2019 (UTC)

The September update by Amorymeltzer

Please remember that the script is exported to a huge variety of third-party projects. Not all of them can update the site engine in a timely manner. And some changes can break the script work for them. Ivan-r (talk) 17:46, 13 October 2019 (UTC)

@Ivan-r: we don't "export to" anywhere. If an external web site is importing raw code from us, they may want to consider using a versioning system (such as pointing to a specific revision here, forking, etc) if they don't want to be on our "live" copy. — xaosflux Talk 21:00, 13 October 2019 (UTC)
Since I was named here, I just wanted to note that I've indeed seen this. I think it's a worthy consideration, but xaosflux has hit the nail on the head. ~ Amory (u • t • c) 21:41, 13 October 2019 (UTC)

Minor tweak for partial blocks

With partial blocks rolling out, the popup of BLOCKED for someone partially blocked seems wrong. What would folks think about changing it to read Partially blocked instead? I've done a quick test at User:Amorymeltzer/pb-popup.js, see the diff from the current gadget. I could also see removing bold in favor of italics or just plain text as well. ~ Amory (u • t • c) 23:03, 13 January 2020 (UTC)

@Amorymeltzer: how about something like:
(Blocks) for partially blocked users in contrast to
Blocks maybe? scratch that, we use emph for global groups. — xaosflux Talk 23:59, 13 January 2020 (UTC)
BLOCKED for siteblocked users
? — xaosflux Talk 23:58, 13 January 2020 (UTC)
Do you mean "(Blocked)"? I'm not sure it conveys the meaning. Maybe "(editing restricted)" or something? ~ Amory (u • t • c) 01:13, 14 January 2020 (UTC)
It isn't necessarily an "editing" block so not that. Howabout Blocked or SITE-BLOCKED ? — xaosflux Talk 01:16, 14 January 2020 (UTC)
Or maybe BLOCKED vs Has blocks? — xaosflux Talk 01:16, 14 January 2020 (UTC)
Ooh, I like "has blocks." Works for Has rangeblocks as well. ~ Amory (u • t • c) 02:34, 14 January 2020 (UTC)
{{+2}} — xaosflux Talk 02:38, 14 January 2020 (UTC)
With the above tweaks, that'd look like this I suppose? Will hold off adding it for a bit pending other input, but I imagine folks won't really notice until a change is made. ~ Amory (u • t • c) 10:50, 14 January 2020 (UTC)

I put this in place last night FWIW. ~ Amory (u • t • c) 18:08, 24 January 2020 (UTC)

Timestamp localization wrong

Tracked in Phabricator
Task T223002

With daylight saving time upon us, Local timestamps wrong during Daylight Saving Time (DST; Summer Time) is about to become prominent again.

In short, storing the minute offset associated with the user's selected timezone, and using it to localize timestamps that may occur during times when the offset is different, is the wrong approach. If the offset is stored during winter time, localization of timestamps that occur during summer time will be wrong and vice-versa. —[AlanM1(talk)]— 00:04, 8 March 2020 (UTC)

Help in SqWiki

Hello! :)

Lately the navigation popups gadget has stopped working for us in SqWiki. I know the code of gadgets is localized (I'm an I-Admin) but it stopped working spontaneously and even though I made sure we had the same code as the one here, it still doesn't work. No one has changed the common.js/css pages. First I thought it was only me because of some changes I may had made at my preferences that didn't go well with the gadget but yesterday I got emailed by another admin and he was having the same problem. Strangely enough for both of us the gadget works well in EnWiki. Has anything changed lately? Can anyone take a look at our project, maybe point out the problem? Any help in general is appreciated. :) - Klein Muçi (talk) 06:42, 7 April 2020 (UTC)

@Klein Muçi: the sqwiki implementation is not using the same dependencies we are, notably user.options is missing in w:sq:MediaWiki:Gadgets-definition (compare to our MediaWiki:Gadgets-definition). — xaosflux Talk 13:14, 7 April 2020 (UTC)
@Xaosflux: hello, friend! :) What you said was true. We are now using the same dependencies but it's still not working unfortunately. :/ - Klein Muçi (talk) 14:11, 7 April 2020 (UTC)
@Klein Muçi: It works for me. Probably you tried an outdated version from your browser cache, which didn’t contain your changes. (By the way, it would be great if sq:MediaWiki:gadgets-prefstext contained a link to sq:Speciale:Gadgets, just like its enwiki counterpart in the upper right corner.) —Tacsipacsi (talk) 00:00, 9 April 2020 (UTC)
@Tacsipacsi: Unfortunately, it doesn't. :/ I even tried emptying the cache but still nothing. @Βατο: Try emptying the cache and tell us if it works for you after. - Klein Muçi (talk) 07:56, 9 April 2020 (UTC)
Hello, it doesn't work for me either. – Βατο (talk) 08:43, 9 April 2020 (UTC)

Interface-protected edit request on 22 May 2020

Hello. Popups is a gadget on bnwiki. For redirect, bnwiki uses #পুনর্নির্দেশ. since পুনর্নির্দেশ is not defined here, this gadget doesn't follow redirect on bnwiki. To fix it, Please replace 

		'bg':  [ r, 'пренасочване', 'виж' ],
		'bs':  [ r, 'Preusmjeri', 'preusmjeri', 'PREUSMJERI' ],

with 

		'bg':  [ r, 'пренасочване', 'виж' ],
		'bn':  [ R, 'পুনর্নির্দেশ' ],
		'bs':  [ r, 'Preusmjeri', 'preusmjeri', 'PREUSMJERI' ],

আফতাবুজ্জামান (talk) 18:08, 22 May 2020 (UTC)

 Question: there are some invisible characters in the text you are requesting. Please confirm if these are needed or update your request. — Martin (MSGJ · talk) 22:12, 23 May 2020 (UTC)
@MSGJ: পুনর্নির্দেশ should match with this (first one). It's matching correctly. Please go ahead. --আফতাবুজ্জামান (talk) 13:18, 24 May 2020 (UTC)
 Done. Hope that works okay? — Martin (MSGJ · talk) 20:34, 24 May 2020 (UTC)

Interface-protected edit request on 11 June 2020

Hello, could someone please add 'nds-nl': [ R, 'DEURVERWIEZING', 'DUURVERWIEZING' ], to the setRedirs() function? bdijkstra (talk) 16:45, 11 June 2020 (UTC)

Bdijkstra, can you clarify what this change is for? —CYBERPOWER (Chat) 20:34, 16 June 2020 (UTC)
To be able to follow redirects when using the popups gadget on Dutch Low Saxon Wikipedia. --bdijkstra (talk) 21:03, 16 June 2020 (UTC)
 Done —CYBERPOWER (Chat) 21:08, 16 June 2020 (UTC)
Indeed it works now, thanks. --bdijkstra (talk) 22:02, 16 June 2020 (UTC)

getting popups to work on content generated by other scripts

so if my script generates some content, contained in, say, OOJS or jQuery.ui dialog box, and i want the links in the newly minted content to be hooked to the gadget too, is there something i can do?

thanks, peace - קיפודנחש (aka kipod) (talk) 04:05, 27 June 2020 (UTC)

Have you tried the "reset" option under popups's "popups" option? -- Michael Bednarek (talk) 04:19, 27 June 2020 (UTC)
That’s rather a workaround than a solution, as it requires action from the user rather than the programmer. You might use mw.hook('wikipage.content').fire($content) if that’s appropriate, but probably the gadget should invent a new hook, as other consumers of the wikipage.content hook might expect the $content parameter to contain the whole page text, freshly from the parser (i.e. they might do non-idempotent changes on the content). —Tacsipacsi (talk) 10:58, 27 June 2020 (UTC)
thanks both. after some discussion on mw gelp desk, i think i understand my mistake now - the content added is not under the #content part of the page - it's stuck to something under the #p-personal div, which is outside the content. this is what fails the inbuilt "page preview" popups, which is what i'd really want. thanks again - קיפודנחש (aka kipod) (talk) 05:02, 2 August 2020 (UTC)

@Amorymeltzer and TheDJ: Can be added in the bottom of the popup the links versus the sister projects when according to Wikidata they exist? --Andyrom75 (talk) 08:35, 25 November 2020 (UTC)

Not clear to me what you're asking for, or what query that would add... ~ Amory (u • t • c) 16:14, 29 November 2020 (UTC)
trying to translate, hoping i understood the request correctly: when the popup is for an article, show interwiki links at bottom. the query you'll need to perform, if you want to fulfil this request is { action: 'query', prop: 'langlinks' }. personally, i do not think the interwiki links are useful enough to justify the screen real estate and the effort. at most, i would add the number of interwiki at some corner of the popup, using tooltip to explain what this number indicates ("the article exists in X languages" - bonus point for listing the first N). peace - קיפודנחש (aka kipod) (talk) 21:45, 4 December 2020 (UTC)

JS error: "TypeError: $.inArray is not a function"

When I hover over "Nocturn op. 9, núm. 2" on https://ca.wikipedia.org/w/index.php?title=Nocturns_op._9_(Chopin)&oldid=22970535 I get a JS error "Uncaught TypeError: $.inArray is not a function". I'm not sure why this is happening, but could one of the maintainers look into it and please patch it? Jdlrobson (talk) 21:01, 1 August 2020 (UTC)

@Jdlrobson: I suggest you ask one of the cawiki intadmins to update w:ca:MediaWiki:Gadgets-definition to include the dependencies that we have for popups.js as listed in MediaWiki:Gadgets-definition. — xaosflux Talk 00:17, 2 August 2020 (UTC)
Eh, I've been meaning to look into this for a while since I get it sometimes here. This thing is a miserable beast to go through. ~ Amory (u • t • c) 16:15, 29 November 2020 (UTC)
If someone can give me a repeatable way of finding it, I'll try and look into it. I've not run into it for a while. ~ Amory (u • t • c) 13:29, 4 December 2020 (UTC)

educated guess: look at line 1467: 

function $(c) { return (typeof c == 'string') ? (ll[0].substr(0,c.length)==c) : ($r = ll[0].match(c)); }

in the scope of this line (i.e., inside Insta.convert() ), it replaces jQuery "alias" $. so in this scope, $.inArray is invalid. remedies: if the array is "normal", you can use <arrayVar>.indexOf. if jquery inArray is desired, call it using jQuery.inArray(). personally, i would rename the "$()" function (i think it was written before jQuery became standard mw library). if you want to try and repro: i did not dive deep into the code, but from a glance, my guess is that it has something to do with nested lists (i.e., lines which begin with **#* and such). peace - קיפודנחש (aka kipod) (talk) 21:13, 4 December 2020 (UTC)

Ah good eye קיפודנחש, that's awful! A couple others there should be renamed; I've done a quick replace in my userspace, and while with a quick glance overall it seems to work, I've not got a great idea about how to specifically test these changes or ramifications. Jdlrobson do you have another way to repeat that particular error, at least? I couldn't trigger it on your initial example, and as noted haven't been able to find it here lately, though I know it exists. ~ Amory (u • t • c) 18:30, 5 December 2020 (UTC)
I looked into it a bit and can confirm the find/replace will fix the error. The problematic $.inArray call will run when viewing a preview to User:Enterprisey/sandbox5; you need a list indented with ; (since Previewmaker.prototype.mopup will remove lists indented with :). There are only two calls to $.inArray in the whole script. However, it doesn't raise an error when it tries to call the function; it just returns to the caller. I have no idea why that happens. Maybe it's just a JavaScript thing. Enterprisey (talk!) 23:08, 5 December 2020 (UTC)
So... that link has what triggers the error but it doesn't trigger the error? Am I reading that correctly? 😂 ~ Amory (u • t • c) 02:56, 6 December 2020 (UTC)
It executes the line that ought to trigger the error and then returns from the function instead of saying anything. I am thoroughly befuddled. Maybe I should ask Stack Overflow or something. Enterprisey (talk!) 03:42, 6 December 2020 (UTC)
@Enterprisey: I had a stupid caps error; previews show fine on your link, whereas the original just showed nothing. So, regardless of not being able to trigger the original error, an improvement! ~ Amory (u • t • c) 11:41, 6 December 2020 (UTC)
Hmm, I think I can see some issues with my quick replace. For one, it looks like some popups have abbreviated previews? Also, upon second generation for the same link, I get a compareLineString is not defined error. I'll try and look into it a bit more tomorrow. ~ Amory (u • t • c) 11:41, 6 December 2020 (UTC)
Dumb capitalization error, fixed both. ~ Amory (u • t • c) 11:41, 6 December 2020 (UTC)

I can check the error logs after any fix is made to verify that it's fixed. Jdlrobson (talk) 03:45, 6 December 2020 (UTC)

methinks you'll have to merge it with This diff. peace - קיפודנחש (aka kipod) (talk) 00:28, 7 December 2020 (UTC)

Okay all I've just pushed a change to fix both the issues in this section. I was able to replicate the error on ca.wiki (I was using the wrong link...) which helped soothe my cautious soul, but ping me if anything is busted!​​​​ ~ Amory (u • t • c) 12:41, 9 December 2020 (UTC)

Malformed URI sequence

@Amorymeltzer: I could have sworn I got the same error here, too, but now I can't reproduce it. Maybe I was thinking of this bug: If I (FF 83/Linux) hover over this link, I get https://en.wikipedia.org/w/index.php?title=User:Amorymeltzer/popup.js&action=raw&ctype=text/javascript at line 2205: URIError: malformed URI sequence. Don't know if that's related. Suffusion of Yellow (talk) 22:05, 5 December 2020 (UTC)

@Suffusion of Yellow: That's a separate issue, that amusingly I was dealing with earlier today. Basically, decodeURI (and decodeURIComponent) are stupid and can't percent-encode % per se, so the whole thing just falls apart What I just did was:
url = url.replace(/%(?![0-9a-fA-F][0-9a-fA-F])/, '%25');
That basically percent-encodes any % that doesn't look like a proper hexcode. We can do that here too, I suppose. ~ Amory (u • t • c) 03:02, 6 December 2020 (UTC)
Actually, looks like popups already does this? See the functions myDecodeURI and safeDecodeURI. Your issue appears to be the only extant use of the native decodeURI, and a quick test shows that merely replacing it makes the popup work. The title is erroneous/misleading, though, as in your case it will show "X#3%" as the title, when we'd prefer "X#3"? Half a loaf, I suppose! ~ Amory (u • t • c) 03:11, 6 December 2020 (UTC)
​Reverted my fix for the malformed URI issue, since it was mucking up previews of citations (See WP:VPT#NavPops are now behaving differently). Will try to think about later when I get a moment. ~ Amory (u • t • c) 13:55, 9 December 2020 (UTC)
Okay, had a moment, I think I took care of it, check out this comparison. Basically, (some? all?) citations previews use _, which were removed by decodeExtras, so using that broke 'em. I added my regex to decodeEscapes in the case where no valid %-encodings were found, and swapped the order in decodeNasties so that decodeURI was only called on the now-properly-escaped text. I'll do some more testing later, since it's not urgent, but I think this should clear up this issue. ~ Amory (u • t • c) 15:30, 9 December 2020 (UTC)
Great, thanks for the patch and for even looking at this code. (Sometimes I feel like I need a shower after working on it...) Enterprisey (talk!) 03:18, 11 December 2020 (UTC)

Whoops, forgot about this! Just noticed Jon (WMF) made a different change to address this. I suppose with errors on we'll soon find out if this works well enough! ~ Amory (u • t • c) 02:08, 26 January 2021 (UTC)

We certainly will! Yay to not having to code in the dark any more. Hopefully this means we'll catch the bugs before people report them :) Exciting times to be a Wikimedia developer! Jon (WMF) (talk) 02:14, 26 January 2021 (UTC)
Jon (WMF), I actually went ahead and replaced your changes with my version above, hope you don't mind: I was still able to trigger the issue on the same link above after the changes you made. Was there something you tested it on I could confirm this works as well? ~ Amory (u • t • c) 02:17, 26 January 2021 (UTC)
I do not mind at all. In fact I appreciate your help and support with getting these issues addressed. Don't worry you will hear from me again if the error resurfaces haha! :) Jon (WMF) (talk) 02:20, 26 January 2021 (UTC)
Something wrong after fix URL problem. (Popups 's Script on Chinese Wikipedia is is a direct reference to English Wikipedia's) --Cwek (talk) 03:00, 26 January 2021 (UTC)
The Japanese Wikipedia is also experiencing garbled text problems. --yusuke1109 (talk) 07:55, 26 January 2021 (UTC)
In the French Wikipedia also. The title of a target page which contains non-ASCII characters is wrong (but the link works). Seudo (talk) 10:03, 26 January 2021 (UTC)
​​​​So sorry for that, thanks for the note! I've gone and reverted the change. Will look into a better fix later! ~ Amory (u • t • c) 11:32, 26 January 2021 (UTC)
Okay all, I think I fixed it, but lmk if something is still busted. ~ Amory (u • t • c) 12:35, 26 January 2021 (UTC)
​ Il looks OK now. Thanks! Seudo (talk) 13:33, 26 January 2021 (UTC)

New wikitext mode

Currently the script does not work well with the new wikitext mode as it cannot automatically edit and fill in the edit summary. Is it possible to fix this by replacing "action=edit" with "action=submit" in the generated links since "action=submit" opens the old editor? ~ Aseleste (t, e | c, l) 15:25, 7 April 2021 (UTC)

which particular action of the script are you referring to ? —TheDJ (talk • contribs) 11:22, 8 April 2021 (UTC)
@TheDJ: I am referring to any action that takes you to the wikitext editor. Somehow forgot to watchlist this page, sorry. ~ Aseleste (t, e | c, l) 17:41, 8 April 2021 (UTC)

timeZone support

As described in phab:T223002, there have long been problems with DST in popups. This change should fix that, by using the timeZone the user has configured instead of the offset (which should not be relied upon). We make use of toLocaleString to render a string in the specified user language locale and the configured timezone. IE11 is the only browser we support that doesn't support this method, and in that case we fallback to the old system. It also introduces the options popupLocale, popupDateTimeFormatterOptions, popupDateFormatterOptions and popupTimeFormatterOptions to override as desired. —TheDJ (talk • contribs) 22:33, 3 April 2021 (UTC)

Regarding if( tzComponents.length === 3 && tzComponents[0] === 'ZoneInfo') { ... } else { errlog( 'Unexpected timezone information: ' + tz ); }, @TheDJ, tzComponents[0] can also be System (wiki default time) or Offset (exact offset specified rather than a zone). – SD0001 (talk) 08:05, 4 April 2021 (UTC)
Yes, I know, it's just that I can't do much with that information. System == UTC (already the fallback). Unless its not, which means not a WMF server and I don't see why we need to support those installations. (Nvmd, I forgot about non-english there.. I'll see about fixing that too) This System setting should only occur for new users who have never set their timezone. The Offset case can happen more often, but should still be rare. I guess in theory we could fallback to offset calculation here, but I'm not sure that is worth it. —TheDJ (talk • contribs) 09:36, 4 April 2021 (UTC)
Now with offset support as well: timezone change —TheDJ (talk • contribs) 12:31, 4 April 2021 (UTC)

This System setting should only occur for new users who have never set their timezone.

I’ve changed my preferences (including my timezone preferences) quite a number of times, but settled at the default System, as I prefer to see the same time in page histories and in signatures. I’m pretty sure I’m not alone; this occurs not only for new users. —Tacsipacsi (talk) 01:00, 5 April 2021 (UTC)

 Done I've synced in the requested change, please ping me here if any issues are presenting now. Any int-admin should feel free to revert if breaking issues have been created. — xaosflux Talk 14:59, 12 April 2021 (UTC)

isFunction

When I made the change, I mistakenly hit enter before managing to write an edit summary. Here is the summary: "Fixing usages of $.isFunction (Deprecated: https://api.jquery.com/jQuery.isFunction/). See T280944 for more info. Ladsgroupoverleg 20:38, 7 August 2021 (UTC)

Pronoun templates

I'm thinking about code changes to make {{User They them pronouns}} put "they/them" in the same place where "he/him" sometimes appears today. That's going to be tricky to localize, though - anyone have any suggestions? We could start another mapping of language-specific data, separate from the current mapping of translations, that can hold mappings of templates to pronoun displays, perhaps? Enterprisey (talk!) 07:59, 10 August 2021 (UTC)

Other option is to make those templates emit a span with a class that can be recognised that is used to parse out the information you want to display. —TheDJ (talk • contribs) 08:35, 10 August 2021 (UTC)
Yeah, that sounds like a better idea. Or maybe a HTML attribute data-mw-use-pronouns="they/them", for direct display in Popups, which removes the need for any sort of mapping or translation layer. I know Popups already fetches the wikitext of the user page; I don't know if it already fetches the HTML, but I guess that's not much of a concern. Enterprisey (talk!) 21:37, 10 August 2021 (UTC)
You're going to have to fetch additional data regardless, because the wikicode fetcher/interpreter only fetches the first part of the page and the template can be anywhere. It also doesn't really do anything with templates. So it's either via the rendered html, or via something like categories. But categories could be way more controversial. —TheDJ (talk • contribs) 11:00, 11 August 2021 (UTC)
Perhaps don't get married to this specific template for this purpose? There are a ton of these templates if you count all the forks. You could just make a single custom template for popups purpose, with the directions being to put it at the top of the page - it wouldn't have to have visible output (it could just output an empty div with a class for example). — xaosflux Talk 13:58, 11 August 2021 (UTC)
Ala Template:Wikipedia user they them popups or the like maybe? — xaosflux Talk 15:21, 11 August 2021 (UTC)

Event delegation?

At User talk:Nardog/MoveHistory#Odd side effect, a user thought Navigation popups stopped working on links in diffs made by wikEdDiff because of my script, when (as far as I could tell) it was because wikEdDiff was sometimes loaded after Navigation popups had already run. I suggested code to make sure they are loaded in the right order (or can the order be specified in gadgets definition or somewhere?), but this seems like a problem that can be worked around by Navigation popups attaching event handlers to an element near <body> rather than to individual links, taking advantage of event delegation, so it can show popups on links inserted later by other scripts. Nardog (talk) 00:53, 31 August 2021 (UTC)

Popups on search suggestions?

One kind of link on which Navigation Popups don't seem to appear are the search suggestions that pop up if I type into the search bar (e.g., if I type "a" I get suggestions of A, Association football, Australia, Animal, Arthropod, ..., any of which I can click to navigate to the article). Would it be reasonable to make Navigation Popups show for these links? —2d37 (talk) 05:33, 28 September 2021 (UTC)

Page Previews incompatibility

As raised here, incompatibility with the more modern Page Previews is a real drawback to the Navigation popups tool—is there a plan to add an option for the Navigation popups to only be shown for non-mainspace pages? — Bilorv (talk) 13:33, 28 September 2021 (UTC)

@Bilorv: despite WP:DTTR: {{sofixit}}? () Basically, there is no centralized "design authority" on this, so whatever someone wants to work on is fine. There should be very little pushback if someone wants to introduce an opt-in option to the gadget. — xaosflux Talk 15:05, 28 September 2021 (UTC)
@Xaosflux: always happy to be sofixit'd. I have some fluency in programming, but none on Wikipedia, so I can't really estimate the scale of the task from my level of knowledge. Would we be looking at wrapping some code in a simple conditional ("if !getValueOf('popupDisableMainspace') || [function to get page namespace] != 0") or a huge overhaul of hundreds of lines of code? — Bilorv (talk) 15:54, 28 September 2021 (UTC)
I'd think it would be more of the try/catch wrapper type. You might get some more engagement with the more regular devs for this if you put it on the workboard as well. — xaosflux Talk 16:14, 28 September 2021 (UTC)
presuming this is not something everyone wants, it can be implemented individually, in a roundabout way: basically, instead of enabling the gadget in preferences, one can load it "manually" from their personal script page, applying any filter desired, such as namespace id != 0, or even article name != 'Kung Fu Panda' or "today is not Tuesday". peace - קיפודנחש (aka kipod) (talk) 21:21, 30 September 2021 (UTC)
i missed the "fluency in programming, but none on Wikipedia" part. sorry. to load the gadget, use the command
// simply load it:
mw.loader.load(' ext.gadget.Navigation_popups' ); // gadget may be named differently on other wikis
// alternatively, "everywhere except article space":
if ( mw.config.get( 'wgNamespaceNumber' ) != 0 )
    mw.loader.load( 'ext.gadget.Navigation_popups' );
קיפודנחש (aka kipod) (talk) 21:30, 30 September 2021 (UTC)
An interesting concept, קיפודנחש. When I use this conditional version it shows me navigation popups as normal for non-mainspace links, and for mainspace links it shows me both the popups and the hovercards. When I change this to:
if ( mw.config.get( 'wgPageName' ) != 'Kung Fu Panda' )
    mw.loader.load( 'ext.gadget.Navigation_popups' );
I get the exact same effect, whether on links to Kung Fu Panda or other mainspace pages. Same also for simply:
mw.loader.load( 'ext.gadget.Navigation_popups' );
So it looks like the conditional is completely ignored, for some reason, and the code executed regardless. — Bilorv (talk) 22:00, 30 September 2021 (UTC)
your condition should still work, but only ON THE 'Kung Fu Panda' PAGE (it won't work for links to this page!)
the decision to load or not load the gadget is done only once, when the page is opened.
i suggest you try to see what is the behavior for internal links which appear _in_ the page Kung Fu Panda (presuming you have the condition), and if indeed you see what you want to see, you can change the condition to mw.config.get( 'wgNamespaceNumber' ) != 0; (tbh, the "!= 0" part is superfluous, since 0 is false, so it's more for the human reader than for the machine).
peace קיפודנחש (aka kipod) (talk) 22:14, 30 September 2021 (UTC)
i might have misunderstand the original request - i thought you wanted to disable popup on mainspace, not "disable popup for links to mainspace pages". note that the 2nd, more sophisticated way, requires more than just navpop change: the inbuilt "hovercard" (i think this was the original name of this feature) would detect "navigation popups", and disable itself when detected, respecting the seniority of the latter. presuming this is still done, what you ask might require some changes to the inbuilt feature, otherwise each may give "right of way" to the other, such that neither will work for mainspace links.
typically, mainspace IL should be only to mainspace pages, so my "reverse" solution (based on namespace of current page rather than that of the linked page) should be "almost good enough". you may have other places where may want to squelch navpop, e.g. watchlist, categories, or "what links here" pages (. my suggestion was to find a criterion for "where to load navpop" which works for you. i can't think of something like "which links to ignore" way, short of actually meddling with the code of both navpop and the inbuilt feature. sorry. peace - קיפודנחש (aka kipod) (talk) 22:31, 30 September 2021 (UTC)
@קיפודנחש: have you actually tested the code yourself? I tried both versions of "links to mainspace pages/Kung Fu Panda" and "links on mainspace pages/Kung Fu Panda" with both versions of the conditional, figuring myself that the code you'd given looked more like it was designed for links on a page, and none of the four of them worked. I reasoned similarly to you that disabling popups in mainspace was close enough. — Bilorv (talk) 15:59, 1 October 2021 (UTC)
i added to my personal script page this code: 
if ( mw.config.get( 'wgNamespaceNumber' ) != 0 )
    mw.loader.load( 'ext.gadget.Navigation_popups' );
and it does exactly that: navpop works everywhere except in mainspace (note that for links to articles from non-article space, like the link to kung fu panda above, you get both: "page preview" does not detect navpop, since it's not selected in preferences, and navpop itself works outside of mainspace). i understand you were asking something a bit different - discriminating based on the page linked, but this is, as you put it, "close enough".
i also verified that indeed, the inbuilt "article preview" self-disables when navpop is enabled in preferences => gadgets. navpop provides more functionality than page preview (basically everything under "actions"), and i imagine most navpop users want it on mainspace too. again, such an option in navpop will not be enough - in addition to disabling navpop for mainspace links, something will have to be done to tell "page preview" that the user selected this option, so it should not "self disable", and still disable itself for navpop users who did not choose this option. all this is doable, but it seems highly unlikely it will be done. peace - קיפודנחש (aka kipod) (talk) 17:10, 1 October 2021 (UTC)
I didn't notice your edit here changing the code without comment. I'll go with this bodge for the time being, though it seems to be that despite being told to fix it myself, I do not have the technical permissions to actually implement my initial request. — Bilorv (talk) 17:04, 2 October 2021 (UTC)
One could edit it in a sandbox and offer the sandbox version to be copied by an interface editor. (Personally I don't think I have the confidence to try fiddling with a widely-used 243-kilobyte JavaScript script myself.) —2d37 (talk) 09:16, 3 October 2021 (UTC)
@2d37: I don't have the technical permissions to edit the functionality of hovercards, which seems to be necessary for this change. — Bilorv (talk) 16:54, 3 October 2021 (UTC)
Ah, my apologies, yes, I thought MediaWiki:Gadget-popups.js was meant. (As it's all dynamic JavaScript, I suppose it's possible to mess with the Page Previews from within (a non-gadget version of) Navigation Popups, but I don't suppose it's wise.) —2d37 (talk) 00:13, 4 October 2021 (UTC)

Interface-protected edit request on 8 October 2021 (2)

Under the line 

.popup_history_date {
  font-weight: bold;
  font-size: 120%;
}

add the block 

.popup_history_row_odd,
.popup_history_row_even {
	display: flex;
}

.popup_history_row_even td:nth-child(3),
.popup_history_row_odd td:nth-child(3) {
	flex: 3;
	word-break: break-word;
}
.popup_history_row_even td:nth-child(4),
.popup_history_row_odd td:nth-child(4) {
	flex: 7;
	word-break: break-word;
}
.popup_history_row_even > td:not(:last-child),
.popup_history_row_odd > td:not(:last-child) {
	margin-right: 2px;
}

This fixes overflows of the content in the history view of popups. —TheDJ (talk • contribs) 22:19, 8 October 2021 (UTC)

 Done — xaosflux Talk 15:45, 19 October 2021 (UTC)

Interface-protected edit request on 8 October 2021

Request to deploy this new version of popups (diff). This has the following changes:

  • Use the proper groupnames, instead of the technical groupnames (administrator instead of sysop)
  • Add support for WhatLinksHere, Diff, emailuser and Contributions pages in non-english languages, by fetching the Special page name aliases from the API.
  • Factor out the api constructor and reuse it
  • Recognize wikispecies, wikivoyage, wikidata and metawiki as wikimedia properties. —TheDJ (talk • contribs) 21:17, 8 October 2021 (UTC)
    @TheDJ: just a quick note that this isn't being purposefully ignored as far as I know, the change is just quite large and likely no one has had enough time to review it yet. I'll likely just promote your change soon as I trust you and it could always be rolled back - just haven't found a good time to schedule that where I'd be around to fall it back if needed. Thank you for continuing to work on this development! — xaosflux Talk 23:23, 18 October 2021 (UTC)
  •  Done any int-admin should revert without pause if problems have been introduced. — xaosflux Talk 15:42, 19 October 2021 (UTC)
    Hmm... following this change, when I hover over a user, the user groups now display as the system message names for some time until another network request completes. I imagine the user group names don't actually change much... would it be possible for there to be some caching or some other way to prevent this behavior? It's a minor cosmetic issue, I guess, but it's a little annoying. And to end on a positive note, thank you for putting the effort into this change; it does look a lot better to have the proper names be used. Enterprisey (talk!) 06:49, 20 October 2021 (UTC)
    No significant delay here – less than a second, if at all. On the other hand, contributions for IP editors have a very narrow column for the article name. -- Michael Bednarek (talk) 07:25, 20 October 2021 (UTC)
    @Michael Bednarek the column sizing is intentional. It was to fix the overflow. The columns are now divided 3:7 between article name and comment. Its hard to find a good tradeoff for that. —TheDJ (talk • contribs) 07:48, 20 October 2021 (UTC)
    Yes I sometimes see it too. Unfortunately popups is designed to render early and then fill in information as it arrives. That also happens here and I have no easy way to get around to it. There is also not really a usable cache for this, as popups only has in-memory caches, so adding a new one would be some additional work. —TheDJ (talk • contribs) 07:51, 20 October 2021 (UTC)
    OK, all good. Enterprisey (talk!) 08:05, 20 October 2021 (UTC)
    This does look jarring. @TheDJ perhaps the delays can be mitigated with simple http caching? I see the message fetch requests don't have maxage param, though these are unlikely to change at all. – SD0001 (talk) 15:31, 20 October 2021 (UTC)
    is this only on the use localized group names part? Because really, that isn't that important is it? — xaosflux Talk 15:45, 20 October 2021 (UTC)
    It's a like a different kind of FOUC, which while not "important", is usually considered worth fixing. I see it on every username hover. – SD0001 (talk) 16:06, 20 October 2021 (UTC)
  • Do the the flashing, I'm in favor of not using the localized group name parts - other improvements still seem fine. Anyone want to mock up a proposed new version? — xaosflux Talk 16:23, 20 October 2021 (UTC)
    I realized that a return statement is placed incorrectly, causing the popup to update twice instead of once. I think that will fix the problem. —TheDJ (talk • contribs) 19:28, 20 October 2021 (UTC)
     Done updated that return; placement - lets see if it helps. — xaosflux Talk 19:54, 20 October 2021 (UTC)

UserData not translatable?

I hope this is the correct page to ask my question. While using the gadget on dewiki, I noticed that the UserData line for links to user pages is always in English (e.g. he/him · autoreview, editor, last edit on 2021-10-01). Is there a way to localise it? Regards, XanonymusX (talk) 22:58, 30 September 2021 (UTC)

@XanonymusX: As far as I know, user groups are just the technical names (this is why you’re flagged as a “sysop” on dewiki instead of an “admin”). Everything else should be translatable through window.popupStrings, e.g. 
window.popupStrings = {
	...
	'he/him': 'er/ihn', // or whatever is used in German; be careful to use pronouns and not biological sex/gender (see [[phab:T284783]])
	'last edit on ': 'letzter Beitrag am ',
	...
};
—Tacsipacsi (talk) 00:20, 1 October 2021 (UTC)
Thanks, that worked! The only part I have not been able to change is “# edits since:”; how to find out what the exact string is in this case? I have tried “edits since” and “edits since: ”, to no avail. Of course, displaying the technical names for the user group is not very nice in a non-English environment; similarly, the number and date formats do not fit with the German translations of the remaining text. Any chance that these could be localised as well? Regards, XanonymusX (talk) 11:32, 4 October 2021 (UTC)
Should be ' edits since: ' as can be found in MediaWiki:Gadget-popups.js. "similarly, the number and date formats do not fit with the German translations of the remaining text" these should be getting localised by your browser (and for me it shows "4. Oktober 2021" for instance). If it doesn't work for you, can you specific exact pages and language settings you use, as well as the browser you use ? —TheDJ (talk • contribs) 11:47, 4 October 2021 (UTC)
This discussion reminded me of a long-standing problem I have with popups at the German Wikipedia: every aspect there works, except the popup list in a revision history or watchlist for "Beiträge" (contribs) does not show. But, when I hover over a user name and then "Benutzer" (user) and go to "Beiträge", the popup list does show. However, this method requires hovering 3 levels and a steady hand on the mouse. The failure to show the popup list for "Beiträge" directly baffles me. -- Michael Bednarek (talk) 13:06, 4 October 2021 (UTC)
This is because popups has 3 links with hardcoded strings, since it didn't traditionally know the translated name of those links.
:::::        pg.re.contribs = RegExp('(title=|/)' + sp + '(?:%3A|:)Contributions' + '(&target=|/|/' + nsRe(pg.nsUserId) + ':)(.*)');
:::::        pg.re.email = RegExp('(title=|/)' + sp + '(?:%3A|:)EmailUser' + '(&target=|/|/(?:' + nsRe(pg.nsUserId) + ':)?)(.*)');
:::::        pg.re.backlinks = RegExp('(title=|/)' + sp + '(?:%3A|:)WhatLinksHere' + '(&target=|/)([^&]*)');
:::::
So "Contributions", "EmailUser" and "WhatLinksHere". These types of translations don't have a proper API to access them from the JS side, if I'm not mistaken. —TheDJ (talk • contribs) 16:30, 4 October 2021 (UTC)
I played with adding some options, which should make it possible to set something like window.popupContributionsLinkRegexp = 'Contributions|Contribs|Beiträge|'+encodeURI('Beiträge'); from the de.wp configuration script. Not deployed yet. I also worked on translating the group names, but the strategy I'm using there doesn't work yet, as apparently you can only retrieve a max of 50 messages and we have 91 groups and dynamically loading them within popups with the current structure is a bit hard... If anyone has ideas.. —TheDJ (talk • contribs) 20:54, 4 October 2021 (UTC)
They have an API endpoint: https://de.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces%7Cnamespacealiases%7Cspecialpagealiases tells all the required information. (It doesn’t tell which one is the canonical special page name in the wiki’s content language, but recognizing all is even better: it means that all links work, including ones that are processed by NavPopups (e.g. talk pages’ previews) and those that aren’t processed at all (e.g. when selecting wikitext in WikiEditor). Also, the regexes above are case-sensitive, but special page names aren’t actually; special:contributions/tacsipacsi is the same as SpEcIaL:CoNtRiBuTiOnS/Tacsipacsi (but not the same as SPECIAL:CONTRIBUTIONS/TACSIPACSI; user names are case-sensitive except for the first character). To better handle links not processed by the MediaWiki parser, please make the regexes case-insensitive.) —Tacsipacsi (talk) 11:29, 5 October 2021 (UTC)
oh cool, I didn't even know about that. I'll try and work that in somewhere this week. —TheDJ (talk • contribs) 08:05, 6 October 2021 (UTC)
Thanks, somehow I had been unable to find that specific string! It’s working now. The dates however are always shown as 2021-10-08 to me and the byte number always uses a point instead of a comma. I use Chrome, language preference is de; I also tried it with Firefox now, still the same.–XanonymusX (talk) 21:47, 8 October 2021 (UTC)
Popups at DE Wikipedia's watchlist show German dates for me ("9. Oktober 2021"), article size is shown as nnn.nkB, but still nothing is shown for "Beiträge". -- Michael Bednarek (talk) 01:26, 9 October 2021 (UTC)
@Michael Bednarek: I still see ISO 8601 (YYYY-MM-DD) dates everywhere, the article size is also incorrect (the dot is a thousands separator in German, not a decimal separator: the English 1,234.5, meaning one thousand two hundred thirty-four and a half, is 1.234,5 in German). The fix for the contributions link is ready but hasn’t been deployed yet (see edit request below). —Tacsipacsi (talk) 11:57, 9 October 2021 (UTC)
When I use popups to hover over your username at https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Tacsipacsi&action=history (2nd line) I see "er/ihm · autoreview, editor, 323 Beiträge seit 20. Juni 2012, letzter Beitrag: 23. Juni 2019", hovering over "Diskussion" shows "er/ihm · autoreview, editor, 323 Beiträge seit 20. Juni 2012, letzter Beitrag: 23. Juni 2019¶5.2kB, 11 Wikilinks, 0 Bilder, 0 Kategorien, 119 Wochen alt" (¶ is a new line). Hovering over "Beiträge" shows the browser's, not popups', tooltip "Spezial:Beiträge/Tacsipacsi". This behaviour is the same for Firefox and Chrome. -- Michael Bednarek (talk) 12:31, 9 October 2021 (UTC)
I see er/ihm · autoreview, editor, 323 Beiträge seit 2012-06-19, letzter Beitrag: 2019-06-23 (the second line is the same for me as for you). But I’m okay with the ISO date format, so I don’t think we should spend much time debugging the difference. —Tacsipacsi (talk) 14:40, 9 October 2021 (UTC)
I noticed for the first time today on the German Wikipedia that popups showed entries under "Beiträge" (contribs) (see above). Thank you to whoever fixed this. -- Michael Bednarek (talk) 01:10, 26 October 2021 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Gadget-popups.js/Archive_2&oldid=1118466413"