In T361147#9742408, @Volker_E wrote:

Was able to reproduce this on the Codex docs site with Safari Version 17.4.1 (19618.1.15.11.14), but it seems to be a browser bug.
When I uncheck the background-color property on the span carrying the check mark, while I'm inspecting the element, I can make the check mark appear again.

(Engineering notes)

I totally forgot to move to this to QA! It's already live on all wikis and has been for a week.

@ppelberg is away for a while (E1732) but I did consult the Editing team and there were no technical objections. It was mentioned that line numbering could be confusing to new users, but this is less of a concern right now that CodeMirror is not on by default. T359498 will also later provide a means for users to selectively toggle individual features as they so desire. When that time comes, communities can decide what the default features they want, and having CodeMirror on by default I think will be more realistic.

In T358804#9711347, @MusikAnimal wrote:

The <br> tag here is not being fully nested in the .cm-bidi-isolate span https://en-rtl.wikipedia.beta.wmflabs.org/w/index.php?title=Br&action=edit

This is possibly an issue with the parsing of apostrophes. If we do instead boldened syntax (no extraneous apostrophes), things look better. Definitely still a bug, I just don't know how common it will be, and it seems to sort of be an issue for LTR as well. T304567 may be related.

Unlicking this. I'm working on T362913 first which will ease development moving forward.

Barring objections, I'm just going to add a check for a minimum of 1,000 edits on the corresponding project. Someone like WizardGamer775 may have gotten there eventually, but there will always be outliers. A 1K edit requirement should shield us from most intentional disruption.

I was more thinking along the lines of the MediaWiki's browser support matrix, but I see now Grade A still includes Safari 11 which is too old. I shall change the examples back :) Thanks for flagging!

That's what I'm saying, async/await is not in ES6! It was added only in ES8 😄

In T361512#9725663, @Samwilson wrote:

This task is about internationalizing the intake form isn't it? … should this task stay scoped on the i18n of the form?

In T361465#9720984, @Bhsd wrote:

For instance,

this.$textarea[0].dispatchEvent(new Event('focus'));

Saving as JSON would be cool, and would make it easier to edit proposals using the intake form. However, we template to render the content, so we'd be doing a JSON-to-wikitext conversion more often than not (every page parse). I was thinking that the bot that parses proposals (T361067) would eventually be responsible for data storage, which we'll later use in the dashboard. So JSON wouldn't benefit us in that sense.

I think ideally we'd have our survey sandbox working (T362809) before tackling this, but that's a ways off. Most of us don't have admin rights on Meta so you won't be able to easily delete test proposals.

Indeed, it looks like replag is the cause here https://replag.toolforge.org/

Done https://openstack-browser.toolforge.org/server/commtech-bot02.commtech.eqiad1.wikimedia.cloud

I can't even say for sure the cursor is being moved. From a user standpoint, it seems it's not, or if it is, it happens too quickly to notice. I didn't code anything to keep focus on CodeMirror -- it's doing that on its own which leads me to believe we're not breaking any rules, per se.

In T174145#8172734, @thiemowmde wrote:

@Volker_E, ok, I see. I gave it a try. Here is a version I re-created from scratch to a) look as pixel-perfect as possible at the 20x20px default size and b) avoid the cutter knife impression I talked about in T174145#4542977.

highlight_Thiemo_2022-08-22.svg308 BDownload

In T174811#9716295, @Jack_who_built_the_house wrote:

Thank you. Tbh I don't know how to read changes when there are only /dist/ files in the patch and no /src/ changes 😄

I would much prefer the errors are captured, at least, but as it stands now barring a means to reproduce, I'm in favor of keeping unfoldAll -- especially if everything continues to function just fine despite it hiccuping. The (un)fold all features are only available via keystroke, so I suspect most users won't use them anyway. As we roll out to more wikis, we'll monitor the error logs and should have a better idea of how widespread the issue is.

I've added mediawiki.org as a pilot. There's no community really to consult per se, and it's low-risk. I just want it deployed here before any content wikis because the documentation uses some of the interface messages which aren't deployed there yet (i.e. "⧼codemirror-prefs-enable⧽").

In T361465#9711883, @Bhsd wrote:

This is sort of a follow-up to T197632, so pinging @Bhsd to see if they think there are any issues in switching to trigger().

My understanding is that trigger( 'focus' ) sets focus on the hidden textarea element. However, it might be a problem only for IE.

r1019841 provides a means to integrate with CodeMirror unrestricted and with full control. r1019841 meanwhile adds a ext.CodeMirror.input hook that gives you a ViewUpdate object. I think between these and the existing hooks, we've satisfied what is being asked for in this task. I don't see a need to expose CodeMirror internals in the other hooks, or to fire input events on the textarea (given the data we supply is not what the input event would normally do).

In T174811#9711383, @Jack_who_built_the_house wrote:

I think you would also need to do const lib = require( 'ext.CodeMirror.v6.lib' ); to get access to EditorView.updateListener and do something like this to emit input events on Special:BlankPage:

…
const lib = require( 'ext.CodeMirror.v6.lib' );
…
lib.EditorView.updateListener