Observe that Left/Right won't exit the unicorned underline.

Mouse selection works now, but not keyboard.

This no longer happens.

Can't reproduce. Very old bug so probably been fixed.

Can't reproduce. Given the age of the task I'll assume it's fixed. Please re-open otherwise.

Text is now correctly aligned.

This behaves more sensibly now.

Copy paste sanitisation has improved significantly since 2014, so closing. If this is still happening, please re-open.

IME cursor code has changed significantly since 2014 and I can't reproduce. Please re-open if this is still hapenning.

This is intentional. We move the selection the paste target so we can intercept copy events. Users should not care what document.activeElement is set to.

We could have VE output <br> when you press shift enter in a list, but I think this should be done in Parsoid:

• We are only using <br> because wikitext doesn't support linebreaks
• In other contexts, we generally don't want people using <br> (e.g. table cell), or even in main paragraphs if they press shift+enter accidentally.

Duplicate of T110986. This one is older, but the other has more discussion on it (sorry @Mooeypoo)

Pressing shift+down moves your cursor down visually in the browser. This is just how native selection works in the browser (for example, in read mode, select the first 'l' in 'list item 1', then press shift down, and the same thing happens).

I don't think we do much wiping of data when users log out in general, and you could argue this is either a good or bad thing.

After the above patch it dropped to 3,400 lines. Today it is 5,400 (!)

The rendering is consistent with native selections. We should ignore the empty partial selection for most actions, but that is T52419.

This is working for me. Feel free to re-open if this is still an issue.

Of these I think Korean is an obvious ommission, and was discussed in the original task (T323537#8461963).

Similar to T52419 in that it involves selections which overflow into the next CBN.

Google Docs and LibreOffice don't allow you to indent the first item of a list. They instead visually (but not semantically) indent the entire list. Doing that in MediaWiki (with our <dd> hack indentation) would be even more confusing, so I think doing nothing would make more sense here. Users should probably have to create a bullet list above the first one before increasing indentation.

Browsers do this automatically now (tested Chrome + FF).

Not happening for me in Chrome or FF. Assuming this was a browser bug that has since been fixed, but please re-open if it is still happening.

This has been implemented in DiscussionTools in T275729.

Verified

In T333709#9267084, @ppelberg wrote:

Started a conversation on mw:Talk:Edit check: https://www.mediawiki.org/wiki/Talk:Edit_check#How_should_we_evaluate_this_project?

It might be useful for people to get a sense for the activity of a page if we also showed at least the "X people are commenting"

I've applied my own fix with @disksance 's blessing and things appear to be working now.

This still sets an href, it just sets the href to the current page. Now click on OOUI tools reload the page. The fix to the library (https://github.com/wikimedia-gadgets/VariantAlly/pull/5) should cause it to skip over non-href <a> tags.

Appears to the VariantAlly script: https://github.com/wikimedia-gadgets/VariantAlly/issues/4

We generally don't enable VE on talk namespaces, as it doesn't support indented discussion threads well. One can still add ?veaction=edit to the URL to force the visual editor to load.

I've moved 11 of the remaining 37 pages, but the other 26 will require someone with more rights across all wikis.

May have been fixed since T312558. Is this still broken @Ponor ?

That is T52881. While that would make fragment linking easier, this task argues that a specific tool for quickly linking to sections of the page you are talking about would be helpful tool.

I looked into this a bit, and the problem isn't the year is 0 (both our PHP and JS timestamp libraries support the non-existent year 0).

so that comment with invalid timestamps can be replied to

^ core patch has broken DT headings:

In T338534#9227853, @Tacsipacsi wrote:

I don’t agree. What users can and cannot thank should be a product/design decision informed by technical possibilities, not a purely technical decision.

You will also need to inherit wikimedia/jsdoc instead of wikimedia/jsduck in eslintrc.

Thanks, done.

Clarifying what this patch does:

• Applies to anyone who has visual enhancements enabled (either via the beta feature (which exposes the new preference as enabled by default), the A/B test on certain wikis, or by being on mobile where enhancements are always enabled)
• Enables visual enhancements whenver the __NEWSECTIONLINK__ marker is present (as opposed to only in talk namespaces)
• However this does not apply in the article namespace, unless the article namespace is in wgExtraSignatureNamespaces (such as on mediawiki.org)
  • This prevents our styling ever applying to Wikipedia articles, even if a user accidentally adds the marker to that page.

You can override the gutter with this user CSS:

.client-js .mw-editform #wpTextbox1 {
  margin-left: 0;
  width: 100%;
}

In T351487#9342421, @Nardog wrote:

Who benefits from this?

Anyone switching between highlighting and not highlighting. It also removes the jitter while CodeMirror is loading, which was the original reason for the change. Any fix would add even more complexity for little benefit.

Presumably just limiting the patch to fixed width Vector 2022, and leaving as-is in other situations, would be fine (an improvement on the status quo)?

3 & 4 are fixed. 1 is more complicated as it requires more interaction between VE and this core component (VE needs to override the list of available sections, rather than use an API call). I think that should probably be fixed later.

Thanks for the feedback.
1 sounds useful and should be fixable.
I think points 2-3 can be addressed later in follow ups.
4 should be fixed, we should replace underscores when normalising.
5: if you start typing # immediately you get no page name. Removing the page name could arguably be a Parsoid job, or something we should leave in if the user types it explicitly, but we could remove it locally.

I would call this a feature. When toggling between plain and code height the content will not jump and reflow, and you won't lose your place.

DT mobile is deployed everywhere.

Note that we disable clipping in CSS in this widget:

.ve-ui-completionWidget .oo-ui-popupWidget-body {
	/* The contained MenuSelectWidget is already clipped (T330401) */
	/* TODO: This could be done in JS if OO.ui.ClippableElement provided a way to disable clipping */
	overflow: hidden !important; /* stylelint-disable-line declaration-no-important */
}

Looks like this is caused by scrollbar-gutter: stable.

I assumed this was related to https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/966217 but that hasn't been merged yet...