MediaWiki talk:Gadget-popups.js

message: I have no idea why the code in #Turkish Redirect above randomly sprinkles 'r' for 'redirect' or 'R' for 'REDIRECT' into every row. My testing indicates both these keywords work on Turkish Wikipedia. A potential future patch could be to refactor the code to be something like [r, R, ...] on every line. –Novem Linguae (talk) 09:51, 15 August 2023 (UTC)
replies: text: I found this pattern in core recently, where this code may have been copy pasted from or at least inspired by. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/952290. There, 0 corresponds to case insensitive and 1 corresponds to case sensitive. r and R in this code may have similar meanings. https://github.com/wikimedia/mediawiki/blob/master/docs/magicword.md. Will need to take a closer look at this. –Novem Linguae (talk) 07:44, 25 August 2023 (UTC)
thread_title:  List of redirect magic words for each language could use refactoring 

message: This gadget uses a second file called MediaWiki:Gadget-navpop.css. Idea: Shouldn't have to look at the gadgets definition file to figure out what this gadget's CSS file is named. It'd probably make more sense for all files related to this gadget to start with MediaWiki:Gadget-popups. So I propose renaming MediaWiki:Gadget-navpop.css to MediaWiki:Gadget-popups.css –Novem Linguae (talk) 10:34, 15 August 2023 (UTC)
replies: text: Support. No reason in having this oddity. Chlod (say hi!) 14:48, 18 August 2023 (UTC)

text: I’m not opposed to the renaming, but please make sure to maintain backward compatibility. There are probably quite a few people and wikis who load the NavPopups CSS directly rather than as part of the ResourceLoader module, so it’s important that https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navpop.css&action=raw&ctype=text/css continues to load the necessary styles. —Tacsipacsi (talk) 17:22, 19 August 2023 (UTC)
replies: text: @Tacsipacsi. Would replacing MediaWiki:Gadget-navpop.css with importStylesheet('MediaWiki:Gadget-popups.css'); be an acceptable solution? –Novem Linguae (talk) 20:47, 7 December 2023 (UTC)
replies: text:  Apart from it not working, yes. 🙂 You try to put JavaScript in a CSS file, which of course won’t work, but a working solution along these lines would be acceptable. Please also make sure to use absolute URLs because many – probably even most – affected imports are not on the English Wikipedia (importStylesheet uses a URL relative to the wiki it’s executed on, not to the wiki it’s defined on, which would be wrong). —Tacsipacsi (talk) 15:25, 8 December 2023 (UTC)
thread_title:  MediaWiki:Gadget-navpop.css should be renamed to MediaWiki:Gadget-popups.css 

message: I see some hints in the code that this gadget has a repo somewhere and is compiled with a deploy script. For example // ENDFILE: run.js. Any idea where the repo is? –Novem Linguae (talk) 10:36, 15 August 2023 (UTC)
replies: text: Those are still from Lupin. He used some sort of concatenation script on their local machine. We never had access to it. —TheDJ (talk • contribs) 11:21, 15 August 2023 (UTC)
thread_title:  Does this gadget have a code repository? 

message: This gadget uses custom string repetition function. It should be replaced with native String.prototype.repeat() which is significantly faster and well supported by modern browsers. – Ammarpad (talk) 05:20, 20 September 2023 (UTC)
replies: text: It seems to be used only for formatting time. So it would probably only help in optimization of the history page preview (if at all significant). Not sure if that is something worth optimizing. You know "premature optimization..." etc Nux (talk) 22:51, 24 September 2023 (UTC)
replies: text: I see this as more refactoring than optimizing. I have no objections to the idea. But it needs someone to write and test the patch. –Novem Linguae (talk) 23:42, 24 September 2023 (UTC)
replies: text: Refactoring when you loose compatibly, do a lot of work and gain nothing in practice is a bad idea IMHO. When you would start refactoring that you would never finish ;). When you go up the stack you also have a custom `map` function. Nux (talk) 11:50, 25 September 2023 (UTC)
replies: text: If both behave identically, using internal functions is always better than writing your own. 1) More standardized so more readable. 2) Less lines of code. 3) More performant. –Novem Linguae (talk) 19:33, 1 December 2023 (UTC)

text: To be a bit more constructive here... I think a better refactoring effort might be to be to move Popups to Github (e.g. with Wikipedia:Wiki-to-Git). Then do a split to separate files. And then either use e.g. browserify to combine it again. I've been thinking abut this for a while for plwiki, not sure if such update would be accepted here. Nux (talk) 12:19, 25 September 2023 (UTC)
replies: text: I'd be open to this if this page gets more activity. With current activity levels though, moving to GitHub may just result in the GitHub being neglected and the versions getting out of sync. And also adds deploy complexity. https://github.com/wikimedia-gadgets/ would be a good spot for this if popups development gets more active (more folks working on this would justify the added complexity of an off-site repo). –Novem Linguae (talk) 19:36, 1 December 2023 (UTC)

text: this doesn't appear to be a ready-to-go release, and may need additional discussion as well. Please prepare a current version to proposed version in a sandbox, such as at Special:MyPage/Gadget-popups-sandbox.js for the proposed code. IF this section is just to discuss strategies and proposals of course you may continue the discussion below. Best regards, — xaosflux Talk 03:17, 8 October 2023 (UTC)
thread_title:  Use native string repetition function 

message: Steps to reproduce: 1) vector 2010, not tested on other skins, 2) turn off navigation popups in Special:Preferences gadgets, 3) add the below code to User:abc/common.js, 4) hover over a valid article. What happens? Article title link is black. What should happen instead? Article title link is blue.
mw.loader.using(['mediawiki.api', 'mediawiki.user', 'mediawiki.util', 'user.options', 'mediawiki.jqueryMsg']).then(function() {
	importScript('w:User:Sohom Datta/parsingchange-popups.js');
	importStylesheet('w:MediaWiki:Gadget-navpop.css');
});
Looking at the code for .popup_mainlink a { color: #000; }, I think the devs intend for it to be black everywhere.
In the situation above, there are two CSS styles competing with each other. In one situation, .popup_mainlink a { color: #000; } wins out over the other styles. In the other situation, a:link, .mw-parser-output a.extiw, .mw-parser-output a.external, .vector-menu-portal .vector-menu-content li a { color: rgb(0,0,238); } wins out over the other styles.
Anyway, I think we should pick one color, then get it to be used consistently. Whether it's blue or black. I'm leaning blue.
I'm also curious why loading it as a non-gadget changes the CSS order of precedence, even though the two sets of selectors are identical. Perhaps there's a bug in the load code above? –Novem Linguae (talk) 20:37, 7 December 2023 (UTC)
thread_title:  Article title hyperlinks in previews are black, not blue 

message: Looks like this gadget has another talk page at Wikipedia talk:Tools/Navigation popups, and also a tag on Phabricator. Just an FYI for folks who only know about this page. I only discovered these today. –Novem Linguae (talk) 08:20, 30 December 2023 (UTC)
thread_title:  Other talk page, and Phabricator 

message: Is it possible to add the most recent block log entry (for currently blocked users) into the popup? Similar to how MediaWiki:Gadget-markblocked.js puts the reason in the tooltip. I have both scripts enabled, and it does strikethrough the username but Popups overrides the markblocked tooltip for blocked editors so I can't see the block reason without navigating away from the page I'm on to check the block log. I'd try building it myself based on the markblocked gadget, but my Javascript knowledge is very limited. The WordsmithTalk to me 21:11, 28 February 2024 (UTC)
thread_title:  Feature request: Show Block reason 

message: Usually when you hover over a username, popups shows all their local permissions in regular text, and all their global permissions in italics. However, I've noticed a couple permissions are not showing up. In particular, extended confirmed (local) and global renamer (global). I propose fixing these two, and doing an audit to make sure there's not any other permissions being missed. If there's some hard-coded list in the code somewhere, I propose switching to something that is not hard-coded so that new permissions can be reliably detected without code modifcations. –Novem Linguae (talk) 04:13, 16 April 2024 (UTC)
replies: text: I believe extendedconfirmed is an intentional omission. (No opinion in whether it should be.) Global renamer is, technically speaking, a local right on Meta, not a global right. See e.g. Special:CentralAuth/Tamzin. As a global renamer, I'd definitely find it useful to have that included here, but I'd think it'd require an extra API call just for that check?  -- Tamzin[cetacean needed] (they|xe) 04:21, 16 April 2024 (UTC)
replies: text: Yeah, looks like global renamer is local to meta and would require its own API call. Good find, thank you. –Novem Linguae (talk) 04:36, 16 April 2024 (UTC)
replies: text: There could be a case for a no-permissions global group for global renamers, similar to VRT permissions agents, but I guess that would be a matter for Meta.  -- Tamzin[cetacean needed] (they|xe) 04:38, 16 April 2024 (UTC)

text: "I believe extendedconfirmed is an intentional omission." correct. there are several groups (not permissions btw) that are filtered out because almost everyone has them. —TheDJ (talk • contribs) 08:22, 16 April 2024 (UTC)
thread_title:  Certain user permissions (extended confirmed, global renamer) not showing 

message: Can an interface admin please copy User:The wub/popups sandbox.css to MediaWiki:Gadget-navpop.css (comparison). This updates the styling to work in the new dark mode (phab:T365749), following the guidance at mw:Recommendations for night mode compatibility on Wikimedia wikis. the wub "?!" 20:32, 26 May 2024 (UTC)
replies: text: * Pppery * it has begun... 01:55, 27 May 2024 (UTC)
replies: text: Thanks very much! the wub "?!" 09:07, 27 May 2024 (UTC)
replies: text: @Pppery: Another edit, sorry. It was reported that forcing the diff text color clashes with the "Blackskin" gadget. I figured out some new diff background colors for dark mode which work with the white text color, avoiding the issue with Blackskin and I think looking better on the whole. Can you update from my sandbox again please? Here's the diff. the wub "?!" 21:43, 27 May 2024 (UTC)
replies: text:   * Pppery * it has begun... 01:31, 28 May 2024 (UTC)
thread_title:  Updates for dark mode