Update: none of these are getting deployed today, and arwiki won't be enabled universally because it's going to be in the A/B test.

Testing this will involve editing the MediaWiki:Editcheck-config.json message. It adds support for two new keys:

That said, this is another on the pile of tasks that'll potentially get simpler as the Parsoid read-views roll out, because then VE and read-mode will be operating off of basically the same HTML.

I am not a javascript/DOM expert, but wouldn't it be trivial to make a call to window.getSelection() before invoking the editor, remembering that, re-select that text after the editor starts, and use element.scrollIntoView() to get back to it?

GBasha-WMF was looking for a way to find this information, and it occurred to me that it was sort of strange we weren't already exposing it...

Looks like the patch here got moved to T312558 and merged -- we might want to QA this issue specifically.

I wonder if the language-variants are confusing it somewhere. Садко vs Sadko in what it's looking for when trying to find the comment, etc.

QA note: you should be able to test this by just viewing the "review changes" diff from the save dialog. There's no way to set the link parameter from inside VE, but with this patch it should just leave alone whatever someone has set it to in the source.

@Arlolra git bisect indicates that this was caused by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/969191

Hm, yeah, my suggestion wouldn't work at all, because ApiMessage::create can't take a MessageValue.

The problem seems to be something about how the ApiParsoidTrait dieWithRestHttpException is trying to pass the exception error message from the LocalizedHttpException through to the API.

Related to T350902. I think the two patches for that wound up merging and not producing the expected order.

I made T351470 for this question.

Hm, actually... it's different from the classic editor because we auto-sign the comments, so it's impossible to leave an actually completely empty comment/topic. And the classic new-topic editor would certainly allow the equivalent of just entering "~~~~".

@Ryasmeen fair point -- I was thinking it was something we had allowed for backwards-compatibility with the behavior of the non-DT new-topic tool, but I checked and that does suppress entirely-whitespace comments.

Pretty recent, then -- the patch that added the scrollbar-gutter rule to OOUI was from Oct 25.

It's intentional for them to center-aligned on pages without visual enhancements, but they should still be top-aligned on pages with them.

It's worth considering that "pasted" is more complicated than everything else mentioned so far, both technically and conceptually, because it's content that has meaning because a certain action was performed with it, rather than something that could be worked out by analyzing the text after the fact.

toslots being main doesn't stop the other slots being considered for the diff. It seems to just be a mechanism to explicitly tell the API which slot given content is being provided for -- the API is going to return all the slots in its output unless we tell it not to. e.g. https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=compare&format=json&fromtitle=File%3ALord%20Bishnu-Shesh%20Narayan.JPG&toslots=main&totext-main=test&formatversion=2

To see this go to e.g. https://commons.wikimedia.org/wiki/File:Lord_Bishnu-Shesh_Narayan.JPG and make any minor change in VE or in VE's source mode, and review your changes (in wikitext mode; the visual diff will look fine). You'll see something like this:

The last round of patches went out in the train that made it to most wikis on Nov 2nd. We now seem to be hovering at around 0-5 EditAttemptStep schema validation errors on a given day (there haven't been any since the 11th, at the time I write this).

Side-effect of the change for T344629, I guess.

@Arlolra Is this a plausible side-effect of the recent round-tripping changes for T348703?

(The former is basically why we have tags, incidentally -- we preselect things we think are important and pull them out so we can filter revisions based on that. Sometimes it's data that isn't really part of the revision -- the editor used, actions taken during the edit, etc -- but other times it's thinks like the "a notable amount of content was added" or "a citation was added" which could be worked out at any time, it's just expensive to do so in a query.)

The challenge of this sort of analysis being applied to something like Special:RecentChanges, or similar server-side tools, is that it's all the outcome of some fairly complicated processing of the data. If we want it to work server-side, we'd probably need to add a whole layer of data storage that could be queried, for which we'd need to define up-front a limited set of data that was worth extracting for use.

This is on ve.dm.InternalList.prototype.sortGroupIndexes, where it's trying to sort the group and it's finding that there's not a firstNode for one of the indexes. Stack implies that it's in the transaction code, coming off of a content insertion, but is a bit unhelpful for working out what kind of content was inserted.

It's on var mwAttrs = this.model.getAttribute( 'mw' ).attrs;, specifically saying that this.model doesn't exist. Probably means that the debounced event handler is managing to run after the teardown Fortunately, this would mean that there's no functional problem being caused by it.

Re: 1.A, this message is probably going to be very similar to the existing spamprotectiontext message, but we can't just use that one because (a) its default wording expects to be talking about a whole attempted-edit and so is a bit too vague ("probably caused by a link to a forbidden external site"), and (b) some wikis (looking at you, enwiki) have customized it to be huge and so it would cause display issues squeezing it into the citoid dialog.

The error on the linked one is happening on a diff of a talk page. However, it doesn't happen to me when I visit that page.

@Ryasmeen the description field isn't empty -- you're adding a linebreak to it, otherwise it wouldn't have let you post the topic. (We could argue about whether we should count an all-whitespace description is being empty, of course, but as it stands there is content in it.)

It was definitely removed in this commit: https://gerrit.wikimedia.org/r/c/wikimedia/portals/deploy/+/971987/1/wikipedia.org/index.html

ssastry did a code search and noticed that there's one non-WMF skin that was going to be hit by the same xpath issue, so I made a pull request on it on github.

Quick explanation of the issue:

1. [@class="mw-parser-output"] is checking for an exact-match of the class attribute.
2. The parser patch added more classes to the mw-parser-output div.
3. class="mw-content-ltr mw-parser-output" is no-longer an exact match.

I guess that patch changed the base Parser output as well, so it really could be either.

Looks like the MobileFrontend MakeSectionsTransform is no longer working correctly with presumably-changed Parsoid markup -- the linked beta page has the entire article content wrapped in <section class="mf-section-0" id="mf-section-0">.

If I was a deployer, I’d assume that any questions have already been cleared during a team meeting.

The deployers don't take any outstanding patches against the repo and merge them, they just merge the ones that've actually been signed up for deployment on https://wikitech.wikimedia.org/wiki/Deployments -- in part because the process includes testing the patch on a staging server, and a random deployer wouldn't know enough about a given patch to properly test that it worked.

Should that be marked work-in-progress until the decision has been made?

I tend to feel that there's no point marking config patches as work-in-progress, as they can only ever be merged by directly being shepherded through a backport window. (Along with the other flaws of the work-in-progress system, of course.)

This has already been fixed by T348288, and was thus presumably a symptom of the ongoing reorganization of overlays -- the fix will be going out next week on the normal deployment schedule.

Confirmed:

I've gone ahead and fixed HotCat.

Happens because the posting API does $wikitext = CommentModifier::appendSignatureWikitext( $wikitext, $signature );, which calls CommentUtils::htmlTrim on the wikitext (which strips the opening/closing whitespace). I can't remember if we're doing that for a specific reason.

Another wait-for-train pause.

It's a bug in HotCat because VisualEditor does update wgCurRevisionId after it saves an edit. HotCat stores a copy of the values on pageload and never updates them, and so it doesn't notice this.

From our meeting, "Learn more" in the revised copy will link to https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation for now until something more-direct comes along.

VE edit notices show up in this side-popup when you start editing a page:

VisualEditor just got tagged here and so I learned about this task. I think we've already done everything it requests as of T343339.

The issue is indeed that some references are defined in places that VE can't know about. In this case it's the three that're defined inside the infobox parameters.

I'd need to double-check what "mode" the growth tool is opening in, but assuming it's adding a custom one, it seems possible that just restricting the fallback so it's only offered if we're trying to load "visual" would be the right thing to do.

Will this run independently of other DiscussionTools features?

The patch-as-written includes it inside the DT initialization, so it'll run if anything at all is causing DT to be loaded on the page. (Which I think might be always happening on talk pages now regardless of how many of the sub-features are disabled. I checked, and turning off everything in the preferences still leaves the mw.dt object existing from the dt.init JS.)

You've added click-new-sticky-header though – is that supposed to be the same thing?

In the cold light of the morning I see you were actually pointing out that this was weirdly named, rather than asking what it means. Yeah, I think that click-new-sticky-header should just be new-sticky-header.

click means it came from a click on an edit link. new means it came from either a redlink or from a section=new action. (url and url-new are those two, but from direct navigation rather than in-page actions.)

Huh, so there are. Looks like I didn't add them in https://gerrit.wikimedia.org/r/c/schemas/event/secondary/+/805728 -- I think because at the time it wasn't even possible to create a new section from the sticky header, if I'm remembering the timeline correctly.