Mind you, the icon in Citoid has also been that way for (gosh) about 8 years now, so changing it either way risks confusing an entrenched community. (Though, honestly, I agree that using the reference icon would make more sense overall...)

The alternative, of course, being this patch: just have the top edit button edit the whole page. As was said, this is probably much more reasonable from a performance standpoint than back in 2017-or-so when the original decision was made.

It's worth noting that there's some cases where temp users having preference-setting completely disallowed is going to give them a non-default experience, because there's places where we've left old defaults in place for existing users and set new "defaults" by overriding them for newly created users. See e.g. Echo, which changes what notifications are sent in this way.

Patchdemo: https://patchdemo.wmflabs.org/wikis/56e9396b0e/wiki/Talk:DiscussionTools?useformat=mobile

Patchdemo: https://patchdemo.wmflabs.org/wikis/56e9396b0e/wiki/Talk:DiscussionTools?useformat=mobile

We could probably merge this into T330536 -- turns out that the menu does contain the edit link, it's just that the clipping effect combines with the size of the non-discussion section heading perfectly to make it look like no menu is being shown.

@Theklan are you using the new skin? It has a bit less horizontal space available (particularly if you have both sidebars enabled), and that might be enough to account for the change depending on exactly how your space is set up.

I like 4 the best, for making over-indention actually impossible while still giving visual cues. That said, 2's a decent compromise and will confirm closer to what people expect -- there's templates like that deindent one which put in an arrow breaking the flow, and they'll make more visual sense if there's some sort of indentation in play.

This is now launched everywhere but Wikipedias and Wiktionaries, and we should presumably decide when we want to launch it there. (I guess if no terrible issues develop in the next few weeks.)

As I understand the requirements, all that I need to do here is add the DesktopWebUIActionsTracking to the "add topic" button when it's promoted to the header. That patch logs it with the name "addsection-header". (As opposed to "ca-addsection" for the unpromoted version of the button, and "addsection-sticky-header" for the version in the sticky header.)

A combination, maybe? DT's DOM-fiddling removing that invalid </blockquote>, which then made that node get through selser and allowing the newline to get added incorrectly by parsoid.

The described issue sounds consistent with the wikieditor JS and the mobile JS both running at the same time (such that the desktop wikieditor is loaded in the background), or possibly with the redirect-to-mobile code not running as expected (such that the desktop wikieditor loads, logs events, and then the redirect happens, rather than the redirect occurring before the form is loaded at all). However, I can't actually make this happen by directly navigating to an ?action=edit URL on mobile, so it's a bit confusing.

I do understand the parser confusion, since it was dealing with already-invalid markup -- note that it didn't add a blockquote, it just removed a meaningless closing-blockquote that didn't have a matching opening-blockquote.

Even if we switch to just using (2) this will mean that references are re-numbered when switching from read mode to edit mode.

I was thinking that a quick path forward would be for the reference list to offer a button that opened up a variant on the reuse dialog. In its context item would be the easiest place.

There's also Editing-related items in New Contributors and Translation.

I've got an Ace update patch up on the subtask

Someone like @EAkinloose or @Ryasmeen might be better suited to give you a "what we do to comprehensively test DiscussionTools on mobile" overview, admittedly. 😅

@nray you need to check a talk page on a wiki with DiscussionTools enabled for mobile (currently the default, and is turned on everywhere but enwiki) -- e.g. https://fr.m.wikipedia.org/wiki/Discussion:C%C3%B4te_d%27Ivoire. There should be:

Just bear in mind that this would be a large task. To port to ES6 we'd have to make meaningful semantic changes to every single file in the VE project and in various extensions, and deal with lots of areas where things like subclassing and accessing superclass properties occur. (And coordinate this across a number of extensions, including either porting OOUI to ES6 simultaneously or switching to something like Codex, etc.) It could be done, but it'd be a significant time investment, and I doubt we'd manage it without introducing new bugs.

We are down to enwiki as literally the only place that it's enabled, mind you. :D

Copying my comment in from the other ticket, since I think it remains relevant here:

The major hangup on this is that it's going to expose the challenges with VE seeing references that're defined within templates. (Because of the current lack of a centralized way to edit references, this is only really visible to users from the "reuse citation" part of the cite dialog, where such references don't appear.) I suspect that if we accept having those ones greyed out in the list with a "this can't be edited here" tooltip, the rest of this should be fairly simple to do -- unless I'm not thinking of something, it's "just" hooking up a few bits of already-existing functionality and doing some UI work to expose them.

The major hangup on this is that it's going to expose the challenges with VE seeing references that're defined within templates. (Because of the current lack of a centralized way to edit references, this is only really visible to users from the "reuse citation" part of the cite dialog, where such references don't appear.) I suspect that if we accept having those ones greyed out in the list with a "this can't be edited here" tooltip, the rest of this should be fairly simple to do -- unless I'm not thinking of something, it's "just" hooking up a few bits of already-existing functionality and doing some UI work to expose them.

I think there's validation occurring over in T320281.

I think (based on my possibly-out-of-date understanding of the metrics platform) that the WikiEditor instrumentation is going to be incomplete, because the patch for it only added the client-side instrumentation. For WikiEditor the logging of the init, saveAttempt, saveSuccess, and saveFailure events is done server-side via EventLogging::logEvent.

This will automatically happen because the hook is directly tied to HookUtils::isFeatureEnabledForOutput( $output ) -- so any page that has DiscussionTools enabled will inherently have the MobileFrontend talk overlay disabled.

(In fact, if we ever want to make that config change, it'd be good to avoid having other people manually creating subscriptions via the API, since that'll be a bit of a confusing doubling-up factor.)

We technically support this via the DiscussionToolsAutoTopicSubEditor config. It's set to discussiontoolsapi by default, which restricts it to only doing auto-subscription for edits made through the API, but if it's set to any then it'll auto-subscribe to anything that triggers our new-comment detection.

I believe this is a duplicate of T329439, the fix for which was backported a few hours ago.

This needs general regression-testing of DT behaviors that (used to) depend on tracking comments added to parser output.

"mode":{"data_type":"null","value":"null"} seems to be the problem.

Which wikis should this be going out to?

Ace has committed a fix for it, so we could presumably either backport that into our bundled version or await a new release.

OOUI release has happened, so this should be testable.

Re: test cases, DiscussionTools does its own transforms on talk pages on mobile web, so Editing has some interest in keeping an eye on changes that affect this.

It's inside ve.init.mw.DesktopArticleTarget.prototype.onWatchToggle, and is pretty easy to trigger: watch/unwatch the page and then edit it. It doesn't handle the case of there already being something in the hook-queue and so it running before the page metadata has been parsed to setup the checkboxes.

There's an issue open for it on Ace's repo, it seems: https://github.com/ajaxorg/ace/issues/5012

This seems to specifically be related to the Ace editor component used in a MWAceEditorWidget, and seems to be tied to how the Ace editor is deciding how wide characters are. The line height seems to be off as well:

@MNeisler / @ppelberg that proposal-patch was done-and-launched last year, so I think this ticket just needs approval that it actually meets the not-written-yet requirements. :D

Patch is merging; we'll want to wait for this to roll out on the train and then for logging to actually happen, I assume.

I'm immediately suspicious of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/803578/ (T309695) mostly because it was 5 days ago and is touching the precise argument that's erroring.

I think that following direct links would be the only way to make that happen, yes.

The same general issue as T300826, if we're tracking recurring patterns.

Given that sentence splitting is (probably) going to need a server-side component, it might make sense for for us to make a prototype tool that can be thrown onto patchdemo and output some sort of visualization of an article and how it'd be split so we can get an idea of how viable this is for placement.

The template is sufficiently challenging to read that someone else might have better luck than me untangling what about it is leading to it not being closed...

I did a little bit of testing, and it's definitely related to having the {{Community Wishlist Survey/Proposal header|1=Auto-save feature}} template at the top of the page.

@ppelberg I am, though it doesn't seem to happen on every pageload. It's possible it requires some state that I've not accounted for properly in the task description...

I'd need to do a bit more testing to distinguish between this being ve.init.target not being replaced by the editor setup versus the DT autosave reinitializing it in the background and clobbering the editor's target.

A complexity to bear in mind is that we're not splitting text, we're splitting either wikitext or HTML. This might cause some challenges around finding valid insertion points.

I'd expect things to be heavily skewed towards blocks on loggedout wikieditor, because that's where all the automated crawlers are going to be hitting. e.g. a naïve spider crawling every link on wikipedia is going to hit the edit-link on every single page, and if its IP is blocked as many are.... Similarly, those spam scripts that just go around and try to submit every form they can find with links, etc.

Is this task still needed? My impression was that the restbase switchover work is mostly-done? (And e.g. the referenced task in the description is closed, etc.)

It'd need to be a fairly extreme cache overreach -- that function was added back in fc96dcc9d966623821f2c802a0a1a6a91b7fbcb1 in August of last year.

Note: the new wikitext editor doesn't suffer from this, thanks to having a different preview mechanism.

DiscussionTools' scrolling boils down to calling OO.ui.Element.static.scrollIntoView. It seems like the correct way to address this would be to update OOUI to only animate a scroll when prefers-reduced-motion isn't set. (But this might take a little investigation to make sure it doesn't break any cases where the animation is actually required?)

Seems strange. The call to mw.util.getTargetFromFragment happens in highlighter.js, and that does list mediawiki.util as a dependency -- so absent some resourceloader bug or something like a gadget meddling with the globals, I don't think this error should be occurring.

The explicit overrides we've done to standard behavior is to not submit the form if it doesn't pass validation (though technically you can also do that within HTML attributes; we're just doing it in JavaScript instead), and adding the meta-enter behavior to submit the form from within the multiline field.

@ppelberg We didn't do anything specifically about this, rather enter behaves consistently here with how it does in all HTML forms. (I.e. in multiline fields it adds a newline, otherwise it submits the form.) We can change that, but it's worth noting that it does depart from the generally expected behavior of the entire (browser) platform.

I think it's only used in ve.ui.DSVFileTransferHandler, so it'll only trigger when an upload actually happens. I.e. you'd actually need to get someone to drag-drop a malicious file onto a VE window before this could be exploited.

It does work elsewhere with just the contributions link.

@Ryasmeen pointed out an issue with bucket assignment for logged out users that made me dig into it:

I think it's references contained within templates not being added to the internal list. There should be 195 items in the internal list (194 references + 1 note), but there's actually only 189 in ve.init.target.surface.model.documentModel.internalList. There are six references in that article which are used entirely within templates (the infobox, and the review-scores template in the reception section), none of which are present in the internal list. (Which also throws the numbers off in e.g. the re-use dialog.)