In T367982#9915003, @Mondo wrote:

I've noticed this a couple of times in Timeless, too, so it's not limited to Vector.

In T237244#9783122, @matmarex wrote:

I'm trying it on myself as an experiment: https://meta.wikimedia.org/w/index.php?title=User:Matma_Rex/global.css&oldid=26746343

A build on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/1048488 failed with "T282893: Expected host directory /srv/jenkins/workspace/quibble-vendor-mysql-php82-noselenium/log to exist but it does not."

Oh, interesting, it looks like it only happens when a CAPTCHA from the ConfirmEdit extension is enabled. So in Wikimedia production, this will affect users who add an external link in their first edit.

The problem is more clearly visible in various glossary articles, for example:

• https://en.wikipedia.org/wiki/Glossary_of_cue_sports_terms#1–9
  
• https://en.m.wikipedia.org/wiki/Glossary_of_cue_sports_terms#1–9
  

I can't reproduce this today.

Fixed by the changes in subtask.

In T368102#9913395, @PerfektesChaos wrote:

My code is following a documentation of .textSelection(encapsulateSelection) maintained since about 2010, meanwhile deleted, in mw:ResourceLoader/Core modules now pointing to doc.wikimedia.org which tells 404.

Therefore no proof and no valid documentation is available, what the contract on using textSelection did contain and what has been promised for a decade.

I swear I did follow the documentation always and in all details.

In T356196#9913655, @matmarex wrote:

• It crashed on simplewiki on this comment: https://simple.wikipedia.beta.wmflabs.org/wiki/User_talk:112.135.29.135#h-Quick_deletion_of_சித்திரைப்_புத்தாண்டு-2011-06-29T00:28:00.000Z

Running the maintenance script on all wikis on the beta cluster

Minimal reproduction: $( '#wpTextbox1' ).textSelection( 'encapsulateSelection', { pre: 'A', peri: undefined, replace: true } )

To be honest, I doubt this affects anyone except you, since that discussion also says (if I understand correctly) that this hidden feature was never documented correctly. But it does seem like a bug.

I found your discussion on de.wp which gives actual steps to reproduce: https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#c-PerfektesChaos-20240620175000-BUG:_Wort_„undefined“_erscheint_bei_der_Quelltextbearbeitung

Caused by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/1043758

I guess this task is rejected then. I'll have to try to get used to the new footer.

I think that @Mdann52 is working on a bot to correct all of these files. I saw this linked in some discussion on en.wp: https://commons.wikimedia.org/wiki/Commons:Bots/Requests/Mdann52_bot_2

I see the section names in the example you provided. Can you clarify what output you're seeing, and what do you expect to see instead?

Hi, I saw this issue reported a few weeks ago (I watch DiscussionTools bug reports), but I didn't find the time to investigate until now, especially after I saw it was marked as resolved.

User-notice proposed text: (using the same wording as when the feature was announced in Tech/News/2024/05)

Some of the permanent links to talk page comments, which can be copied by clicking on a comment's timestamp, did not work when the topic title was very long and the link was used as a wikitext link. This has been fixed.

It's a bit weirdly technical, but that's the best I came up with. Improvements welcome.

Sorry it took us a while to get back to this. I'm now busy working on CentralAuth with the MediaWiki Platform team, and the rest of the Editing team is busy working on Edit check and other projects.

I actually have a patch ready to get patchdemo fixed. Just needs someone giving me rights in the repo to I don't need to fork the whole repo. (I know but I'm used to gerrit)

Also… why was MediaWiki's own icon made bigger? It doesn't look good, and it makes it more difficult to keep custom icons consistent with different MediaWiki versions.

I see now that you've mentioned it in release notes, but this still seems unnecessarily disruptive to me. Sites and extensions that add to $wgFooterIcons may not like this styling for their icons (the config variable is called "icons" after all, not "buttons"), and maintaining multiple icons for different MediaWiki versions will be annoying. If you want to decline this, I'll live with that, but I expect that there'll be some grumbling along these lines from other folks in the future.

I'll make patches for all the extensions too.

That seems to work!

• Before: https://patchdemo.wmflabs.org/wikis/1a27a5e689/wiki/Special:GlobalUsers
• After: https://patchdemo.wmflabs.org/wikis/a491434c7c/wiki/Special:GlobalUsers

It seems there's no documentation for this that would need to be updated:
https://www.mediawiki.org/w/index.php?title=Special:Search&profile=all&search="runMaintenance"&fulltext=1

Could be caused by rMW30287f6be67d: Temporary accounts: Create user on edit save attempts or some related work. Maybe just requires tweaking the assert parameters here? https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/08b62bc0682b4c07456c5344d8b9745ec0cbb17e/modules/CommentController.js#437

Probably caused by rMW7f588780a048: Support multiple matchPatterns in temp user autocreate config

Caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1027178

I do like the idea of using two toast messages, my question is how long would the second toast message display for? Or if it is permanently visible as suggested, then my assumption is users click on it to dismiss, and I wonder if all users will understand that this is how to dismiss the message?

We got in touch with the design team, whose response is here: https://docs.google.com/document/d/1DQM_xi7fK2_YfFMV6mulGYTxmmr_tADHRhLrI7x-jMk/edit#heading=h.e4e6d6c4proc

The az errors stopped with wmf.9 deployment. I deleted the override: https://az.wikipedia.org/wiki/MediaViki:Log-name-tag

For the other websites, I took a few screenshots for reference. Some of these integrations aren't very good looking.

We probably won't use the popup approach in the end, so I will cut this investigation short, but I wanted to note what I have already learned. I had a closer look at https://archive.org/donate and the two popup auth providers available there. Observations:

This task was previously declined.

I think the new behavior is standards-compliant, and the old one is incorrect. The file has a <g> element inside a <clipPath> element, which is apparently not allowed: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/clipPath#usage_context (and was never allowed, here's a spec from 2001: https://www.w3.org/TR/SVG10/masking.html#EstablishingANewClippingPath).

More context:

• It's trying to show a notification about this edit: https://www.wikidata.org/w/index.php?title=Q1138776&diff=prev&oldid=2173575677 which added a pagelink to wikimaniawiki page "2024:Venue"
• The username The_monster_is_my_thing_ill_do_this_if_im_thing is truncated to The_monster_is_my_thing_ill_do_this_if_, which is 39 characters, a very unusual length. I searched Echo code for that number and found that event_agent_ip field is 39 bytes: https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/2a4e100a322fe5a28ad54883d47d2daa0f954765/sql/mysql/tables-generated.sql#10

In both PHP and JS code, this ends up being represented as an array with a gap – try $request->getArray( 'preloadparams' ) in PHP, mw.util.getArrayParam( 'preloadparams' ) in JS.

Took me just a few minutes to find affected articles on Wikipedia. https://en.wikipedia.org/wiki/List_of_presidents_of_Burundi (and lots of other articles in https://en.wikipedia.org/wiki/Category:Lists_of_national_presidents)

Maybe, but this is still very unexpected behavior.

@TheDJ I may be misunderstanding your suggestion, but I don't think that would help – the text would still be laid out using the flex layout, which would interfere with the normal line wrapping. My solution is to remove the display:flex where it wasn't supposed to apply (it should be applied only to the wrappers around the headings containing the section toggle, the heading text, and the section edit link [and optional DiscussionTools stuff] – not to the heading text itself, but it was applied there erroneously due to a conflict between styles for the old and new headings).

Excusing myself and the folks who were added to the project to have access to Patch demo (which is in this project for historical reasons, and which is running on a more recent VM already).

That's my bad, sorry. Your investigation is exactly right on all counts. I will get the fix deployed soon (Monday at the latest).

Production logstash: https://logstash.wikimedia.org/goto/ca022838d6eb4b350437e62dfe42ab66

I concur, it seems like unnecessary work at this point.