Jon (WMF)

MediaWiki:Mobile.js

Hi, I just noticed your edits on MediaWiki:Mobile.js, namely 174757781 and 174757798; I'd like to investigate a bit and polish them. Could you please elaborate about these edits, and tell me where you saw such "undefined function" JavaScript errors occurring? Thanks

The mobile site from French Wikipedia looks a little different to the desktop site. Notably it does not run MediaWiki:Common.js. On top of this the Minerva skin does not load many of the legacy JavaScript described in mw:ResourceLoader/Migration_guide_(users)#Legacy_removals. As a result any user scripts that are executing on mobile will throw JavaScript errors.

These scripts can come from global scripts on meta.wikimedia.org or Special:MyPage/minerva.js or Special:MyPage/mobile.js.

We have JavaScript error logging for French Wikipedia now so these are starting to appear at volume in our logstash software.

It would be great if these functions messaged impacted users to update scripts or used Minerva supported functions that have not been deprecated! It would be great if you can help with that?

I've been using the global search tool to find pages with legacy JavaScript. Jon (WMF) (discuter) 16 septembre 2020 à 17:25 (CEST)

• Maybe the most tricky overlook is meta:Special:MyPage/global.js, because once created it's fastly forgotten, as it's located on a different wiki. Even more tricky, it also executes on mobile, as opposed to Special:MyPage/common.js.
• About our local function addCustomButton(), it's designed to be straightforward to use, so that the user just puts the function and doesn't have to care with any conditional. You may see an example here. Therefore, I don't think it should be consider a mistake if it's put in a global script; however it is a mistake if it's used in a mobile-specific script (Special:MyPage/minerva.js or Special:MyPage/mobile.js). Basically the same goes with our related local functions addSpecialCharset and addSpecialCharsetHTML.
• The same probably goes with our local function obtenir, which as you can see is a script loader, because mistakenly loading on mobile a desktop-only script is probably worse than just avoiding the scripts, by making the loader a no-op.
• About MediaWiki's importScript, I suppose the best is also to have it always defined, and no-op. Though, shouldn't this one rather be taken care of by MediaWiki? As a reminder, on desktop importScript and importStylesheet aren't deprecated actually, and are still going to remain for a while, as there are no replacements for these functions yet.

od†n ↗^blah 17 septembre 2020 à 15:06 (CEST)

importScript and importStylesheet have been deprecated since 1.29, and mw.loader.load is the replacement, see mw:ResourceLoader/Migration_guide_(users)#Legacy_removals. The fact they don't error is because we know lots of gadgets use it and roll out is thus tricky: phab:T72470.

Note global scripts by default run on mobile, so global scripts should be considered mobile (Minerva) specific. Jon (WMF) (discuter) 17 septembre 2020 à 17:24 (CEST)

I see you have hotfixed a handful of local scripts. I'd like to investigate these further, to understand the root causes, as some of these bugs doesn't seem to be straightforward.

Do you know on what viewed pages the errors were triggered? You mentioned Logstash earlier. If the access is not public, maybe you could provide me the information privately or grant me some access?

od†n ↗^blah 1 octobre 2020 à 02:52 (CEST)

probably the most useful thing for you is going to be getting access to logstash. I link to it on en:User:Jdlrobson/User_scripts_with_client_errors. If you haven't got access you are probably not in one of the required groups.

If you don't have access, let me know which scripts you are interested in and I'd be happy to manually generate some anonymized data for you. Jdlrobson (discuter) 1 octobre 2020 à 02:56 (CEST)

For starters, I would be interested by investigating about MediaWiki:Common.js (there is no image lazy-loading on desktop site? so where/when do we have no image?) and MediaWiki:Gadget-CatsaGauche.js (by merely looking at the code, I think your fix wasn't correct). od†n ↗^blah 2 octobre 2020 à 06:42 (CEST)

Regarding

var ThisAlt = ThisBox.getElementsByTagName('img')[0].alt;

- there was an instance on https://fr.wikipedia.org/w/index.php?title=R_Leporis&action=submit

at GeoBox_Init/</< URL1:7:882
at each URL2:203:2
at each URL2:201:2
at GeoBox_Init/< URL1:7:808
at each URL2:203:2
at each URL2:201:2
at GeoBox_Init URL1:7:591
at fire URL2:244:209
at fireWith URL2:245:402
at fire URL2:1201:482
at ready.js/< URL2:1319:146
at mightThrow URL2:247:149
at resolve/</process< URL2:247:808

Regarding

NotFoundError: Node.insertBefore: Child to insert before is not a child of this node

- this error was much more common, however unfortunately the stack trace not too useful (simply at CategoriesAGauche). It occurred on various pages including Circonscriptions_législatives_des_Français_établis_hors_de_France, Manoir_de_Crux Ferme_du_Clos-Montfort - note that users might be running gadgets that make the HTML incompatible in all of these cases so I think defensive programming in general is always a good idea with gadgets. I'm not seeing any recent occurrences of these errors so I think the changes you made were fine - so thanks for the follow ups on them! Jon (WMF) (discuter) 2 octobre 2020 à 07:46 (CEST)

MediaWiki:Gadget-DotsSyntaxHighlighter.js

Hello, I don't understand how this error could have happened… In the setup() function, we have this line:

syntaxHighlighterConfig.voidTags = syntaxHighlighterConfig.voidTags || syntaxHighlighterSiteConfig.voidTags || ["br", "hr"];

od†n ↗^blah 19 octobre 2020 à 05:03 (CEST)

Similarly, I don't understand this error in LiveRC. Theoretically the getPageInfos() function is called beforehand and ensures rc.langlinks is a defined array. od†n ↗^blah 19 octobre 2020 à 17:56 (CEST)

Is it configurable? I suspect somebody might be setting syntaxHighlighterConfig.voidTags to something that's truthy but not an array

e.g. syntaxHighlighterConfig.voidTags = true;

or

e.g. syntaxHighlighterConfig.voidTags = "br";

If it's not configurable and the code cannot get into a truthy non-array state it's possible somebody is modifying the script via globals as it's being made accessible on the window object - the solution for which would be to localize it to a var instead. Does that make sense? Jon (WMF) (discuter) 20 octobre 2020 à 17:55 (CEST)

I ran several searches, and nobody uses this voidTags setting. The only scenario I can think of is someone that would be modifying the setting directly on their browser, e.g. via a Greasemonkey script. We can't support such scenario (Greasemonkey + a completely wrong setting value), they would be countless… Does the error happen on only one IP?

od†n ↗^blah 21 octobre 2020 à 14:10 (CEST)

MediaWiki:Gadget-HotCatsMulti.js

Hello,

Your edit seems to have broken MediaWiki:Gadget-HotCatsMulti.js, as reported by several users here since about the time of the change. Symptom: the interface buttons of HotCatsMulti simply do not show up in the category bar of any page. It was working yesterday. I'm seeing this on Chrome V88 (did not try another browser though). Note that on French Wikipedia HotCatsMulti behaves and is coded much differently than on other wikis such as en (I don't know why, maybe it shouldn't). Place Clichy 12 mars 2021 à 11:44 (CET)

This seems to have been fixed by this other edit (replacing undefined by null), which had been requested here. Place Clichy 12 mars 2021 à 16:01 (CET)

MediaWiki:Common.css contrast issue

Hi!

I have noticed that this modification has caused a contrast issue on certain pages. For example, on "Aide:Wikification", the "Niveau débutant" label has become black on a dark green background (see previous appearance). What are the possible options to fix the contrast issue while remaining compatible with the night mode?

Thanks. SleaY ^[contacter] 26 février 2024 à 06:27 (CET)

Sorry for the delayed reply! Thank you for flagging that. This should now be fixed in around 5 minutes or so. Jon (WMF) (discuter) 29 février 2024 à 22:28 (CET)

Hello and thank you for the response. If this action was sufficient to correct the issue for the beginner level, I presume the same action could be done for the advanced level (L-1948) and the expert level (L-1954).

Best regards.

(In accordance with the WP-FR rule that requires translating all messages into a foreign language, here is the translation.)

Bonjour et merci pour la réponse. Si cette action a été suffisante pour corriger le problème pour le niveau débutant, je présume que la même action pourrait être réalisée pour le niveau avancé (L-1948) et le niveau expert (L-1954).

Amicalement.

(En accord avec la règle de WP-FR qui demande de traduire tous les messages en langue étrangère, voici la traduction.) SleaY ^[contacter] 1 mars 2024 à 19:09 (CET)