Electron 2.0.x: characters render duplicated when opacity is used in editor

[ggovan]

Issue Type: Bug

In a JS or TS file create an unused import import * as unused from 'somewhere'

The editor then reads

import **asaunused from 'somewhere';

The text when copy and pasted is correct. The DOM looks correct. removing the opacity of the &nbsp elements fixes the issue.

VS Code version: Code - Insiders 1.25.0-insider (c51cf86, 2018-06-18T08:50:30.859Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz (4 x 3392)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: enabled video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Memory (System)	15.91GB (5.10GB free)
Process Argv	C:\Program Files\Microsoft VS Code Insiders\Code - Insiders.exe --disable-extensions
Screen Reader	no
VM	0%

Extensions disabled

[mjbvz]

So if you paste import * as unused from 'somewhere' in to an editor, the text looks corrupted?

Can you please share you user configuration. Have you configured a font for example?

[ggovan]

Here is my user config. I get the same issue if I remove the zoomLevel.

{
    "window.zoomLevel": -1,
    "todohighlight.isCaseSensitive": false,
    "todohighlight.include": "{**/*.cs,**/*.jsx,**/*.ts,**/*.html,**/*.php,**/*.css,**/*.scss}",
    "vsicons.dontShowNewVersionMessage": true,
    "workbench.iconTheme": "vscode-icons",
    "workbench.colorTheme": "Solarized Light",
    "java.home": "C:\\Program Files\\Java\\jdk1.8.0_131",
    "terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
    "java.errors.incompleteClasspath.severity": "ignore",
    "diffEditor.ignoreTrimWhitespace": false,
}

[mjbvz]

@alexandrudima @rebornix Any thoughts on this issue? I haven't been able to repo it

[rebornix]

@mjbvz I ran into this issue a couple of times last week when doing refactoring. Will see If I can have a stable reproduce.

[ggovan]

Sorry wrong, button.

I meant to say that I have tried this on another machine with the same setup and was unable to reproduce it. But on my main machine it is consistent across multiple projects and restarts.

[alexdima]

I am also not able to reproduce.

[joaomoreno]

Just reproduced it! 🎆

Paste these contents in a .ts file:

function foo() {
    const a = `hdshhdasha;
    return `hello`;
}

And have this tsconfig.json:

{
    "compilerOptions": {
        "noUnusedLocals": true
    }
}

A mysterious a creeps out from under the shadows!!! 😨

[joaomoreno]

OK, what. It doesn't repro with --disable-gpu. It doesn't repro in Electron < 2.

My graphics card specs are:

Intel Iris Pro:

  Chipset Model:	Intel Iris Pro
  Type:	GPU
  Bus:	Built-In
  VRAM (Dynamic, Max):	1536 MB
  Vendor:	Intel
  Device ID:	0x0d26
  Revision ID:	0x0008
  Metal:	Supported, feature set macOS GPUFamily1 v3
  Displays:
Color LCD:
  Display Type:	Built-In Retina LCD
  Resolution:	2880 x 1800 Retina
  Framebuffer Depth:	24-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Rotation:	Supported
  Automatically Adjust Brightness:	No

@ggovan What's your graphics card?

[ggovan]

Good to see it's not just me.

Name	- Intel(R) HD Graphics 4600
PNP Device ID	- PCI\VEN_8086&DEV_0412&SUBSYS_05A41028&REV_06\3&11583659&0&10
Adapter Type	- Intel(R) HD Graphics Family, Intel Corporation compatible
Adapter Description	- Intel(R) HD Graphics 4600
Adapter RAM	 - 1.00 GB (1,073,741,824 bytes)
Installed Drivers	- igdumdim64.dll,igd10iumd64.dll,igd10iumd64.dll,igd12umd64.dll
Driver Version -	20.19.15.4531
INF File	- oem76.inf (iHSWD_w10 section)
Colour Planes- Not Available
Colour Table Entries -	4294967296
Resolution	- 1680 x 1050 x 59 hertz
Bits/Pixel -	32
Memory Address	- 0xF7800000-0xF7BFFFFF
Memory Address	- 0xE0000000-0xEFFFFFFF
I/O Port	- 0x0000F000-0x0000F03F
IRQ Channel - IRQ 4294967290
I/O Port	- 0x000003B0-0x000003BB
I/O Port	- 0x000003C0-0x000003DF
Memory Address	- 0xA0000-0xBFFFF
Driver	- c:\windows\system32\drivers\igdkmd64.sys (20.19.15.4531, 7.61 MB (7,974,904 bytes), 22/02/2017 00:31)

[joaomoreno]

@ggovan Can you reproduce with --disable-gpu?

[ggovan]

Everything works fine when I --disable-gpu.

[alexdima]

@chrmarti does this work fine for you when running with --disable-gpu ?

[chrmarti]

To reproduce in Electrom:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>Hello World!</title>
  </head>
  <body>
<style>
  .squiggly-inline-unnecessary {
  opacity: 0.6;
}
.view-line {
  font-family: "Monaco";
    font-weight: normal;
    font-size: 14px;
    line-height: 21px;
    letter-spacing: 0px;
}
  </style>
<div style="top:21px;height:21px;" class="view-line"><span><span class="mtk1">&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="mtk5 squiggly-inline-unnecessary">const</span><span class="mtk1 squiggly-inline-unnecessary">&nbsp;</span><span class="mtk13 squiggly-inline-unnecessary">a</span><span class="mtk1 squiggly-inline-unnecessary">&nbsp;</span><span class="mtk17 squiggly-inline-unnecessary">=</span><span class="mtk1 squiggly-inline-unnecessary">&nbsp;</span><span class="mtk9 squiggly-inline-unnecessary">`hdshhdasha;</span></span></div>

    <h1>Hello World!</h1>
    <!-- All of the Node.js APIs are available in this renderer process. -->
    We are using Node.js <script>document.write(process.versions.node)</script>,
    Chromium <script>document.write(process.versions.chrome)</script>,
    and Electron <script>document.write(process.versions.electron)</script>.

    <script>
      // You can also require other files to run in this process
      require('./renderer.js')
    </script>
  </body>
</html>

[alexdima]

I've created electron/electron#13367 to track this upstream.

[ggovan]

I no longer have this issue on 1.26.0-insider (Commit: bbafa06 Date: 2018-07-09T05:49:15.364Z).

I'm happy for this to be closed.

[bpasero]

@alexandrudima @rebornix since I cannot find a correlating issue at Chrome so far, I am thinking of a workaround we could apply in VSCode. Looks like adding will-change: transform; to the .squiggly-inline-unnecessary class fixes it, but the implications are not entirely clear to me (other than knowing that Chrome will put the elements matching this class on a separate layer for painting).

Also, I wonder if there could be another case where this hits us in the editor that we did not discover yet, e.g. is there another case where we combine   with opacity and monospace fonts.

Another thing that seems to help is to NOT assign the squiggly-inline-unnecessary class to <span>&nbsp;</span>, but I am not sure how much control over that is possible.

I do not think we should ship an update with this bug as I can cause too much confusion, so I am adding the electron-blocker label.

[Tyriar]

Moving to Chromium v63's version of skia appears to have fixed the issue (@deepak1556 put a build together for me to test).

Before:

After:

Tested on mid 2014 mac with Intel Iris Pro 1536 MB.

[bpasero]

We pushed a workaround using will-change:opacity for these.