This issue doesn't appear on Zastava M 98/48, Zastava M59/66, Vz. 98/22

In T419143#11678494, @jpxg wrote:

In T419143#11678431, @MBH wrote:

Some investigation was made in Russian Wikipedia discord chat, maybe it will be useful.

1. In 2023, vandal attacks was made against two Russian-language alternative wiki projects, Wikireality and Cyclopedia. Here https://wikireality.ru/wiki/РАОрг is an article about organisators of these attacks.
2. In 2024, ruwiki user Ololoshka562 created a page https://ru.wikipedia.org/wiki/user:Ololoshka562/test.js containing script used in these attacks. It was inactive next 1.5 years.
3. Today, sbassett massively loaded other users' scripts into his global.js on meta, maybe for testing global API limits: https://meta.wikimedia.org/wiki/Special:Contributions/SBassett_(WMF) . In one edit, he loaded Ololoshka's script: https://meta.wikimedia.org/w/index.php?diff=prev&oldid=30167202 and run it.

I will be writing this up for the Signpost, so if you have the actual code, I would be curious to take a look at it for myself (I don't know if there are private messages on Phab but EmailUser on the English Wikipedia should work for me).

Update as of 17:09 UTC, the wikis are back in read write mode, but some functionalities are still disabled.
Unclear which functions.
This started with code at https://ru.wikipedia.org/wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Ololoshka562/test.js
I won't repost the since-deleted code, but I have saved it if someone is curious.

Does this check for the presence of wikimarkup in pasted content? It's not out of the question a newbie would paste template/article content.

In T394503#10829797, @Aklapper wrote:

Please paste text (such as full error messages) as plain text. Text in screenshots cannot be searched for and cannot be copied. Thanks.

@Jdlrobson -- Go to a category that displays non-copyright restrictions (https://commons.wikimedia.org/wiki/Category:Communist_symbols)

There can be duplicates that appear in a patterned order, even.

@Nurg -- just a heads-up, you revealed your IP in the previous comment.

The error rate seems to be decreasing. https://downdetector.com/status/wikipedia/

Or four times!

@Pppery -- Could I ask you please copy another comment over to UTRS?

Many thanks!

I got this on enwiki w/ Chromium v126 (Falklands War)

In T379859#10329433, @Pppery wrote:

I can't see F57711575 and I don't think an image is necessary here anyway

After testing without uBo, I am quite sure Pcoombe's explanation isn't universally applicable.

Able to reproduce on several subcategories (hopefully it's obvious I didn't choose which at random) in https://commons.wikimedia.org/wiki/Category:Non-copyright_restrictions

@Pcoombe --
I cleared cookies and disabled uBO. The donation prompt's dismissal points me to the sidebar. (Granted, I'm unsure of a reliable way to confirm this due to the delay between each prompt. There's a slim chance I cleared cookies before disabling uBlock, possibly confusing the script that looks for the donate link position)
As I was writing post-cookie-clearing, the same issue occurred with yet another of the donation messages.

In T378997#10297705, @Pcoombe wrote:

I use uBlock Origin to hide the donation button

Well, there's the issue.

The donation link used to be in the sidebar menu, but we moved it to the top right of the page on desktop for logged out users (T372757). However there was an overlap where some sites had the link in the new position, and some in the old. So the banner close tooltip checks the top right of the page for the donation link, and if it doesn't find it there it falls back to the sidebar menu. If you're removing the link then obviously that will confuse things.

I could probably change it to not show anything if there's no donation link to be found on the page, but it's not a priority right now.

This one works fine:

This one works just fine:

The same issue appears with the 'Wikipedia can't be sold' message. Couldn't get a screenshot...

I was able to see this on a different device, hopefully I can clarify things with the attached screenshots. First off, I use uBlock Origin to hide the donation button (on some devices, anyways).

I'm going to have to side with the collective here. An enormous amount of work was put into VideoJS, but unfortunately it is rather antiquated. If someone has a shiny new alternative ready to be rolled out, I'd happily welcome that in a heartbeat.

Good catch--readers. It escapes me why there exists a difference between the two.

You would be right, great catch

@Jdlrobson -- Any ideas on what's causing this behavior? Hopefully I elaborated enough for you to duplicate.

Here's a video and a frame from the video:

Weird. Chrome 129 for me, logged out. This was slightly easier to reproduce on a low-end laptop
I have uBlock Origin turned on, perhaps it's not out of the question that it misbehaved.

It's gone there, but reappears:

@Jdlrobson -- good catch. thanks!

In T374871#10232743, @TheDJ wrote:

These were added by explicit request of the edit community (specifically image curators). They indeed probably aren't very useful to the average user, but the editor community tends to take a stance that the opportunity for users to learn and understand the details of copyright is important, even if it educates only very few users. The ticket adding them was pretty recent 2018?? I'll see if I can find it back.

@Jdlrobson —
The icons do in fact have tooltips (although the icons and their alt text don't appear at all on mobile, meaning only about a quarter of line|2-year|access-site~mobile-site*desktop-site|monthly|all unique devices see the darned things in a given month (assuming pageviews are evenly distributed)... Even as an editor, the icons don't serve too much purpose, but from a legal standpoint it might be sensible to maintain the trademark and seal/currency disclaimers. I'm not a lawyer, nor do I play one on TV, and trademark law is an especially intuitive field, at least for me,

Back up again. Resolving...

I think it's fair to assume that relatively high-age accounts with several edits are experienced users, but there could be several categories (5 uploads, 30 days; 10 uploads 1mo; 6mo 20; etc).

@Prototyperspective -- Fixed! Good catch with respect to the broader reach of T376137

Fixed, good point. I was unwisely thinking about date only. For whom this might be helpful, example screenshots of the issue are below
{F57589382}
{F57589384}

This is definitely fairly prominent.

@Pppery -- good catch!

I am again able to replicate the footer bug, although only on ChromeOS desktop v128. The latest version of Chrome on MacOS doesn't exhibit the spacing issue.

With respect to your first point, that makes perfect sense (while I don't feel much harm could come of creating nasty URLs, it's certainly a risk). Well explained! With respect to the second point, I was pleasantly surprised to find that Phabricator has an email reset (though I have only found two instances of Phabricator accounts being disabled due to vandalism, so it may not be worth putting in the effort to auto-disable Phab accounts when locked).

Blocking page purge makes some sense (spamming it?), but may I ask why blocked IPs cannot use the URL shortener?

Wikitionary now does something similar to what's been proposed (with less rich text, granted)

For what it's worth, the preview for ISBN appears brown (but mostly imperceptible) in its preview.

I have to agree with T233741 and your assessment of a possible solution. Anyways, given how few settings are available, it probably shouldn't have its own page (perhaps for logged-in users, it's different on mobile than when I last checked). Either way, it feels unintuitive for there not to be a button returning the user to the previous page.
Cheers!