I've pinged the developers at [[:en:Wikipedia talk:HotCat ]]

@Jdforrester-WMF why is this HotCat's fault? From the description above, it sounds like the value of wgCurRevisionId being returned is incorrect. Surely a tool like HotCat should be able to rely on that being set properly, no?

@Harej, I disagree with prioritizing this as "medium". This involves silent data loss. That should never be a medium priority. It also sounds like the fix has already been identified (use baserevid instead of basetimestamp) and that fix is probably trivial to implement. So why toss it on the medium heap, which basically means it'll never get fixed?

Wow, yeah, that fixed it, thanks.

@Snaevar I'm reopening this. If after some discussion by all the interested parties it is decided not to implement this feature, that's one thing. I know you disagree with my assessment, and I welcome your input, but I don't think it was appropriate for you to unilaterally close the ticket without discussion.

Interesting. I can still reproduce it here. I normally use Chrome, but just tried this in Firefox 109.0.1 (64-bit) and can reproduce it there as well. I'm not seeing anything exciting in the console:

This feels like it's related to T332799

This is related to T346835

@kostajh I'm not sure what I could usefully share that wouldn't violate CU confidentiality. I also don't think it would be germaine to this ticket. I see two distinct issues here:

Just wondering if anything is happening to this? I'm working another LTA case right now. We list over 400 confirmed socks spanning 2 years. I suspect there's many more that we either haven't found or haven't bothered to tag. This particular LTA has a pattern of creating a new account on some random IPv4 address then switching to a v6 mobile network for editing. If we could block the v6 /36 only for anon or unconfirmed users that would put a big dent in their operation, or at least make it more work for them to roll out new socks. Such a block would have almost no collateral effect. I don't want to fully block the /36 because it would have way too much collateral damage.

The sandbox idea works for me, thanks.

I just got another one of these:

Looking at the suggested workaround instructions:

When I do this:

Thanks for the link. I remember reading that page at some point a long time ago, but didn't remember the details.

Is this documented anywhere?

In case people are not aware of the practical issue here, I'm now getting a:

I agree that this is a bug. I just got bit by the same problem. See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Autosubscribed_to_a_bunch_of_identical_threads_by_mistake?

I would not be surprised if the checkuser extension were sensitive to a similar DOS attack. If not in the PHP backend itself, then likely in the javascript which builds the summary table.

In T338032#8902758, @Dzahn wrote:

I am not sure realtime media helps unless we have actual coverage 24/7 with people in multiple timezones handling these?

There is one case that I know of where a user with enough edits to be ready for consideration for admin rights on the English Wikipedia was determined to be a sockpuppet.

Do we need to store (as opposed to request) client hints for all of the CheckUser-loggable actions, or is there a subset that are most commonly linked to the type of abuse that we use this information for?

OK, I mostly understand what's happening here. My user-config.py defines oauth credentials for {en,test}.wikipedia.org, and those credentials were created to only be valid on those specific projects. test_create_short_link() forces a login to meta, and that's one of the ways this fails.

On the other hand, maybe this is a server-side issue? I'm all the way down to

It's possible this is a bug in the upstream requests library. I can reproduce this (on both MacOS and Debian) with:

I think you've got that backwards, the flag is not set, so it defaults to '0', which is != '1', so the assertion is run. Which leads to a couple of additional observations:

I see what's going on. This is somehow related to authentication. I have OAUTH credentials in my user-config.py file. It's unclear why it should cause this behavior, but if I comment out the:

I'll echo the sentiments of my fellow CUs. There are a number of LTA cases I track where the abuser uses a model of phone that we don't see very often, so the UA is the definitive way to track the person. Tracking by UA is especially important in parts of the world where:

Oh, I'm guessing this is due to T334940

As noted by others, I agree that it's too domain-specific to be part of the Page class.

FWIW, I can reproduce this as well.

Go to https://en.wikipedia.org/w/index.php?title=Fleetwood_Park_Racetrack&oldid=1146074624. Scroll down to the "Miscellaneous" section and look at the reference after "...toboggan slides, illumination, and music". It is ' "Sport at Fleetwood Park". The New York Times...', numbered 38

My first thought was that sitemaps made sense back in the days when dinosaurs roamed the internet. Then I looked at https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview to refresh my memory of why they exist. The main purpose is to enable web crawlers to find pages which aren't reachable by following the link tree from your main page.

How would you feel about having site_detect.py:check_response() raise ServerError if response.status_code == 403?

Interesting. It seems to be platform dependent.

Oh, I see how this works. WikiHTMLPageParser overrides handle_starttag() which calls set_api_url().

I don't understand why this failure is specific to github. It's failing for me as well on my MacOS laptop.

You posted two screenshots (IMG_7394.PNG and IMG_7395.PNG). How did you generate those, i.e. what do I have to do to view those two different versions of the page on my phone?

Could you post the URLs used to generate those? I tried scaling them to phone-size on my desktop, that's not a good comparison because the desktop's monitor doesn't have anywhere near the resolution my phone has.

Sorry, this is a duplicate of T331486

Hi. Sorry it took so long to get back to you. On https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know, on the page I've got:

The example I gave in T329063 is now working better.

@TheDJ before I do that, is there any value to the people trying to debug this to my leaving things they way they are now, since it seems I can reproduce it and nobody else can?

I'm seeing this again. I again have in my console:

I just saw it happen again on https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know#Prep_7:_Chicago_station_(CTA_Logan_Square_branch)_(nom)

This reminds me of T326996.

The particular thing I wanted to do today is move a python wheel file which I had built on my local dev machine and wanted to install on toolforge. Checking the wheel into git would make no sense. The way I currently install my app is indeed to push the source to git and pull that down into toolforge, but I'm exploring if doing wheel installs would be simpler.

I'll add one more comment. Sometimes I've copied what I need over to /tmp because it's world writeable and worked with it there. From any rational security analysis, that's the wrong thing to do, but sometimes you need to get something done and you find a way to do it. If you make it easy for people to do the right thing, they'll do it. If you make it difficult for people to do the right thing, they'll do the wrong thing if that's what lets them get their work done.

Just noting that I've run into exactly this same issue (see this thread). So I'll add my voice to supporting getting this implemented.

I haven't seen it again after I reported the original incident. But I'll let you know if I see it again.

FWIW, I described another way to reproduce this on enwiki vpt

Interesting. Yes, I'm seeing javascript errors on page loads (even before I try to edit anything). It's not entirely reproducible, but they're all variations on:

I can even replicate it on my desktop, using Chrome's mobile device emulation. For example, looking at https://en.wikipedia.org/w/index.php?title=User:RoySmith/sandbox&oldid=1138008943&useskin=vector2022, emulating a Galaxy Fold at 280 x 653 pixels. This one is using my normal (User:RoySmith) account, MacOS 12.6.1 Chrome Version 109.0.5414.119 (Official Build) (x86_64)

On the phone, it's my mobile account, which is totally generic. I see the same issue logged out in an incognito window.

With the explicit useskin=vector URL, the high-order digits overflow onto the grey left-side navbar, but they're visible on both the 6a and the X4.

Both of my examples are using Chrome.

On my Moto X4 running Android 9, there's enough room for 3 digits, so this appears to be browser or device specific.