Thanks for letting me whine and posting the update. I verified the clean build. I too am frustrated that there is no UI for these settings. But worse is that the build system doesn't issue an error message when it can't find a reference. That is definitely a bug, although whether in MSBuild or VS I don't know. Never did figure out the join between them.

Strange. Yes on the VS version. I did have UnitTests as startup (don't ask) but fixing that didn't help. And AutoWikiBrowser.exe runs just fine without NewtonSoft alongside, presumably because I haven't done anything that requires its services.

I wonder if a third party can try to repro? I guess there aren't many of us who try to build release packages anyway.

@Prati28: sent email.

I'm still trying to understand why I need a HintPath and you don't. Apparently you don't need the HintPath if the assembly is in one of four places, of which the two relevant here are (a) the output bin directory (which I hope actually means bin\release) but you said you had cleaned that (b) "paths can be specified in the project settings or configuration files". SpecificVersion false and HintPath ..\libs\NewtonSoft.json.dll work for me. While I'm here, CheckPageConverter has build errors due to 12588 but I guess that doesn't matter now.

I always build the entire AutoWikiBrowser solution (F6 in VS2019).

I apologize; I misread the changes in 12588. But I must have something different in my context from yours: I deleted all the bin and obj folders, and the Tortoisesvn checkmarks everywhere are green. I F6 the solution, and still no Newtonsoft in AWB\bin\release. But when I copy the elements of WikiFunctions csproj <Reference> entry to the AWB csproj (SpecificVersion and HintPath) and rebuild it does get copied.

The inclusion of Newtonsoft was removed in change 12588.

Visual Studio 2022 no longer forces a Framework update. I'll reopen this if that changes.

Thinking about it overnight, I realize the suggested fix could be a regression, for those module authors who assume \r\n sequences in the text. An alternative would be to set a timeout on all user-supplied REs (say 2 minutes) and catch the exception with a "please simplify" dialog. But that would be a more significant amount of coding. Given that it's a rare occurrence (i.e. reported once after all this time), Won't Fix would be fine with me.

I suggest a reasonably pragmatic approach would be to replace line 852 with:
if (UserInputTextBox.Text.Contains ("|") && !((IListProvider)cmboSourceSelect.SelectedItem).DisplayText.StartsWith("Wiki search (text)"))
(and remove the comment on the previous line).

Line 852 in ListMaker.cs. Suggestion: any fix can be more or less complex depending on how you want to handle quote counting and escaping. Or suppress the | split in the search cases. And I understand the priority would be low for this probably rare instance.

As a simple user/UI tester, when can I expect a behavior change on enwiki? Still the same misbehavior on Page and User.

I was invited here from T319358: I have some more points, in case anyone here hasn't seen my gripes. And I realize this is a rapidly moving target. Using Vector-2022 on current Edge, and I don't know if I'm an an A/B test.

Well, I still have problems with this:

1. As shown in my screenshot, click User, then click Page (without dismissing User): the Page menu underlays the User menu, which is confusing. At least let the most recently clicked menu show itself (verified using my alternate user without TW active).
2. For dropdown menus, there are two standard behaviors that I observe almost universally. The classic Win32 menu bar, where a dropdown is dismissed by click-away or hover over another menu in the bar. Or the more modern dropdown, where - and I just realized this was one contributor to my problem - the "V" hint at the availability of a dropdown is replaced by a "^" hint, which suggests another click to close, i.e. pull up, the dropdown. In these cases, that visual cue is not provided. It's also not provided in the shortcut menu at the top right, but that at least uses the "click away" dismissal rule.
3. To your question on the TW click-to-close: yes, good point, because the mouse is necessarily hovering over the menu header right after the click, it sort-of closes and temporary-opens at the same time. But that is disconcerting also: did I click hard enough? Again, changing the hint icon between V and ^ will help answer that question, although having it remain open until I move away is still disconcerting.

Of all things, I hadn't thought of clicking on the menu again. That does dismiss the More menus; but IMO "click somewhere else" and "click another menu in the same menu bar" are normal ways of dismissing an accidentally deployed menu. Is that intended behavior in this context?

Still exactly as reported, unless I have something stuck in the cache (I purged the test page).

I note @Novem_Linguae's comment about being a day before "this" (I can't figure out what that would be) lands on enwiki, but I thought I'd report this complex menu bug as this report was just redirected from T337893. Will the fix to this bug address the following? (1) the TW menu can be dropped down by hovering, but the MoreMenus require a click (2) when TW or MoreMenu are clicked, they won't dismiss, either by click-away (if they were activated accidentally) or by right-click/new tab. Only a page refresh or of course a single click will remove them. The result can be as shown, with the Page menu barely visible.

My "can't click away" problem is still there, though. On a User page it's even more dramatic: it doesn't matter in which order I click these, the Page menu is inaccessible (F5 again is the cure). And User and Page don't drop down on a hover, so clicking them is the only way to access.

I don't know whether to add this here, to T319358, or start another issue, but here goes:

I came here via Twinkle Talk with a version of this bug, but it's not identical to the OP. My Page menu is clear, but the TW menu is naked like in the above screenshot (I have underscores too).

I couldn't resist. I instrumented by reflecting into the RE cache, and did some test AWB runs. Some with a specialized list of EB1911-derived articles, and some in this month's "Articles that may be too long..." category.

Sorry to keep on at this, but the difference between a low-teens count from one of my earlier tests and 50+ seems to be "Apply general fixes", which was turned off in the former case. That makes some kind of sense.

What really annoys me is that there is no instrumentation of the Regex code, even accessible via reflection, that lets you test the performance of the cache during a run. For example, a usage count would be really helpful. The cache is implemented as a linked list with MRU promotion, which means that looking up a previously unseen expression is O(n). In general the MRU logic will help, but there seems to be no way whatever of finding out how many expressions at the end of the list are one-and-done. For example, in the "Sun" case the last entry is "[a-z-]*uca-", which appears in session initialization and can be allowed to fall out of the cache. I don't know how many others are once-only. The first, by the way, is "\\)" (???).

Probably not. I was surprised about the variability on a simple single page load, but didn't diary the second test. Using an instrumented version of the current SVN build and the current page versions (5/31 8pm EDT).

Hmm... in another run I only got 19 in the cache. I need to investigate more to see what changed, so don't act on this yet. It's still more than 15 though.

Point taken. However you would also need two complete sets of .csproj files too. And I would prefer the other way round: the default .sln file (and .csproj's) be up-to-date with the latest Windows/VS tools and a backward-compatible Fx 4.5 .sln/.csproj set with a target-specific filename.

Confirmed fixed in 12547 (I tested 12549).

My version of this bug, T321221, seems fixed on en wikipedia today.

I'll check my repro (T321221), which currently still has the old behavior. Are you planning to roll this out to en.wikipedia first?

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.