Issue Type: Bug
Codelens affects the hit test of mouse position when selecting text by moving mouse.

As shown above, I have trouble selecting to the end of the line.
VS Code version: Code - Insiders 1.42.0-insider (fd13e449f5f2fe300f187129d6065ed1cfad74d3, 2020-01-17T16:30:38.851Z)
OS version: Darwin x64 19.2.0
System Info
|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (16 x 2400)|
|GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled|
|Load (avg)|2, 2, 2|
|Memory (System)|32.00GB (4.78GB free)|
|Process Argv|-psn_0_17432735|
|Screen Reader|no|
|VM|0%|
Extensions (9)
Extension|Author (truncated)|Version
---|---|---
comment-tagged-templates|bie|0.3.0
github-markdown-preview|bie|0.0.2
markdown-emoji|bie|0.0.9
markdown-preview-github-styles|bie|0.1.6
gitlens|eam|10.2.0
vscode-pull-request-github-insiders|Git|2020.1.11042
remote-ssh-edit-nightly|ms-|2020.1.11041
remote-ssh-nightly|ms-|2020.1.11041
debugger-for-chrome|msj|4.12.5
(2 theme extensions excluded)
@rebornix I have tried with:
settings.json: "typescript.referencesCodeLens.enabled": true
test.ts:class C {
readonly isClosed: boolean;
constructor() {
this.isClosed = true;
}
}
const c:C;
c.isClosed;

And I could not reproduce.
Perhaps there are more steps to it? Did you try disabling all extensions, I see that there is a git lens decoration on that line.
I am also seeing this, but it seems like an issue with gitlens, not codelens.
This appears to be a result of using margin in the after decoration. Here is an extension I can reproduce with:
package.json{
"publisher": "alex",
"name": "40127",
"version": "0.0.0",
"engines": {
"vscode": "^1.0.0"
},
"activationEvents": [
"*"
],
"main": "index.js"
}
index.js:const vscode = require('vscode');
exports.activate = function () {
const dectype2 = vscode.window.createTextEditorDecorationType({
after: {
contentText: "abcd",
color: "#00ff00",
margin: "0px 0px 0px 3em"
}
});
vscode.window.activeTextEditor.setDecorations(dectype2, [
new vscode.Range(0, 1000, 0, 1000),
new vscode.Range(1, 1000, 1, 1000),
new vscode.Range(2, 1000, 2, 1000),
new vscode.Range(3, 1000, 3, 1000),
new vscode.Range(4, 1000, 4, 1000),
new vscode.Range(5, 1000, 5, 1000),
new vscode.Range(6, 1000, 6, 1000),
new vscode.Range(7, 1000, 7, 1000),
new vscode.Range(8, 1000, 8, 1000),
new vscode.Range(9, 1000, 9, 1000),
]);
}
I could reproduce in Chromium and have created https://bugs.chromium.org/p/chromium/issues/detail?id=1043471 upstream.
FYI @eamodio The usage of margin in the ::after element (the inline blame) makes hit testing incorrect. There is no clear workaround available on our side.
@alexdima Is this new with Electron 7?
I don't know.
I think this was caused by a change to vscode, not gitlens. I have a second plugin Error Lens that is seeing the same issues.

Indeed, I cannot reproduce on Stable, and since this is a Chromium issue, this is caused by our Electron 7 upgrade on Insiders.
Adding important as more members of the dev team are hitting this -- @jrieken
This makes it very hard to click after a line so that the cursor is at its end. In 9 out of 10 cases selection jumps to the line start
As a temporary workaround, can you see if the issue repros when launching code with --disable-features="LayoutNG"
It seems like the selection jumping is just a side effect of incorrect mouse coordinates offset. Here is a more complete bug demo for full context

Has something changed in the latest insiders version (c4b6a6b537de49a734d0eedea06152ea37dfdb6a)? It looks like the issue is resolved as far as I can tell, but it also looks like Electron is back to 6.x.
@dlong500 Yes, in preparation for our upcoming release, we have rolled back Insiders to Electron 6.0. Once we ship stable, we will upgrade Insiders again to Electron 7.0, which has this issue.
I noticed that if you have "gitlens.currentLine.scrollable": false, you can see this offset issue happen to the entire line instead of just the gap between the lens text and the code, even with deepak1556's workaround. Might be worth noting.
I pushed a change to always configure to disable LayoutNG.
@alexr00 can you also confirm this is fixed for you with latest?
It looks good to me
Fixed by upstream fortunately https://crbug.com/1043471#c11
Backporting the chromium fix to Electron 8 turned out non-trivial because of the changes between versions and also I am not familiar with LayoutNG code path. I have backported the fix to Electron 9 for now, will enable LayoutNG when we adopt this version. If anyone else is interested in backporting the fix to Electron 8, feel free to. I can help with development setup quesitons.
Should be fixed in latest insiders.
Most helpful comment
As a temporary workaround, can you see if the issue repros when launching code with
--disable-features="LayoutNG"