Thanks @Aschmidt. Pinging @Esanders given -

It first showed up right after T175223 was implemented.

I wonder if this was caused by the fix for T175223.

Actually, I think this was caused by 29f6b48eebc0 (turning off inputStyle: enableContentEditable in Firefox). It seems we did that in order to disable CodeMirror's spellchecking, but the way we disabled it is probably overkill. We could actually just disable the spellchecking specifically and not all of contentEditable. Something like...

inputStyle: 'contenteditable',
spellcheck: enableSpellcheck,

in ext.CodeMirror.js. Let's try that before we mess with ve.ui.CodeMirrorAction.js.

After doing some archeology, it looks like we actually turned off contenteditable in Firefox to deal with @Fomafix's keyboard shortcut bug (T95104#3634230). Considering all the Firefox-specific CodeMirror problems we now have, I'm beginning to think that Fomafix's bug might be worth breaking again in order to turn back on contenteditable in Firefox. Hopefully, we could find a better way to deal with Fomafix's bug (although it seems to actually be a browser bug as there is no JS involved).

Interestingly, it looks like the blurry text may actually be two different bugs. In OSX Firefox in the new WikiText editor, it's probably caused by https://gerrit.wikimedia.org/r/#/c/394337/2/resources/modules/ve-cm/ve.ui.CodeMirrorAction.js, and in Windows and Linux Firefox, it's probably caused by https://gerrit.wikimedia.org/r/#/c/382023/4/resources/ext.CodeMirror.js, both of which are related to T95104. Needs some further investigation to confirm this hypothesis.

Because of the recent renaming of this task by @TBolliger I'd like to point out once again that this is not only an issue concerning Chinese text, but also latin scripts and fonts.

I suggest you rename this task respectively. – Thanks!

We'll resize this in today's kickoff.

There is a similar problem. the highlight lines cannot fits the actual position (Windows 10 64-bit, Firefox 58.0.2).

@Taiwania_Justo: Thanks. Could you please file a separate task and provide steps to reproduce, system information, a link to see the problem?

Similar issue was here T176073, which is still happening.

May be fixed by T188473: [Regression pre-wmf.23] Weird wikitext formatting observed while editing with NWE when syntax highlighting is on

Part of the issue is that bold tags change the glyph width of Chinese characters in Firefox, so we will have to disable bold in VE.

Change 417016 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/CodeMirror@master] Avoid using bold with VE+CodeMirror

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

@Esanders - The other two WYSIWYG features in CodeMirror are italic and headers. We should check both of those as well.

Change 417016 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Avoid using bold with VE+CodeMirror

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

Hi @Esanders — Any update on this? It appears to have gone out with wmf/1.31.0-wmf.25, can this ticket be closed?

I'm afraid it is even worse than it was before. Text now looks blurred etc. even immediately after switching on syntax highlighting on my system (same as above, now FF 52.7.2 ESR). When we started out the effect appeared only when you began to enter some text in the editor...

Here is an example of what it looks like with me.

Here is an example of what it looks like with me.

Given that you have grey text version, you must be using Firefox on OSX. I can't reproduce your screenshot using the same article and browser+OS. Can you check again tomorrow after the next release?

Yes, I run FF ESR 52.7.3 on El Capitan, and given that the release is already there tonight (is it?), I'm sorry to say that nothing has changed. :(

I am able to reproduce this defect on macOS 10.13.4 High Sierra on Firefox Quantum 59.0.2 (64-bit) on NWE build Version 5b36d88 2018-03-27T17:24:58Z on article https://en.wikipedia.org/wiki/User:TBolliger_(WMF)/sandbox

It's not as bad as Aschmidt's screenshot, but here is what I am seeing:

This particularly seems to affect italicized words (e.g. adipiscing) and the closing </div>.

Thanks for testing, @TBolliger ! Meanwhile I have upgraded to Firefox 59.0.2, still on El Capitan, and it still looks as bad as it was before on my machine:

I've tested with FF 59.0 and OSX 10.11 (El Capitan) and everything looks perfect on the linked page.

@TBollinger your screenshot looks fine apart from the green </div> tag, could be something do with sub-pixel anti-aliasing, in which case there isn't much that can be done..

@Aschmidt it looks like the top surface has word breaks enabled. This shouldn't be the default behaviour, but maybe a user script or browser plugin is changing this. Is it still broken with a clean browser profile and/or new user account? If it is a user override then https://gerrit.wikimedia.org/r/#/c/422346/ might help.

@Esanders I have restarted Firefox on El Capitan with a fresh profile, and I have switched off auto hypenation on Meta Wiki. No changes, I'm afraid. :( Strange that it seems to work for you... Again, thanks for looking into this!

SG9tZVBoYWJyaWNhdG9yCk5vIG1lc3NhZ2VzLiBObyBub3RpZmljYXRpb25zLgoKICAgIFNlYXJjaAoKQ3JlYXRlIFRhc2sKTWFuaXBoZXN0ClQxOTcyODEKRml4IGZhaWxpbmcgd2VicmVxdWVzdCBob3VycyAodXBsb2FkIGFuZCB0ZXh0IDIwMTgtMDYtMTQtMTEpCk9wZW4sIE5lZWRzIFRyaWFnZVB1YmxpYwoKICAgIEVkaXQgVGFzawogICAgRWRpdCBSZWxhdGVkIFRhc2tzLi4uCiAgICBFZGl0IFJlbGF0ZWQgT2JqZWN0cy4uLgogICAgUHJvdGVjdCBhcyBzZWN1cml0eSBpc3N1ZQoKICAgIE11dGUgTm90aWZpY2F0aW9ucwogICAgQXdhcmQgVG9rZW4KICAgIEZsYWcgRm9yIExhdGVyCgpFVzZSC3IERpc2NsYWltZXIgtyBDQy1CWS1TQSC3IEdQTApZb3VyIGJyb3dzZXIgdGltZXpvbmUgc2V0dGluZyBkaWZmZXJzIGZyb20gdGhlIHRpbWV6b25lIHNldHRpbmcgaW4geW91ciBwcm9maWxlLCBjbGljayB0byByZWNvbmNpbGUu