Change #1317209 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] MWMetaDialog: Let extensions contribute pages

https://gerrit.wikimedia.org/r/1317209

Change #1317210 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/CodeMirror@master] VisualEditor: Add a syntax highlighting page to the options dialog

https://gerrit.wikimedia.org/r/1317210

Change #1317209 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] MWMetaDialog: Let extensions contribute pages

https://gerrit.wikimedia.org/r/1317209

Change #1317210 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] VisualEditor: Add a syntax highlighting page to the options dialog

https://gerrit.wikimedia.org/r/1317210

Change #1318739 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/CodeMirror@master] VisualEditor: Offer active line and whitespace highlighting

https://gerrit.wikimedia.org/r/1318739

We've also added a keyboard shortcut that opens up the VE options dialog ({cmd/ctrl}+shift+comma), and are turning on some other codemirror extensions that were disabled in VE because without settings there was no point to them being loaded...

Change #1318739 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] VisualEditor: Offer active line and whitespace highlighting

https://gerrit.wikimedia.org/r/1318739

I notice a few possible bugs:

1. The preference dialog cannot be opened if there is any content selected.
2. Disabling the line numbers causes misalignment between VE and CodeMirror.

@Bhsd I can't reproduce not being able to open the dialog with a selection. I do see the line number issue though, I wonder if it's some of the various columns of work that've merged not playing nicely together. I will look into it now.

In T433188#12169804, @DLynch wrote:

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

In my test, the issue exists in both Firefox and Chrome on a MacBook. Neither the menu button nor the keyboard shortcut opens the CodeMirror preference dialog when the selection in non-empty.

Change #1319198 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/CodeMirror@master] VisualEditor: properly adjust gutters when toggling line numbers

https://gerrit.wikimedia.org/r/1319198

@Bhsd this patch fixes it. Turns out I was overly-optimistic when I just pulled the lineWrapping extension out of the VE supported extensions -- it had an effect, and I didn't realize because I didn't think in testing that it could maybe only have an effect when line numbers were off.

Change #1319198 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] VisualEditor: properly adjust gutters when toggling line numbers

https://gerrit.wikimedia.org/r/1319198

Okay, the dialog not opening is more interesting.

There's one option that's actually a long-standing VE-source bug: the options dialog is a FragmentDialog, and unless explicitly told not to, when in source mode they convert your selection from wikitext into a VE data model via a server round-trip to get it from Parsoid. This is a no-op if you have no selection, but can take a short while before it'll open the dialog. Crucially, it can also fail, and if it does then the dialog won't open.

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?)

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?)

Thanks for diagnosing the issue! Yes, I get an error from action=visualeditor paction=parsefragment attached below in my docker environment with up-to-date MW core and VE:

{
	"error": {
		"code": "internal_api_error_Error",
		"info": "[3e7fe553b7c7f30c923cd598] Exception caught: Unknown named parameter $siteConfig",
		"errorclass": "Error"
	}
}

Trace:

Error at /var/www/html/w/includes/Parser/ContentHolder.php(111)
from /var/www/html/w/includes/Parser/ContentHolder.php(111)
#0 /var/www/html/w/includes/Parser/Parsoid/PageBundleParserOutputConverter.php(81): MediaWiki\Parser\ContentHolder::createFromParsoidPageBundle()
#1 /var/www/html/w/includes/Parser/Parsoid/ParsoidParser.php(165): MediaWiki\Parser\Parsoid\PageBundleParserOutputConverter::parserOutputFromPageBundle()
#2 /var/www/html/w/includes/Parser/Parsoid/ParsoidParser.php(330): MediaWiki\Parser\Parsoid\ParsoidParser->genParserOutput()
#3 /var/www/html/w/includes/Content/WikitextContentHandler.php(360): MediaWiki\Parser\Parsoid\ParsoidParser->parse()
#4 /var/www/html/w/includes/Content/ContentHandler.php(1569): MediaWiki\Content\WikitextContentHandler->fillParserOutput()
#5 /var/www/html/w/includes/Content/Renderer/ContentRenderer.php(62): MediaWiki\Content\ContentHandler->getParserOutput()
#6 /var/www/html/w/includes/Revision/RenderedRevision.php(246): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()
#7 /var/www/html/w/includes/Revision/RenderedRevision.php(219): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached()
#8 /var/www/html/w/includes/Revision/RevisionRenderer.php(226): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
#9 /var/www/html/w/includes/Revision/RevisionRenderer.php(159): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
#10 /var/www/html/w/includes/Revision/RenderedRevision.php(182): MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()
#11 /var/www/html/w/includes/Rest/Handler/Helper/HtmlOutputRendererHelper.php(1038): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
#12 /var/www/html/w/includes/Rest/Handler/Helper/HtmlOutputRendererHelper.php(998): MediaWiki\Rest\Handler\Helper\HtmlOutputRendererHelper->parseUncacheable()
#13 /var/www/html/w/includes/Rest/Handler/Helper/HtmlOutputRendererHelper.php(692): MediaWiki\Rest\Handler\Helper\HtmlOutputRendererHelper->getParserOutputInternal()
#14 /var/www/html/w/includes/Rest/Handler/Helper/HtmlOutputRendererHelper.php(474): MediaWiki\Rest\Handler\Helper\HtmlOutputRendererHelper->getParserOutput()
#15 /var/www/html/w/extensions/VisualEditor/includes/DirectParsoidClient.php(168): MediaWiki\Rest\Handler\Helper\HtmlOutputRendererHelper->getHtml()
#16 /var/www/html/w/extensions/VisualEditor/includes/ApiParsoidTrait.php(146): MediaWiki\Extension\VisualEditor\DirectParsoidClient->transformWikitext()
#17 /var/www/html/w/extensions/VisualEditor/includes/ApiVisualEditor.php(543): MediaWiki\Extension\VisualEditor\ApiVisualEditor->transformWikitext()
#18 /var/www/html/w/includes/Api/ApiMain.php(2049): MediaWiki\Extension\VisualEditor\ApiVisualEditor->execute()
#19 /var/www/html/w/includes/Api/ApiMain.php(947): MediaWiki\Api\ApiMain->executeAction()
#20 /var/www/html/w/includes/Api/ApiMain.php(918): MediaWiki\Api\ApiMain->executeActionWithErrorHandling()
#21 /var/www/html/w/includes/Api/ApiEntryPoint.php(138): MediaWiki\Api\ApiMain->execute()
#22 /var/www/html/w/includes/MediaWikiEntryPoint.php(180): MediaWiki\Api\ApiEntryPoint->execute()
#23 /var/www/html/w/api.php(30): MediaWiki\MediaWikiEntryPoint->run()
#24 {main}

I cannot open any other VE dialogs when selecting text with syntax highlighting off, and they are associated with similar action API failures. It doesn't seem to matter how much text I am selecting, and there is no console error or warning. ve.ui.MWMetaDialog.static.handlesSource = true will fix the issue.

Based on that trace, I think you have an outdated parsoid version. Mediawiki changed how it's passing that siteconfig in this patch at the end of May (with a corresponding parsoid version update). 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#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.

Thank you very much! My issue is fixed by composer update.