I can't reproduce this in Safari currently.

This is an issue with the mediawiki-core TitleSearchWidget that happens to be used by VisualEditor for this. The data does seem to be returned by the API (the tofragment field on redirects), so it could be done there...

MediaWiki:Visualeditor-quick-access-characters.json actually has something close to this already, albeit in an extremely undocumented fashion -- you can add source:true to a given character/replacement, and it'll only be shown when you're in source mode.

This is Mediawiki:edittools, which isn't very importable into the new editor. (I do have a userscript I wrote that does it, but I wouldn't want to consider it reliable.)

Something like enwiki's version of the spamprotectiontext message (that's shown to someone who tries to post a revision containing blocked URLs) sounds like what you want here, or at least one of the pages it links to. I'm not sure if there's a particularly good language-agnostic page on metawiki to be the default, though.

This is complicated and unreliable, and I don't think we should do it.

So long as the migration didn't involve massively changing the schema, I don't think it should matter -- the name field is in the schema as a freeform string currently.

@mpopov We haven't coordinated with them about it. That said, we've also not been touching the schemas (this patch did because desktop and mobile are inconsistent, but it wasn't necessary and so nobody has merged it), so is there actually anything to coordinate around the migration?

e.g. https://en.wikipedia.org/wiki/User_talk:Aaron_Liu?dtenable=1&useskin=vector#top won't complain about this.

It only triggers if an element with that ID isn't present on the page, which #top isn't since it's not part of the default skin, so a fun part of this is that there's a lot of semi-broken links being generated by the enwiki default signature (and that gadget).

What's supposed to go inside that "learn more" dialog is the page's lede section if there's no comments within it. (That's why Redrose64's talk page doesn't have it hidden -- it has that "welcome" message that's signed.)

Those original lines (delete mwData.attrs.refGroup; rather than delete mwData.attrs.group;) have been that way for a very long time -- at least since 2016. Not sure if it's been broken the whole time, or if the name of the attribute coming from parsoid shifted at some point...

@Krinkle thanks for summarizing everything in the end. 👍🏻

In T359182#9627241, @MNeisler wrote:

I believe the webuiactionstracking schemas still apply sampling rates so we will be able to look at percentages but the actual numbers reported will be impacted.

I mean, it'd be slightly slower. But it's an extremely infrequently run script anyway...

Having it be an optional missable step feels less-ideal. Would there be any drawback to just making it be something that update.php always does?

The difficulty here is that ConfigDependency is supposed to be a generic container for a value from any ServiceOptions config store. As such, altering its isExpired method to refetch its config store would require that it also knows which method to call to do so.

(I didn't notice it when testing the earlier patches because the request needs to have failed in the actual citoid lookup, rather than during the reliability check.)

Yes, it's related to that change.

The bucketing implementation wound up happening tagged against T342930.

In T359107#9603584, @Snaevar wrote:

Sometimes new editors copy articles from one title to another because they do not know how Special:MovePage works, and are in fact fully unaware of it's existence. It is an false positive for an copy-paste copyvio check.

Yeah, definitely seems like the subscribe button placement in the headers is different depending on whether visual enhancements are enabled. ext-discussiontools-init-section-subscribeButton winds up outside the h2, whereas ext-discussiontools-init-section-subscribe winds up inside it.

Could probably hook in and make that removal of ‘markasread’ leave some trace that we could filter by if need be, but I’m also fine just not merging that patch if we don’t think we need it. (Part of the reason I made two patches. 🤩)

@MNeisler may want to confirm that this is okay as a way to log it, also.

https://gerrit.wikimedia.org/r/1008929 can be merged immediately and just logs when a permalink timestamp is clicked. (action: click, action_source: discussiontools.permalink-copied)

For the sake of precision, it set VE as the default mobile experience for: anyone who had never edited before. (Because if they had, even on desktop, they'd have a cookie/preference that we'd listen to instead.) In *practice*, this probably does boil down to new accounts and logged out accounts, with the caveat that logged out accounts do get a localStorage preference saved for the last editor used on that device.

Unless we want a whole new schema for this, it's probably a decent fit for <desktop/mobile>webuiactionstracking. (We already log clicks to the various add-topic buttons there.)

Sort of iffy to do for statistics, since the only edits we can meaningfully tag are "someone was shown this, then fixed it" -- someone who bounces entirely just won't make an edit.

I think the new view is arguably more accurate -- the source is:

I do feel like I did it in the sequence it said to in the installation instructions for the extension, at least.

Missed closing this because of the holidays.

With that merged the apps will need to bump the schema version of EditAttemptStep that they're submitting with to 2.0.3 for this field to be present.

@MNeisler no objections to that column, since we’ve not got anywhere else obvious to put that data. It should be a pretty simple change.

This seems to be the wikitext your custom signature outputs:

Someone else tested on Android and didn't see this happening, so I presume it's something to do with either iOS keyboard issues or our previous attempts to mitigate said issues.

I'd be inclined to just leave the heading as-is -- "insert the citation" sounds awkward.

The thing VE is doing that's causing database access is calling $title->getContentModel().

I've been asked to include eswiki as well, so the config patch has been updated to add them.

Fuller stack is:

at ve.ui.CompletionWidget.prototype.onMenuChoose 
at OO.EventEmitter.prototype.emit
at OO.ui.SelectWidget.prototype.chooseItem 
at OO.ui.MenuSelectWidget.prototype.chooseItem 
at OO.ui.SelectWidget.prototype.onDocumentKeyDown
at OO.ui.MenuSelectWidget.prototype.onDocumentKeyDown
at dispatch

I think your screenshots are in reverse order? (They seem to imply that the incorrect state under "what happens" is the margin:0 one, which I think is wrong.)

Yeah, we'd had that open issue to clean this up for a while, so I figured that taking this opportunity when we were otherwise going to have to put work into fixing the feature just made sense.

The behavior sounds basically-correct: Template isn't a namespace where you're allowed to use VisualEditor, because almost everything in that namespace is a template and VE would be extremely unhelpful for that. In this specific case there's a subpage which isn't really a template, but VE doesn't have any particular way to know about that.

Bisecting indicates that it's https://gerrit.wikimedia.org/r/c/mediawiki/core/+/990744 @matmarex

It's already in that file, so I assume that the issue is something like that not actually being loaded on mobile. (And unifying all that would be a much bigger change...)

@Jdlrobson Specifically it's fallout from https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/995137 removing the generic border-collapse from all minerva tables.

@MusikAnimal Ah, thanks for working to combine disparate lists. Seems it's another of those fun "technically we own it, but nobody on the team has ever touched it" extensions.

@Samwilson adding you/commtech since you reviewed the original patch, and ImageMap isn't in the component responsibility list.

Alternately: adding a JSON blob of data to a single tag with the count of sentences, but then we'll need to write something to actually display that data since it's completely hidden by default.

I can elaborate! I prefer alt 1 because the buttons don't require that you read the text to know what will happen. Makes it easier for someone who's working through a lot of suggestions to act quickly.

@Ladsgroup thanks for handling that! (I didn't really want to try doing it myself, given my complete lack of speaking the language.)