Change:
Issue Type: <bBug</bI can't figure out the exact repro steps, but I've had this happen several times, starting immediately after I updated from the last version of vscode: The cursor gets drawn one character before the actual location. For example, in a typescript file I click past the end of the line, but the cursor gets drawn before the ; at the end of the line. However if I start typing the new text is after the semicolon. Closing the file and re-opening it seems to fix it for a while, but the problem eventually comes back. This is the first time I've seen this in VS Code, although I've seen a similar issue in Monaco before. When we see it there the cursor is usually offset less than an entire character, so it get's drawn on top of the character preceding the cursor location VS Code version: Code 1.36.1 (, 2019-07-08T22:55:08.091Z) OS version: Linux x64 4.19.34--g5b63d4390e96 <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ lit-html1.11.0 soysyntaxchecker3.24.2 bazel-code0.1.9 prettier-vscode1.9.0 nearley1.0.3 vscode-docker0.7.0 Go0.11.4 vscode-typescript-tslint-plugin1.2.2 team1.149.2 vscode-template-literal-editor0.9.0 show-offset0.0.4 java0.47.0 vscodeintellicode1.1.8 vscode-java-debug0.20.0 clang-format1.9.0 vscode-proto30.3.0 </details<!-- generated by issue reporter --
I just had this happen again. It seemed like as I kept typing the cursor was being drawn further and further away from the actual location. Also the error underlines were also drawn before the word that should have been underlined by the same amount as the cursor.
Version 1.36.1 turned out to be unusable for me because of this. I moved back to 1.35.1 and the problem went away.
can you reproduce this issue when disabling all extensions?
Yes, this screenshot is from a session with all extensions disabled: !
Same issue here (Version 1.36 as well as 1.36.1, Debian Stretch environment on Google Chrome OS). Also the height of a line seems to be increasing by a tiny bit the moment that line is changed the first time. This issue is rendering VS Code unusable for me, so I ended up rolling back to 1.35.1, where the issue does not exist.
cc as it only occurs from 1.36
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
This issue is not fixed and I gave the requested info immediately when it was requested.
can you try our exploration builds and check if the issue still persists . Thanks!
Does this reproduce only with certain fonts? What linux distribution are you using? Does this reproduce only on certain (longer) lines? Are you using zooming? () Are you on a high DPI monitor? I need to be able to reproduce on my machine in order to figure out what's wrong, but in the meantime you could use: in your settings to workaround.
I'm having the exact same issue! I was just about to create a new issue but I guess I'll tack onto this one instead. I'm also running Debian Stretch and have had this weird font issue since upgrading to 1.36 (and 1.36.1). I am unable to reproduce it in 1.35.1 after downgrading to it. Having extensions enabled or disabled does not make a difference. It happens sometimes when I create a new line and start typing. The font will look different from the other lines and the cursor will get more and more displaced depending on how much text is in the line. I'm unable to provide the exact steps to reproduce as it seems random but it happens pretty often. When switching to another tab then back again the font gets corrected. I'll provide a couple of images. See the bottom "Lorem ipsum" looking different from the comment above. ! Here's a long line showing the cursor displacement: ! After switching tab and going back: !
This flag seems to fix the cursor displacement for me, but sometimes the font still gets weird for me (which gets fixed when switching tab back and forth). Could it be 2 separate issues at play?
I'm using debian stretch under Crostini on a Google Pixelbook. It does have a high resolution display, and I've been running with the "high density" option turned on for vs code. My font family is set to 'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback' and the font size is 16 pixels. It does seem to get worse the more I type on the line. If I move the cursor to a line that hasn't been modified it seems to display correctly. I tried going back to low density for vs code, I'm still seeing the same problem and sometimes it also draws the cursor too far to the right instead of the left: ! does seem to fix the problem I've also seen this happen in Monaco on chrome with it's default fonts, although it happens much less often there. I tried downloading the linked exploration build with electron 6, but it says the blob doesn't exist. Is there a more up to date version?
Are you certain you have disabled all extensions and have never ever messed with the CSS shipped with VS Code? I'm asking because we would render in exactly the same way an edited line, or a line that is currently being edited, like a line which was never edited... so having decorations rendered correctly after switching tabs and going back is IMHO quite weird. This is scary, why would the font change? Are you perhaps using IME and doing composition? Thanks for following through and confirming that the monospace optimizations are to be blamed in your case... Unfortunately, I will need to set up Debian Stretch to try and reproduce... Conceptually, here is what we are doing: on startup we render 1000 s, 1000 s, 1000 s, etc and we establish if the font is monospace by reading their widths. If all widths are equal, we will consider the font monospace and we'll store the charWidth. if we think the font is monospace, we render decorations in the editor a lot faster, by using simple multiplication (decoration at character i should be painted at offset i * charWidth, etc.) It looks that for you, we detect the font as being monospace at startup, but then it actually isn't... Perhaps under your OS the font is lazy loaded or some other bizarre thing where the initial measurements are no longer correct... But I'm speculating, as I didn't really reproduce...
I have also observed that switching tabs temporarily fixes it, with all extensions disabled. But then it comes back as I start editing the file. Everything renders correctly when the file is loaded, it's only after editing things that the cursor starts to drift away.
I'm not sure if it's relevant, but I just wanted to point out that I'm using debian stretch on Chrome OS, which uses Wayland/Sommelier instead of X. Could there be some difference in font metrics because of wayland?
I'm sure it happens without extensions, I just tried it again. And I have not messed with any CSS. I tried but the issue remains. I'm not using an IME. One weird thing I just noticed was when I did a search all, the font changed for each result/item I hovered over, as if getting corrected. It kinda feels like there are two fonts battling... I would've suspected my PC was messed up somehow if it didn't go away every time I downgrade to 1.35. When I upgraded back to 1.36.1 I noticed the font for the release notes looked off, which I recognized from (the font is correct in 1.35). !
Could you please attempt the following: install a free font like Hack or Fira Mono configure I'm trying to understand if this has something to do with our default linux fontFamily, where we use multiple fonts for fallback purposes.
Well, that made the error manifest itself a bit differently.. with the old font family my cursor always got pushed to the right, now it's in the middle of letters when editor.disableMonospaceOptimizations is off: ! With it on it gets like this: ! Like I also have a high DPI display by the way, perhaps that's related?
I want to point out that I'm not using ChromeOS and I have the issue.. I have noticed some font oddities in Chrome as well though. Could this be some chromium wide thing? Was there a chromium/electron upgrade between 1.35 and 1.36?
Yes, 1.36 was the first version of VS Code to ship with Electron 4.
I have this issue too, since 1.36 on ChromeOS. The only extensions I have are Rewrap and Vim. I haven't changed the VS Code CSS. My laptop has a HiDPI display, but I'm using VS Code on a standard-DPI external display. Disabling monospace optimizations fixes the issue for me. Random lines get the cursor drawn to the right of the insert/edit location, and in Vim normal mode I can see the blinking cursor shows the under-cursor character when blinking (at the wrong position), but shows the line's true content when not blinking. Incorrect line content while blinking: ! True line content: ! Here, we can see the cursor pushed waaaay over from the end of the line. The bug seems to get worse the longer the line is. !
I've personally not seen this issue for quite a while. Maybe it was another electron update that fixed it, but that's just a guess.
I have a fresh Crostini install on a fresh Powerwash Chrome OS (beta channel) today and I'm seeing this issue (also my laptop is locking up as I'm working in VSCode, maybe related?)
Same problem with 1.41.1 on Windows. The offset gets worse the further the cursor moves to the right.
Anyone who has seen this, can you verify that it is fixed in VS Code Insiders? Or do you have repro steps?
I was never able to repro, but since nothing is broken I will optimistically add to this.

Discussion:
return true; })(); <ins> let monospaceAssumptionsAreValid = true; </ins> const alwaysRenderInlineSelection = (browser.isEdge); export class DomReadingContext {

sb.appendASCIIString('</div>'); let renderedViewLine: IRenderedViewLine | null = null; <del> if (canUseFastRenderedViewLine && lineData.isBasicASCII && options.useMonospaceOptimizations && output.containsForeignElements === ForeignElementType.None) { </del> <ins> if (monospaceAssumptionsAreValid && canUseFastRenderedViewLine && lineData.isBasicASCII && options.useMonospaceOptimizations && output.containsForeignElements === ForeignElementType.None) { </ins> if (lineData.content.length < 300 && renderLineInput.lineTokens.getCount() < 100) { // Browser rounding errors have been observed in Chrome and IE, so using the fast // view line only for short lines. Please test before removing the length check...

return this._renderedViewLine.getWidthIsFast(); } <ins> public needsMonospaceFontCheck(): boolean { if (!this._renderedViewLine) { return false; } return (this._renderedViewLine instanceof FastRenderedViewLine); } public monospaceAssumptionsAreValid(): boolean { if (!this._renderedViewLine) { return monospaceAssumptionsAreValid; } if (this._renderedViewLine instanceof FastRenderedViewLine) { return this._renderedViewLine.monospaceAssumptionsAreValid(); } return monospaceAssumptionsAreValid; } public onMonospaceAssumptionsInvalidated(): void { if (this._renderedViewLine && this._renderedViewLine instanceof FastRenderedViewLine) { this._renderedViewLine = this._renderedViewLine.toSlowRenderedLine(); } } </ins> public getVisibleRangesForRange(startColumn: number, endColumn: number, context: DomReadingContext): VisibleRanges | null { if (!this._renderedViewLine) { return null;

return true; } <ins> public monospaceAssumptionsAreValid(): boolean { if (!this.domNode) { return monospaceAssumptionsAreValid; } const expectedWidth = this.getWidth(); const actualWidth = (<HTMLSpanElement>this.domNode.domNode.firstChild).offsetWidth; if (Math.abs(expectedWidth - actualWidth) >= 2) { // more than 2px off console.warn(`monospace assumptions have been violated, therefore disabling monospace optimizations!`); monospaceAssumptionsAreValid = false; } return monospaceAssumptionsAreValid; } public toSlowRenderedLine(): RenderedViewLine { return createRenderedLine(this.domNode, this.input, this._characterMapping, false, ForeignElementType.None); } </ins> public getVisibleRangesForRange(startColumn: number, endColumn: number, context: DomReadingContext): HorizontalRange[] | null { const startPosition = this._getCharPosition(startColumn); const endPosition = this._getCharPosition(endColumn);

*--------------------------------------------------------------------------------------------*/ import 'vs/css!./viewLines'; <ins> import * as platform from 'vs/base/common/platform'; </ins> import { FastDomNode } from 'vs/base/browser/fastDomNode'; import { RunOnceScheduler } from 'vs/base/common/async'; import { Configuration } from 'vs/editor/browser/config/configuration';

// --- width private _maxLineWidth: number; private readonly _asyncUpdateLineWidths: RunOnceScheduler; <ins> private readonly _asyncCheckMonospaceFontAssumptions: RunOnceScheduler; </ins> private _horizontalRevealRequest: HorizontalRevealRequest | null; private readonly _lastRenderedData: LastRenderedData;

this._asyncUpdateLineWidths = new RunOnceScheduler(() => { this._updateLineWidthsSlow(); }, 200); <ins> this._asyncCheckMonospaceFontAssumptions = new RunOnceScheduler(() => { this._checkMonospaceFontAssumptions(); }, 2000); </ins> this._lastRenderedData = new LastRenderedData();

public dispose(): void { this._asyncUpdateLineWidths.dispose(); <ins> this._asyncCheckMonospaceFontAssumptions.dispose(); </ins> super.dispose(); }

return allWidthsComputed; } <ins> private _checkMonospaceFontAssumptions(): void { // Problems with monospace assumptions are more apparent for longer lines, // as small rounding errors start to sum up, so we will select the longest // line for a closer inspection let longestLineNumber = -1; let longestWidth = -1; const rendStartLineNumber = this._visibleLines.getStartLineNumber(); const rendEndLineNumber = this._visibleLines.getEndLineNumber(); for (let lineNumber = rendStartLineNumber; lineNumber <= rendEndLineNumber; lineNumber++) { const visibleLine = this._visibleLines.getVisibleLine(lineNumber); if (visibleLine.needsMonospaceFontCheck()) { const lineWidth = visibleLine.getWidth(); if (lineWidth > longestWidth) { longestWidth = lineWidth; longestLineNumber = lineNumber; } } } if (longestLineNumber === -1) { return; } if (!this._visibleLines.getVisibleLine(longestLineNumber).monospaceAssumptionsAreValid()) { for (let lineNumber = rendStartLineNumber; lineNumber <= rendEndLineNumber; lineNumber++) { const visibleLine = this._visibleLines.getVisibleLine(lineNumber); visibleLine.onMonospaceAssumptionsInvalidated(); } } } </ins> public prepareRender(): void { throw new Error('Not supported'); }

this._asyncUpdateLineWidths.schedule(); } <ins> if (platform.isLinux && !this._asyncCheckMonospaceFontAssumptions.isScheduled()) { const rendStartLineNumber = this._visibleLines.getStartLineNumber(); const rendEndLineNumber = this._visibleLines.getEndLineNumber(); for (let lineNumber = rendStartLineNumber; lineNumber <= rendEndLineNumber; lineNumber++) { const visibleLine = this._visibleLines.getVisibleLine(lineNumber); if (visibleLine.needsMonospaceFontCheck()) { this._asyncCheckMonospaceFontAssumptions.schedule(); break; } } } </ins> // (3) handle scrolling this._linesContent.setLayerHinting(this._canUseLayerHinting); this._linesContent.setContain('strict');