Still a problem: I finally turned "Hide my edits from the watchlist" on in Preferences and it didn't do as expected. Especially when I've done a batch of edits to pages that are on my watchlist, for the rare instance when someone else touches the same group of pages, not much else is visible on a Watchlist display. It's disappointing that this setting has ben ignored for so long (although as I have just admitted I hadn't actually been using it).

"...with fewer characters of plain text..." If the distinction lies with the intervening newline, then possibly related to the WikiFunctions::Parse::UnbalancedBrackets.cs::DoubleSquareBrackets Regex not having RegexOptions.SingleLine? I haven't had the brainwidth to unwind the Regex, but SingleLine/MultiLine errors are all too familiar.

"This won't be possible when combined with ucuserprefix, of course..." I assume the same is true for uciprange (unfortunately, because a:b:c:d::/64 is frequently all the same user).

@Jdlrobson My apologies; I had not realized the implication of the linked entry (in my defense, I was too much triggered by the word "expected", but that's my fault not yours). I'll get off my high horse and temporarily go back to classic Vector. Is there a task I can track that will tell me when the better solution is rolled out?

Sorry, but closing this as "by design" is unacceptable if Vector-2022 is to become the default for new users. On Windows, docking to the left or right, so that the user can see two portrait windows side-by-side, was promoted as a common practice for those of us who suffered Windows 8, and I can't imagine I'm the only one who still has it as part of the normal workflow. Now, on most screens with an HD-like aspect ratio (somewhat old 1920x1080, or today's 2736x1824 at 175% OS scaling), docking to one side results in [https://1drv.ms/u/s!AtuCZY0YF4hGpK07b9IGdnUnGtV3_Q this] view of the main page. Is that the initial impression we want to give? I'm going to have to revert to Vector-2010 until this problem is addressed.

I should have specified that the examples have display=title (or inline,title) as parameters to the coord template.

I reported this bug at Village Pump using Edge, and reported that Chrome did respond to clicks. If someone else has repro'ed it in Chrome, then that's OK with me, but I'd like to be sure the fix applies to Edge too.

I need to generalize this bug report: when correcting an interwiki link to a nonexistent page, an iwlinks query does not pick up the correction if the changed text HAS THE SAME LENGTH. I first noticed this in a few cases where only capitalization was changed, but obviously that's a subset of the "same-length" bug.
Example:
https://en.wikipedia.org/w/api.php?action=query&prop=iwlinks&titles=Eildon%20Hill
Should list prefix: "s", *: "1911_Encyclop\u00e6dia_Britannica/Eildon_Hills, but doesn't.
The "recent change" in question was to correct the EB1911 link from "Hill, Eildon", which is the same length as the correct "Eildon Hills".

How long is too long? I really have no feel for what the official parsing logic does, but (with obviously apologies for still appearing to self-promote) my fairly simple-minded approach currently runs 3.5 seconds from the end of download to installing the highlighted text in the UI control, for two fairly large articles ("West Virginia" in both WP and EB1911), and last time I used earwig I was getting pretty comparable results. That's on my Surface 4, an Intel i5 2-core laptop. I mean, if that's significantly longer than the server, then I'll step back, but otherwise you're free to re-use the logic (I realize C# to py may be a problem).

From the for-what-it's-worth department, I have thrown together a clean-room simplified implementation of only the "URL comparison" feature in a Windows exe creatively called "Copyvios". It has limited applicability (i.e. it scratches my own personal itch so far as the exterior URL is concerned) explained in its README. It does the comparison in a few seconds at most, and the result is broadly comparable with the online tool.

@Earwig I was going to ask: Purely selfishly, how easy would it be to break out the "URL comparison" feature into a separate tool? Presumably it uses fewer resources, and (as I said, purely selfishly) it's the only feature I use.

Thanks for the efforts so far. Hope you can track it down.

It came back briefly, but it's gone again. From where I am, it connects to the server and then 504's after 3 minutes.

Looking (for the first time) at that grafana graph, and due respect to your 30% calculation: the usage reported there was spiky for the first ~9 days, but went to an almost-solid 100% about them time we noticed the timeouts.

Ah, that makes it more complex. Again, I guess there's no evidence that anyone else is encountering the API failures due to an out-of-date security infrastructure; AWB for example still uses fx 4.5 but the code must have been fixed well back, so all seems well. I know I've been heard, so you can put this on infinite backlog.

Suggest: near the top of the /sec-warning file, add an HTML comment:

Yes, an HTML comment, embedded near the top of the page text, not in the response headers. I called it an XML comment because it's in the XML format. Sorry if that was a misdirection. It probably belongs properly in a <HEAD> element (actually, so does the TITLE).

I want to dispute the closing of this because I was specifically asked by the other folks in the linked task to open this separately. Can you get together and decide how to handle it? As I said, it's probably moot but that's not for me to decide.

Closed as suggested. Sorry about the delay; I'll open another ticket although it's rapidly becoming moot. Is this the equivalent of "By Design"?

Thanks, BBlack, for the obvious thoughtful care that went into this. And, in my case, it had the desired end-result, although I had to read to the end of the page to get me started.

Oh, goodness, my thinking is muddled today. Blame a cold.

Thanks for picking this up. I assume the answer is buried deep in XmlDocument.Load(). According to the stack trace it's System.Xml.XmlTextReaderImpl.ParseEndElement() that gets upset. But you're probably right; I didn't look critically enough. The <IMG> element isn't closed.

I don't know if this is late to the game, but from the perspective of one who uses the http API: in the past 2 weeks or so, on en.wikipedia.org, a multi-user "usercontribs" query went from always returning immediately (sub-second) to always timing out. Is this change intended to fix that?

Your issue isn't really related to this task. But I suspect it'll be fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/461440, when that gets merged.

I was sent here from a thread in mediawiki.org API talk:Usercontribs. On the English Wikipedia, in recent days, a simple usercontribs list request with two ucusers has changed from always responding immediately (sub-second) to always timing out. Here's the actual URL I recently tried:
GET /w/api.php?action=query&format=xml&list=usercontribs&ucuser=DavidBrooks%7CDavidBrooks-AWB&uclimit=20&ucnamespace=0&ucprop=title%7Ctimestamp%7Ccomment%7Cflags&continue= HTTP/1.1

I thought that might be the case. Just wanted to be sure you were aware.

Repro steps work - thanks for the quick fix.

Confirmed: I just downloaded version 5700. When trying to switch projects, the UI says it cannot load Newtonsoft.Json, version 7.0.0.0. The version in the download zip is 6.0.8.18111.