after swiping down to refresh

I didn't try changing prefs but at least it works for my case now. 2.7.50434-beta-2023-03-27.

I have basically the same experience as Legoktm majority of the time but occasionally a login attempt is successful. then to reproduce again I clear quarry cookies, get 500 again. last attempt took about 5 tries 500 before I had a successful login.

In T331820#8698824, @doctaxon wrote:

further three are missing when searching: https://de.wikipedia.org/w/index.php?fulltext=1&search=%22Auguste%20Bock%22&title=Spezial%3ASuche&ns0=1

Request from xxxxxxx via cp1080 cp1080, Varnish XID 657590799
Upstream caches: cp1080 int
Error: 404, Not Found at Tue, 14 Mar 2023 16:07:36 GMT

In T318039#8294142, @ABorbaWMF wrote:

Tested on 2.7.50421-beta-2022-10-03

https://github.com/gopavasanth/wmhack-map

also the footer needs a link to source repo and many source files that say All Rights Reserved in header need fixing.

lmk if you need more deets e.g. I could snoop on the Ajax traffic and look at the JS console.

In T307977#7920003, @Sebastian_Berlin-WMSE wrote:

This should allow you to use the workaround that I mentioned. Let me know if it still doesn't work.

same as Dominic. and I also tried starting from scratch in incognito session. but with the same commons account I was using before.

@Amire80 ok thanks, can you fix ru also?

replicated with a fresh install of 2.7.50394-r-2022-02-10

found many= on ruwiki as well. bewiki has the whole screenshot untranslated. (English strings)
(originally wasn't focusing specifically on Cyrillic when checking other langs)

In T290837#7349053, @ssastry wrote:

I made the edit

In T290837#7348973, @ssastry wrote:

Parsoid will not support arbitrary string / token gluing to generate other tokens.

a couple more things

if you're going to do site js/css then might as well do vector js/css as well.
and this may be going too far but some other things to consider:

• vector wasn't always the default so also js/css for earlier defaults
• past versions of wmf-config
• past mediawiki wmf deployment branches

and now force quit doesn't help. so maybe was a coincidence the first time.

got an edit conflict then waited 10+ mins, still was a conflict. (and I was still the only editor today)

@Dbrant what's another example of different phenotypes, same cause? is that policy written down somewhere? if someone just read T115035 and never saw this then they would be unlikely to know they need to also check here to see if it was also fixed when that's fixed.

@Dbrant may be the same cause/fix but clearly not a dupe.

my gut says this is a 5 minute fix for someone that already knows the right part of the codebase. seems there's more than one local cache in the app. a manual refresh immediately after edit updates the rendering but doesn't purge/update the cache used by the in-app editor.

In T268956#6663277, @schoenbaechler wrote:

Looks good to me, moving it to QA signoff.

@schoenbaechler it's from this page I linked in the task description https://commons.wikimedia.org/wiki/Template:Potd/2020-11-30_(en)

see also T268334: Cut off content within “In the news” card

I'm the only editor to that article in more than 48 hrs and following the instructions to refresh and try again doesn't help.

still broken 2.7.50334-beta-2020-11-02

to clarify none of this is on mdot. it's all desktop site just switching local user agent between default and desktop modes. not off the edge of the screen but off the edge of the citoid popup. I think partly maybe depends on the length of that bare URL.

what does standard libraries mean? SUL is for sure not directly possible, I was speculating about something like oauth against mediawiki.org prod.

xyz was sent using exactly the method you request. this has been a feature of our phabricator literally forever (since before it was a production service).

thanks for triaging.

well I don't mind rushing and no one else is bothering to triage at all.

for the record that latest test was [Edit=Require extended confirmed access] (indefinite) [Move=Require administrator access] (indefinite) since 2016-05-07

this is still an issue with Android App 2.1.144-beta-2016-05-09

Please leave this open until actually fixed.