I can't reproduce the original issue, so it might be something even more specific than you have listed.

The sequence of events is:

The qqq description is "Label for the widget's visual mode.\n\nThis should not include the word 'edit' or 'editor', and should not use the product name VisualEditor."

Another reference-defined templates issue that's difficult to solve until we get T404608 or something similar to it from Content-Transform-Team.

It certainly looks identical.

Will we be turning tone check off for everyone (on those wikis) or turning it on for everyone (on those wikis)?

It's specifically complaining each time about this revision: https://fr.wikipedia.org/w/index.php?title=Humour&diff=prev&oldid=38819316

What needs to be tested here is experiment enrollment and the experiment-specific instrumentation.

They're related, for sure, but I wouldn't call it a duplicate.

This could perhaps take inspiration from T380598 which is supposed to be creating a live-updating TOC in desktop VE. As @bmartinezcalvo mentioned in a meeting, the collapsed TOC that Vector-2022 uses seems like a very mobile-applicable design that we could port over.

This seems like it'd be actively getting in the way in the case where the user has clicked the bottom button -- covering up the newly-added content.

There's presumably a difference between the range created by getModifiedRanges for suggestion mode (which just grabs the ranges for all direct children of the document node) and the range created by adding a heading normally and then getting the range from the squashed transactions...

The actions don't make much sense to me -- differentiating between lead/middle/last seems strange. Differentiating between top/bottom makes sense, but as-specified we wouldn't know that for the majority of sections (which are mostly middle, after all).

There's an old screenshot from July on mw.org -- it should get updated.

It's not technically mobile-exclusive -- it's anywhere that this section editing mode is enabled. Which is everywhere on mobile, and also wikitech and officewiki.

The issue is somehow specific to transitioning from a fake selection to select-all. The original patch fixed the issue for a native browser-selection.

Basic would be something like: feature: section-switch; action: switch.

There's follow-ups, but this is done. It has also been tested as part of other tasks.

Pastes from plainText and visualEditor are the most frequent sources

This involves looking at retention rates for users who don't have skipcaptcha right, which is all new user accounts

Just make sure you're not actually checking whether the user has the right, because they might have picked it up during the retention-period you choose.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiEditor/+/1204669 for T409779 was merged-and-backported yesterday, removing some duplication of saveSuccess/saveFailure events (with their interface incorrectly set to wikitext) and inapplicable source-no-js events when people were editing with non-WikiEditor editors. This has greatly reduced our current number of edits that could potentially be posting to the edit form, down to ~0.7% of successful edits on enwiki today.

Interesting -- we deliberately force paste to go first currently, but we weren't thinking about the mode switch when we did that.

The a/b test for addReference went out to enwiki, and so it's enabled on the enwiki-beta. If you check your console once the editor is open you should be able to find mw.config.get('wgVisualEditorConfig').editCheckABTestGroup set to control.

We did previously fix this, so I think it's probably some incredibly timing-dependent aspect of the switch between moments.

This does suggest the future existence of cached suggestions, which currently isn't a thing.

This should be a good semantic fit with the existing usage of saveFailure, because my understanding of the hCaptcha flow is that it'll show the captcha after the user clicks to publish their edit. This aligns with how the already-present ConfirmEdit captchas work, just without the same cycle through the page-request flow.

If you have a config file that contains e.g.:

Those seem like they'd be unrelated, and the other tickets exist already anyway, so either way we might as well close this one if you're satisfied with the basic "paste check shows immediately after a paste" behavior.

(I also can't reproduce it on a physical iPhone. It was just simpler to get the recording in Chrome in mobile-mode.)

Yes, immediately tapping undo in the toolbar. Here's a recording of what I'm trying: https://youtube.com/shorts/sm1Q5klJwAU

The a/b test is now enabled on enwiki. It has also been configured by enwiki admins at https://en.wikipedia.org/wiki/MediaWiki:Editcheck-config.json -- currently just to not trigger in the lead section and various other sections.

Note that creating the possibility for a suggestion that isn't a check is going to require some changes to be made to the suggestions MVP, because currently the overlap is relied on for filtering out suggestions from user-edited content. (Unless such a suggestion should become the only type of suggestion that can show in user-edited content, of course...)

That is technically deliberate, but mostly a side-effect of a change that made it possible for keyboard shortcuts to get you back to the main save panel. It should probably be tweaked so that the keyboard shortcut does that, but directly clicking the button immediately saves -- since in the dialog the back button does work for it. (Or, at a minimum, the publish button should show the "..." version of the label if it's going to take you back to the save panel rather than immediately publish.)

(i.e. do T347775 first.)

Specifically, I think this should be implemented as a part of the BaseEditCheck doesConfigMatch or similar, and can thus be inherited by matchItems. (It might need some special-casing, because whether a page is in a given category can be changed during an edit session, so we'd need to account for that in the editChecksArePossible method of the Controller.)

Approach 3 has the interesting side-effect of removing the "accidental edit" mobile issue.

The conceit here is that the reply input is "just a textarea", and so when your focus moves somewhere else there's not a selection inside it any more. Since there's not a selection, any actions that require a selection to exist in order to do something get disabled. I think our specific intent (though it's been a while so I might be inventing this) was to indicate that the toolbar wouldn't have any effect when your focus was in the subject or summary fields.

This is a follow-on from T407714 which only tested single-section loading.

Sorry, the tech news announcement could have been clearer about the timeline in the end. We announced it to make sure people knew it was coming, in case any objections were raised that would cause us to delay it, but we won't actually turn it on for another week.

Okay, this script will now work: https://meta.wikimedia.org/wiki/User:DLynch_(WMF)/alwaysbesuggesting.js

This is probably a duplicate of T408670.

I verified that it seems to be limited to creating a new page -- I was correctly shown a captcha while adding that sample-reference to an existing (sandbox) page, and completing it saved it correctly.

(Think about the case where the user has written Shakespeare said "The fault, dear Brutus, is not in our stars, but in ourselves". The only bit that would be removed by the paste check would be the contents of the quotation marks that they copied in, and suggesting that they publish with just Shakespeare said "" seems unwise.)

This is getting kicked back for more work after issues turned up.