It says that my request is already pending, though I see there's an email address I can try. Thank you!

Yoink! I'm making a check for uncaptioned images.

As above.

Oops, forgot to make sure that this was linked to the Score change.

Just a note that Val's on vacation this week, but I've got plenty to be getting on with so this is not a priority for me yet.

I've been working on this one in the background. I've found that Kartographer (our plugin for maps) keeps its own state, so our attempt to retrieve an "initial" component state upon first load doesn't work as expected. I'll be submitting a change to Kartographer to make it do so. I'll look at Score afterwards.

Sounds good!

I was thinking of having an allow or denylist to only log certain headers, and possibly simply logging if cf-mitigated is present and what its value is. That way, when we're looking at metrics we can start to segment by whether we hit a web application firewall or are having a site-specific issue.

Oh, what do you know, if I search one of those strings it pops right up: https://phabricator.wikimedia.org/T370263

I thought I already had, but now I look, I can't work out what ticket I thought I put it in. In any case, I'll just paste my notes in here:

@dchan suggested I pop the details of how I've been tinkering with zotero/citoid in here.

I think I've reached a dead-end on this:

I think we might be a "friendly bot": the top item in the list before I went away has disappeared

Well, I've extablished that recaptcha and hCaptcha don't set headers. Unlike cloudflare, which uses interstitials to avoid you even reaching the site they're protecting, these two are used to protect features such as comment forms or stuff that's computationally expensive. I don't think we're going to be having trouble with them – it looks like focusing on just Cloudflare is a perfectly reasonable approach for now.

Generally Citoid will make a couple of requests to resolve redirects and the like, and if it gets a 200 from a HEAD request it then asks Zotero to fetch the page and do its thing. If Zotero fails, Citoid will then make a further HEAD and GET request and run through its own, slightly less specialised, citation extraction routine.

I had a poke at one of the major domains, and found that I was, if I used a headless browser, bounced off Cloudflare's challenge page. In the case of cloudflare, we can detect this by identifying the header cf-mitigated: challenge.

Ops says this is running in k8s and that no, no we cannot proxy through the container (or create one for the purpose). They do have a web access proxy we may be able to use, that's the next thing I'm looking at.

• SOCKSify can help us to redirect local!zotero via production IPs.
• chromium "$@" --proxy-server="socks5://localhost:1080" --proxy-bypass-list="localhost;127.0.0.1;192.168.1.1/16" for checking what's up with the connection with the ol' mark 1 eyeball

I've found that citoid does a lot of work to dereference and follow redirects using HEAD. It will try Zotero, and if that fails, will attempt to fetch documents itself. Citoid formats logs as JSON in a way that looks a lot like OpenTelemetry but is not – I still need to investigate that. At a minimum it sets a request-id, so if we carry that through into our version of Zotero we might be able to trace requests further than before. In T370432 we'll be looking at the behaviour by proxying through the production IPs, which will hopefully give us some insight as to where we're deliberately blocked, where we're hitting a CAPTCHA, and so on.

@dchan and I did some experimentation. We found a few things:

I've built a dialog that presently only shows you the diff between the start of your edit session and the current version of the document. Next steps are to (a) fetch whatever the latest version of a document is; (b) figure out how to show a three-way diff between the user input and the latest version on the wiki and (c) integrate the merging technology of last week

@dchan and I built live merge, as noted above. I've worked out how to add things to toolbars, with my main difficulty having been that the package I'd put the code in didn't load before the toolbar was constructed. I've learned about InputWidget which simplified my dialog code and I've now got a dialog that changes a message depending on the user's input. Now to simply (!) wire that up to the diff mechanisms. The main issue I'm anticipating here is working out the linkage between the MW code and the VE code: I think I need to pass the various documents as arguments.

Finding the current section headings is also done in ve.ui.MWTocWidget.js, which might be a useful place to start

This week I've worked out to highlight text inline and spent some time learning how dialogs are built in OOUI

@dchan and I investigated the current codebase. We experimented with ve.dm.Document#findText and found that the performance was perfectly acceptable on a dev laptop (big caveat!) with a 1000-word regex and one of the largest articles on wikipedia and another large article. We still need to try this on a more constrained device.

The current status is I've worked out how to load various revisions into the codebase and how to do a diff between them. I'm currently pursuing two lines of enquiry: working out how to get a VisualDiff object (or something upstream from that) into a ve.dm.Change format, and building a dialog that allows diffs against various targets, such as between the user's changes and the base document, between the base document and the current version on wiki, and so on. The objective at this point remains getting enough of this corner of this codebase into my head as to be useful, do not expect this ticket to be closed quickly.

I have confirmed that it was doing this because I introduced a bug and then didn't catch it before submitting the change for QA. Sorry about that.

Good catch – definitely not intended behaviour to prevent the dialog from closing in edit mode if the user has not made a change. I'll investigate why it's doing this.

It's just a beta issue – apparently nobody's actively maintaining it. I fired up a patchdemo and was able to upload an image just fine.

Whoops, I didn't mean to give it such an alarming title. I should proofread better, sorry about that.

I've not been able to reproduce on the main branch so it might be environmental?

Thanks for double checking… I was hoping it would just be transient.

I'm having trouble reproing so I'm not sure how to proceed. I'll have another go in a couple days.

Oddly, hitting "F8" or closing the source code editor doesn't cause this bug whereas clicking "resume script execution" does. I'm now not sure it's not a browser bug instead.

I've also confirmed this. I just worked on another bug in the media viewer and found (by forgetting to bring my mediawiki instance back to the present!) that this is a relatively recent regression.

I have a patch ready for this specific plugin. However, it made sense to move this change over to the VE codebase such that any plugin that creates a dialog can benefit from the check for unsaved changes. I'll be submitting that shortly for feedback.