"I'm not sure how widespread this error is going to be"

I provided FF68 as an example for reproduction, as can be seen on caniuse most browsers started supporting this about a year ago so FF83 should be affected too. (and IE, Opera Mini, UC browser for Android, QQ browser and KaiOS browser don't support it either according to caniuse) I don't know how many people use a browser that doesn't support this feature.

The message has changed:

As this will never happen anyway, one less open ticket..

In T100974#7586986, @Tgr wrote:

Is there any wiki where it's acceptable to block a good-faith user without any kind of talk page message?

Personally, I'd much rather see functionality to make sending such messages easy.

"If someone could purge.. that should fix it"

e.g. in a cookie

Can someone do the thing again? It expired today.

YouTube would be able to detect that and automatically serve up whichever format is hardware-decoding supported on the user's machine - it doesn't appear to do that... but that's assuming that they would do that. :) )

YouTube is Google, so they have an incentive to push VP9/AV1.

It would be interesting to try and figure out the current capability set that's out there..

There's also https://store.steampowered.com/hwsurvey which is obviously limited to Steam users and desktop, but can provide some level of insight anyway.

(Note that the reason we're not on h.264 is the patent licensing requirement; until that gets resolved -- either by waiting until 2028 for the patents to expire or overturning the 2014 Commons RFC and reinterpreting or changing the foundation's open file formats policy -- we are stuck working around it with other formats.)

Based on https://meta.wikimedia.org/wiki/Have_the_patents_for_MPEG-4_Visual_expired_yet%3F I'm pretty sure MPEG-4 Visual (which is NOT h.264) should be fair game by now. (but we should ask legal to be certain) The Philips patent should be irrelevant (likely optional to implement in decoders and decoders are the user's problem), but any MPEG-4 rollout wouldn't happen before 7 December even if you started today, I think. MPEG-4 Visual works in an MP4 container and IIRC that worked well on Apple devices. (the primary problematic platform for this) And even software decoding is cheap as chips as it's 20+ years old. I thought there was an existing ticket for that, though I can't find it. (pretty sure brion posted some test files in it, maybe he remembers)

Not really, because if {{DISPLAYTITLE:}} is used, it replaces those extra elements.

So you could ditch .mw-page-title-namespace,.mw-page-title-separator, and replace .mw-page-title-main with a <span class="mw-page-title-displaytitle">new title</span>?

I think this is the correct behavior on our side

No chance you could just update .mw-page-title-namespace,.mw-page-title-separator,.mw-page-title-main?

Should work fine now.

OOOOOOOH now I see what matmarex was going on about when they said discussion activity had to be appended to the header element. (T314714)

Note: I just noticed my talk page has 365 days left on my watchlist. Did someone double the limit? (if so, thank you!)

https://en.wikipedia.org/wiki/MediaWiki_talk:Gadget-EditNoticesOnMobile.js#Edit_request_22_September_2022 should solve it.

I'll look at it. This would indeed be an issue with browsers not supporting ES6. ENOM was never tested on ES5 actually, but with any luck Object.values is the only problem. I already wrote ES5 implementations of several ES6 functions at https://en.wikipedia.org/wiki/User:Alexis_Jazz/Factotum-IE11.js which includes Object.values, so a little copy-paste should solve it.

"because it didn't work with the collapsible sections in MobileFrontend"

anoneditwarning != editnotice

"What is the broader use case? Why does a person want the site to tell them when they were last there?"

If there had been errors I would have probably mentioned them. There are indeed no userjs- options in the saved copy.

In T316177#8199226, @DLynch wrote:

How about the other way around? Have your solution read mw.user.options.get('gadget-EditNoticesOnMobile') and disable itself? (only works if/when/where EditNoticesOnMobile is available as a gadget though)

If we're supporting gadget replacements at all for this feature, which we are, I'd rather let our version (which is inherently going to be distributed to all wikis because it's inside VE) be disabled by many gadgets rather than us needing to explicitly update it to support any other gadgets that come along. E.g. some wiki might want their own implementation rather than ours or yours, or someone who intensely dislikes edit notices could make a gadget that just disables the core implementation without replacing it...

In T124101#7314869, @AlexisJazz wrote:

@MarkTraceur @CBogen @Tgr can someone investigate https://upload.wikimedia.org/wikipedia/en/d/de/Logo_of_the_International_Practical_Shooting_Confederation.png ? This one's interesting because it's both recent and the only revision (before my overwrite) went missing.

Right. How about the other way around? Have your solution read mw.user.options.get('gadget-EditNoticesOnMobile') and disable itself? (only works if/when/where EditNoticesOnMobile is available as a gadget though)

"What code would need to be added to EditNoticesOnMobile.js suppress the upstream mobile edit notice implementation should volunteers at en.wiki to do this?"

Vector classic/Timeless/Monobook only.

All Wikipedias with >300 active users and all sister projects of those (Wikibooks, Wiktionary, etc) are now tracked on https://meta.wikimedia.org/wiki/User:Alexis_Jazz/GUS2Wiki.json.

Never mind, the additional API call turned out to be useful to restrict how often the page is updated. So no longer an issue for me.

Can you provide more examples of the bad data from affected revisions? The –; at the start feels suspect to me, could it be a delimiter that isn't supposed to be there?

In T311308#8113569, @Umherirrender wrote:

In T311308#8026100, @AlexisJazz wrote:

I'm thinking maybe this is a kind of edit conflict, my script changes two different preferences at practically the same time. I wouldn't expect an issue since it's not the same preference, but maybe it's an issue anyway.

Point 1:
The preferences are handled as one. To change one preference all preferences of the userid are read from the database, the change is applied to that data and the according changes on the database are done with DELETE + INSERT. It seems the global preferences is using REPLACE + needed DELETE, not sure if that makes different on locking.

Point 2:
According to the Etiquete https://www.mediawiki.org/wiki/API:Etiquette avoid parallel requests, just combine both in one query to improve performance

Also for the record, I've provided a smaller and simpler mw.deflate alternative in T312720#8098113 as well as its mw.inflate counterpart.

First of all, I wouldn't say anything would be censored. The images will still be there in the articles themselves.

You have a personal and purely subjective cultural hang up about sex. Ok, fine. However it would be culturally imperialistic for us to impose your opinions of "offensiveness" on the world, while denying or denigrating the equally subjective and equally cultural and equally legitimate concerns of people demanding that Images of Muhammad be removed. And then there are the equally subjective and equally cultural and equally valid demands to censor any image of any woman-not-wearing-a-burka.

Due to ongoing issues with the hacks to work around T313140 the second wave has been temporarily put on hold. The issues should be fixed in my userspace version, but we somehow have no testers for the userspace version and after matmarex notifying me of ENOM accidentally (and unintentionally) now fixing T313140 globally I'm no longer confident enough to rely on my own testing before asking for the MediaWiki: version to be synchronized with the userspace version.

Obviously nothing actually relies on that as this only affects windows which have a symbolic size specified, so any such window is already known to become windowed on a large enough screen.

For some reason fiwikisource doesn't have this issue.

I sort of doubt T312042 is a dupe of this. A megadott hitelesítési token lejárt vagy érvénytelen. is centralauth-error-badtoken from the CentralAuth extension. In English that's The provided authentication token is either expired or invalid.

In T312042#8099494, @Aklapper wrote:

See https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems in theory. Also, browser info and browser version info are always welcome.

Pako (combined deflate+inflate version), stripped support for browsers without TextEncoder/TextDecoder:

Vector classic isn't 100% immune either, but this happens way sooner with Vector 2022 due to the absence of an inline TOC, a much wider sidebar, a longer sidebar due to the TOC being there and the inability to stretch on larger displays,

<s>Don't know if this helps at all, but it works..</s> Nope it's broken, base64 breaks on 1+byte characters.

In T281974#7657210, @Jdlrobson wrote:

Okay thanks. So I made a few adjustments and completed my edits.
Is this a suitable compromise (at least as a short term fix? )

I'm not active on euwiki but I wouldn't be thrilled about it. As a short term fix though, could work, but without a very clear definition and follow-up I'm afraid that "short term fix" will end up lasting for 5 years until someone figures out what happened and fixes it. So without a strict definition of "short term", I'd have to advise against any "short term fix".

Odd that I missed that fact. As Wikimedia wikis don't set $wgGadgetsRepoClass to 'GadgetDefinitionNamespaceRepo' it's unused, but the namespace still exists.

In T235237#8085072, @Esanders wrote:

This task is about using CompressionStream to improve performance. Please don't use it to complain about another task not getting prioritised.

In T121049#8084239, @SD0001 wrote:

In T121049#8083303, @AlexisJazz wrote:

https://en.wikipedia.org/wiki/User:Alexis_Jazz/GUS2Wiki

Takes 2-5 regulars per project. (someone using it has to visit the wiki when the stats have been updated, a single regular who never misses a day would also suffice) Currently just overwrites the page so for history you'll have to dig through the page history.

You could just write a toolforge cronjob that does this nightly using a bot account. Making it a userscript that edits silently from a human account whenever they log in seems silly.

Takes 2-5 regulars per project. (someone using it has to visit the wiki when the stats have been updated, a single regular who never misses a day would also suffice) Currently just overwrites the page so for history you'll have to dig through the page history.

In T259532#6384651, @Etonkovidova wrote:

Thanks @AlexisJazz - there is an issue of re-sending notification (a curly bracket in this case), but I could not find the exact steps to reproduce the issue you describe (two identical notification for the same issue). It'd be great if you can provide a screenshot of the Special:Notification page or the drop-down Notification flyout to show the duplicate.

Better late than never, eh?

EditNoticesOnMobile now stores CRC32 checksums of edit notices in localStorage and only keeps the notice text itself for 2 hours instead of 48 hours. This made sense because the notice was only served from cache without an API request if it was less than 2 hours old. The checksums are stored for 2 weeks as they are much smaller. So unchanged notices can be detected for 2 weeks now instead of 2 days.

I fixed it in EditNoticesOnMobile. If there's anything in that hack that might inspire a patch, copy-paste whatever you can use. It's WTFPL after all.

In T312299#8082415, @matmarex wrote:

It really should cut it, because that's the size of screen of real devices used by real users. If the notices on en.wp are not suitable for mobile devices, then they should be adjusted. In desktop VE, we show notices in a 320px popup and in my experience for the most part that works just fine (I've seen some bad ones, but they're a minority).

In T312299#8082183, @matmarex wrote:

Maybe @matmarex and @Esanders have ideas for how the size of the OO.ui.alert can be constrained...

When you use OO.ui.alert(), the default size is 300px, you're currently overriding it to be wider by using size:'larger'. At 300px this wouldn't usually be a problem. But there's currently no way to make it wider than that without it becoming fullscreen when it would exceed the width of the screen.

The RfC to enable the EditNoticesOnMobile gadget by default on English Wikipedia has passed. Deployment details are now being discussed on https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile.

The RfC to enable the EditNoticesOnMobile gadget by default on English Wikipedia has passed. Deployment details are now being discussed on https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile.

@ppelberg where can I see the open question on whether to include functionality like T312999 ?

In T312299#8080135, @ppelberg wrote:

In T312299#8080015, @AlexisJazz wrote:

@ppelberg: please have one more look, also at the source. I swapped out some delays for MutationObserver. The OO.ui.alert has been swapped out for an OO.ui.confirm which is essentially the same as the alert, but when a notice is revisited (using the alert button) it gets an extra button to disable automatic popups.

If the user decides to do this there are two confirmation popups before it's accepted. You've seen the response to the RfC and the wishlist entries, I couldn't make it too easy. But it is generally accessible (no need to mess around with common.js) so your concern of users editing less should be at least somewhat alleviated.

Is there anything I need to do to the script I've saved to en:User:PPelberg_(WMF)/common.js in order to try out the changes you're referring to above? It'll be easier for me to understand what you're saying by trying it out for myself, if possible.

Replace what you copied with {{subst:User:Alexis Jazz/EditNoticesOnMobile.js}}?

@ppelberg: please have one more look, also at the source. I swapped out some delays for MutationObserver. The OO.ui.alert has been swapped out for an OO.ui.confirm which is essentially the same as the alert, but when a notice is revisited (using the alert button) it gets an extra button to disable automatic popups.