Are you using a mouse? It seems the vertical scrolling bar is hidden by default in your recording.

Thanks for reporting! Are you using the 2020 wikitext editor or the 2017 wikitext editor (a.k.a, VE source editor)? You can refer to https://www.mediawiki.org/wiki/Editor if you are not sure.

I think the link should bring users to action=view pages instead of action=edit.

How about only showing underlines when hovering? This is more similar to real anchor links.

@GMikesell-WMF Ideally, this task may also need to be tested without CodeMirror because the issue exists no matter CodeMirror is on or off.

Why do you want to replace underscores with spaces in links? Isn't that cosmetic?

Underlines will be ambiguous because they are also used to mark links.

I am not sure if this task should be accepted. Extra bolding or italicizing may not always look good.

We can easily replace this.readOnly by view.state.readOnly in applyLinter().

In T288161#12305756, @MusikAnimal wrote:

I'm planning to deploy this tomorrow (Thursday, September 10) around 21:00 UTC, along with the new "Highlight" version of the VE integration (T432558).

Hopefully this will help resolve T429583: WikiEditor 2010 toolbar sometimes not displayed and T422354: Adding `ext.CodeMirror.WikiEditor` to gadget dependencies leads to WikiEditor toolbar emptying.

@bmartinezcalvo Visually speaking, I think showing the setting button as enabled is quite confusing. If a button is displayed as enabled, clicking on it is expected to disable something.

In T436733#12282917, @GMikesell-WMF wrote:

Pending PROD- since Beta and Test automatically disables Syntax Highlighting on big articles so I can only test when it comes into PROD.

Could you describe the steps to get autofill using the WikiEditor 2010 Find and Replace dialog? I am unfamiliar with this feature.

In T436389#12270696, @Nux wrote:

If that helps, I wouldn't mind not having the bracket-matching highlighter in DT.

Temporarily fixed by a workaround. However, if Scribunto will migrate to Lua 5.4 and deprecate arg in the future (T178146: Add support for a newer Lua version than Lua 5.1 to luasandbox), we may need to drop the workaround then.

I can confirm this bug also influences other extension tags such as .

It seems that background colors for matching/non-matching brackets are incompatible with VE.

T436171 mentioned the usage of legacy vararg function syntax using arg, which is removed in Lua 5.2.

In T424438#12260487, @MusikAnimal wrote:

You might also see i.e. {{background color|#e0f2fe|Custom Text}} in place of Custom Text, so we'll need to find a way to parse out the colour from that in order to attach our picker, or leave things like that unsupported.

I cannot reproduce this issue.

I cannot reproduce this issue following the steps.

arg was deprecated in Lua 5.1 and removed in Lua 5.2. Which Lua version does Scribunto use?

I think you need to use local args = {...}, and that works for me.

Any example module pages?

@MusikAnimal For this ticket, we may also need to support color pickers in the mediawiki mode (to some extent). Should I move the codemirror-css-color-picker library from ext.CodeMirror.modes to ext.CodeMirror.lib?

I think one of the dropdown menu items should open the full preference dialog.

MediaWiki-extensions-CodeMirror part is completed.

In T433188#12169933, @DLynch wrote:

Assuming you haven't set up a deliberate external parsoid for development, composer update in your top-level mediawiki checkout should fix it.

In T433188#12169860, @DLynch wrote:

If this is your issue, you'll have a network request in the background to api.php for action=visualeditor paction=parsefragment that's flagged as a non-200 response. (Other questions: does it fail the same way with syntax highlighting turned off? How much text were you selecting? Any console errors? If you do this in the console first does that fix it: ve.ui.MWMetaDialog.static.handlesSource = true?)

The selection becomes very strange after sorting if the original selection was not whole lines, and there is a RangeError thrown in the console.

In T433188#12169804, @DLynch wrote:

I can't reproduce not being able to open the dialog with a selection.

@Lucky_number Could you check whether the issue has been fixed on ruwiki? I cannot reproduce it any more.

I notice a few possible bugs:

In T432950#12155102, @DLynch wrote:

this is actually something the codemirror-branch for T432558 could be made to do.

In T163533#12150057, @STei-WMF wrote:

@Bhsd entry added, please make any changes if needed on the draft meta page: https://meta.wikimedia.org/wiki/Tech/News/2026/31

@Quiddity In the 2017 editor, CodeMirror only adds an overlay layer and the layer has to align with the underlying contenteditable. As a result, we cannot change font size or font weight in CodeMirror, either of which will cause misalignment between the contenteditable and the CodeMirror overlay.

A patch that will be deployed next week adds themes to CodeMirror syntax highlighting. The themes can be picked from a dropdown menu in the full CodeMirror preference dialog. For Wikitext, available themes are default, colorblind-friendly (previously the colorblind preference option on Special:Preferences#mw-prefsection-editing) and no-highlight. For code languages (i.e., CSS/JavaScript/JSON/Vue/Lua), there are a few third-party themes available.