User Details
- User Since
- Jul 14 2015, 9:27 PM (481 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- DavidBrooks [ Global Accounts ]
Thu, Oct 3
I should have checked: on the web version the confirmation is "Talk:Foo and its associated page have been..." so probably mobile should be consistent.
Aug 24 2024
More details on the previous comment: As noted in the T371647 discussion, Framework 3.5 is not installed OOB on a new system, although it's easy enough to install by hand.
Aug 21 2024
Another, not directly related, banner shell fix is described in T367178.
Aug 14 2024
The AWB fix was checked in on Aug 8 and then released as part of a forced update. But that also rolled up all other changes made since the 6.3.0.1 release (with some other improvements), but any regressions that show up should be reported on the en wiki AWB project page.
Aug 9 2024
The current logic (according to the Framework reference source RedistVersionInfo.cs) is:
- Use the option CompilerDirectoryPath if present
- Use the value from Executor.GetRuntimeInstallDirectory() if there is no CompilerVersion option, or it is set to 4.0
- If the CompilerVersion is 2.0 or 3.5, look in the registry for the directory, which requires Framework 3.5 installation, or a registry hack
- Any other CompilerVersion is an error.
To the comment on breaking-or-not siteinfo, please note that the AWB break (now fixed) was due to the flag removed from userinfo. That may come to the same thing; I don't know the internals.
Aug 8 2024
The AWB breakage is specifically: format=xml&action=query with a body &meta=userinfo&uiprop=blockinfo|hasmsg|groups|rights returns a rights element that no longer includes <r>writeapi</r> (English Wikipedia)
Aug 3 2024
Update based on setting up a new system. VS2019 Community is no longer available, although you can use Professional for a 3 months trial. Also, as I just realized, VS2022 only skips the mandatory framework update if VS2019 is installed side-by-side. Furthermore, it's necessary to make sure Framework 3.5 is installed if you want the compile to work at all.
Aug 2 2024
Aug 1 2024
Jul 8 2024
Jun 24 2024
May 13 2024
Mar 18 2024
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.
Mar 17 2024
@Prati28: sent email.
Mar 16 2024
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.
Mar 15 2024
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.
Feb 24 2024
Visual Studio 2022 no longer forces a Framework update. I'll reopen this if that changes.
Nov 7 2023
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.
Nov 6 2023
Sep 17 2023
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.
Sep 16 2023
Jul 29 2023
As a simple user/UI tester, when can I expect a behavior change on enwiki? Still the same misbehavior on Page and User.
Jul 8 2023
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.
Jul 7 2023
Well, I still have problems with this:
- 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).
- 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.
- 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.
Jul 6 2023
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.
Jul 5 2023
I don't know whether to add this here, to T319358, or start another issue, but here goes:
Jun 15 2023
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).
Is this the same issue? This is from the latest builds of Edge and Chrome.Jun 14 2023
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.
Jun 2 2023
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 "\\)" (???).
Jun 1 2023
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).
May 31 2023
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.
Apr 19 2023
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.
Apr 17 2023
Confirmed fixed in 12547 (I tested 12549).
Mar 29 2023
Mar 3 2023
My version of this bug, T321221, seems fixed on en wikipedia today.
Feb 25 2023
I'll check my repro (T321221), which currently still has the old behavior. Are you planning to roll this out to en.wikipedia first?
Jan 24 2023
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).
Dec 17 2022
"...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.
Nov 28 2022
"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).
Oct 19 2022
Aug 8 2022
@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?
Aug 7 2022
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.
Aug 6 2022
Jun 10 2022
I should have specified that the examples have display=title (or inline,title) as parameters to the coord template.
May 2 2022
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.
May 3 2021
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".
May 2 2021
Apr 30 2021
Sep 28 2020
Mar 26 2020
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).
Mar 7 2020
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.
Feb 22 2020
@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.
Feb 18 2020
Thanks for the efforts so far. Hope you can track it down.
Feb 17 2020
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.
Dec 18 2019
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.
Dec 15 2019
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"?
Dec 12 2019
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.
Dec 11 2019
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.
Oct 10 2018
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.
Oct 9 2018
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
Jul 18 2015
I thought that might be the case. Just wanted to be sure you were aware.
Jul 17 2015
Jul 15 2015
Repro steps work - thanks for the quick fix.
Jul 14 2015
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.