MediaWiki talk:Gadget-popups.js

Latest comment: 6 months ago by Novem Linguae in topic eslint-config-wikimedia autofixes

Refactor parsing of wikitext

edit

Per the above discussion, the following changes [1] are proposed :) Sohom (talk) 11:02, 6 December 2023 (UTC)Reply

This is just the "Removed the custom wikitext parsing engine at wiki2html() and replaced it a call to the parsing API" part of your above code, and not the other two items, correct? Also, what is a good test procedure for this? –Novem Linguae (talk) 11:15, 6 December 2023 (UTC)Reply
Yep, it is only that wrt to testing,
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');
});
should work :) Sohom (talk) 11:17, 6 December 2023 (UTC)Reply
For testing, I meant, what modules should we be clicking to exercise this part of the code? :) –Novem Linguae (talk) 11:31, 6 December 2023 (UTC)Reply
Oh, okay :) Since this is the preview module, anything that shows a preview would work (articles, userpages, images). I've put together a set of links at User:Sohom_Datta/sandy-box in case you want to test it out :) Sohom (talk) 11:55, 6 December 2023 (UTC)Reply
Sandy box. Love that. Haha. In my testing, I found two differences between the old and the new.
  1. Templates now render, instead of displaying the wikicode. You can see this in your sandy box image examples. I think this is a feature not a bug. I think folks will like this.  Y
  2. Headings now have [ edit | edit section ] links that they didn't have before. And they are showing up a bit too big. I think they are the same size as the headings rather than body text. I think this should either be shrunk or hidden before we deploy this patch. This may involve changing MediaWiki:Gadget-navpop.css.  N
  3. Now that the other patch was merged, needs a rebase.  N
Novem Linguae (talk) 20:27, 7 December 2023 (UTC)Reply
I won’t like if templates are rendered. Templates are not rendered for a reason: how templates making heavy use of parameters happen to render on their own page doesn’t say much about what they’re really are. They are oftentimes even partly or entirely <includeonly>d, so parts are left out from the preview. Couldn’t the namespace condition moved to before making the API request, so that the request is sent only for non-template pages, continuing to display template wikitext verbatim? —Tacsipacsi (talk) 15:37, 8 December 2023 (UTC)Reply
I intend to take another stab at this next week, it seems to be fairly complicated to have templates not be rendered, I will see if we can maybe only the show the documentation somehow. Sohom (talk) 15:59, 15 December 2023 (UTC)Reply

Other talk page, and Phabricator

edit

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)Reply

History preview failed

edit

can we change:

return 'History preview failed :-(';

to something like:

return popupString('History preview failed :-(');

for localization purpose? valepert (talk) 10:22, 31 January 2024 (UTC)Reply

Want to sandbox it somewhere and make sure it works? Then tag this with {{IAER}}? Also, searching for "preview failed" reviews 5 spots we could apply this pattern to. –Novem Linguae (talk) 10:29, 31 January 2024 (UTC)Reply
I made some test here, without CSS, and hovering "hist" on this page. I hope it's enough to evaluate the change. --valepert (talk) 13:57, 31 January 2024 (UTC)Reply
@Valepert. Don't forget to tag this with {{IAER}} when it's ready to go. Also please provide a steps to test, and a diff of what you changed. This makes it easy for the reviewer. –Novem Linguae (talk) 22:36, 28 February 2024 (UTC)Reply
please change "'History preview failed :-('" with "popupString('History preview failed')", adding "'History preview failed': 'History preview failed :-('," before "last:".
see diff.
step to test:
  1. visit Special:Contributions/2A02:C7F:745F:6400:69E1:8FB2:A675:2199
  2. hovering on "hist" of "100%" page
  3. expected message: "History preview failed :-("
--valepert (talk) 22:57, 28 February 2024 (UTC)Reply
Implemented, thanks valepert. However, two things of note: first, there are a ton more error messages that are not similarly isolated. Second, I notice there's an unrelated bug in your example, where the % in the article title display is being unnecessarily URI-encoded, which breaks the link to the article itself. Writ Keeper  14:03, 29 February 2024 (UTC)Reply

Feature request: Show Block reason

edit

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)Reply

Certain user permissions (extended confirmed, global renamer) not showing

edit

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)Reply

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)Reply
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)Reply
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)Reply
"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 (talkcontribs) 08:22, 16 April 2024 (UTC)Reply

eslint-config-wikimedia autofixes

edit

In a sandbox, I ran the official wikimedia javascript linter on the popups code. Here's the diff.

  • ran eslint-config-wikimedia autofixes
    • extends { "wikimedia/client/es6", "wikimedia/jquery", "wikimedia/mediawiki" }
    • excluding
      • controversial ones such as space-in-parens and max-len
      • no-var (changing var to let/const). this would be fine to do since Grade A support is on ES6 now, but will save for a future patch
      • unicorn/prefer-string-slice. I'm not sure the suggested .slice( 0, Math.max( is more readable/better than the existing .substring(
      • some rules that weren't auto-fixing well when I manually reviewed the code
    • including rules such as comma-dangle, no-unneeded-ternary, no-useless-concat, operator-linebreak, semi-style, unicorn/prefer-date-now, dot-notation, jsdoc/check-tag-names, jsdoc/check-types, and others
  • removed some comments

Will self-merge in a couple days if no objections.

Note to self: Manually test a bit on testwiki before deploying. –Novem Linguae (talk) 06:36, 25 April 2024 (UTC)Reply

I really dislike the "comma-dangle": "never" setting, it makes subsequent diffs less readable (and accounts for a large part of the current diff as well). Could you change it to only-multiline (or always-multiline if you prefer) and revert your changes that removed trailing commas? Thanks in advance!
Also, I don’t see any reference to this ESLint rule set in the code. Could you add a comment (even if not machine-readable) that informs future maintainers what they should lint the code with? —Tacsipacsi (talk) 19:41, 26 April 2024 (UTC)Reply
Thanks for the feedback. I'll avoid comma-dangle for now. Although it's in the official Wikimedia JavaScript linter, so I'm sure they have their reasons.
It'd be a pretty big comment, so I will probably have to keep it out of the code for now. The file I am using is...
{
	"extends": [
		"wikimedia/client/es6",
		"wikimedia/jquery",
		"wikimedia/mediawiki"
	],
	"globals": {
		"mw": "readonly"
	},
	"parserOptions": {
		"ecmaVersion": "latest",
		"sourceType": "module"
	},
	"rules": {
		"camelcase": "off",
		"es-x/no-array-prototype-includes": "off",
		"es-x/no-async-functions": "off",
		"es-x/no-class-fields": "off",
		"es-x/no-optional-catch-binding": "off",
		"es-x/no-regexp-lookbehind-assertions": "off",
		"es-x/no-regexp-s-flag": "off",
		"es-x/no-rest-spread-properties": "off",
		"es-x/no-string-prototype-matchall": "off",
		"es-x/no-string-prototype-replaceall": "off",
		"jsdoc/require-param": "off",
		"jsdoc/require-param-type": "off",
		"jsdoc/require-returns": "off",
		"max-len": "off",
		"mediawiki/class-doc": "off",
		"no-jquery/no-class-state": "off",
		"no-jquery/no-global-selector": "off",
		"no-jquery/no-parse-html-literal": "off",
		"no-jquery/variable-pattern": "off",
		"no-shadow": "off",
		"no-underscore-dangle": "off",
		"security/detect-non-literal-regexp": "off",
		"security/detect-unsafe-regex": "off",
		"unicorn/prefer-string-slice": "off",
		"space-in-parens": "off",
		"computed-property-spacing": "off",
		"eqeqeq": "off",
		"no-var": "off",
		"spaced-comment": "off",
		"array-bracket-spacing": "off",
		"jsdoc/no-multi-asterisks": "off",
		"no-alert": "off",
		"no-tabs": "off",
		"jsdoc/require-asterisk-prefix": "off",
		"jsdoc/check-alignment": "off"
	}
}
Novem Linguae (talk) 13:14, 4 May 2024 (UTC)Reply
  Done. –Novem Linguae (talk) 15:14, 4 May 2024 (UTC)Reply
@Novem Linguae: Thanks for excluding comma-dangle!

Although it's in the official Wikimedia JavaScript linter, so I'm sure they have their reasons.

I guess simply legacy. According to ECMAScript version history#5th Edition – ECMAScript 2009, a trailing comma in object literals is accepted only since ES5, and Wikipedia used to support ES3.

It'd be a pretty big comment, so I will probably have to keep it out of the code for now.

I see. Then maybe a subpage or a collapsible box on the top of this talk page? I fear a random talk page topic will get lost in the archives.
(Sorry for the late reply, I missed notifications due to a bot archival, which stopped watchlist emails despite not sending one itself.) —Tacsipacsi (talk) 10:32, 18 May 2024 (UTC)Reply
I was reading a random Phab ticket today and found out why comma-dangle is in eslint-config-wikimedia. It's for easier copy-pasting to JSON. I guess this use case was important to Wikimedia developers back when they decided on this rule. Today I learned. –Novem Linguae (talk) 15:53, 1 June 2024 (UTC)Reply
What is that random Phab task? I find this hard to believe (or at least not well thought through) because at the same time we have "quotes": "single", which is exactly the non-JSON-compatible version, and it’s even much more work to replace all the single quotes with double ones than deleting some commas. —Tacsipacsi (talk) 21:47, 1 June 2024 (UTC)Reply
phab:T222707#5164890 and phab:T222707#5165095
(the developer community has had this conversation before and decided that easier portability to JSON is more important than cleaner diffs)Novem Linguae (talk) 00:08, 2 June 2024 (UTC)Reply

Updates for dark mode

edit

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)Reply

  Done * Pppery * it has begun... 01:55, 27 May 2024 (UTC)Reply
Thanks very much! the wub "?!" 09:07, 27 May 2024 (UTC)Reply
@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)Reply
  Done * Pppery * it has begun... 01:31, 28 May 2024 (UTC)Reply