Prettier formatting causes document to jump with insiders

[eamodio]

Issue Type: Bug

This started very recently and is not reproducible with the same setup on 1.32. Often when I am editing a decent size (~1000 lines) js/ts/tsx file and I save the file and the prettier extension kicks in and re-formats the document jumps down by a page or 2 and the cursor ends up at the very end of the file. It only seems to happen with larger files, and is reproducible every time I add a bunch of blank lines and then save.

While this might be an issue with the prettier extension itself, it doesn't happen in 1.32 and I know there was work done to code formatting this iteration.

VS Code version: Code - Insiders 1.33.0-insider (4d1cb56, 2019-04-03T08:14:19.284Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 x 4008)
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 surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Memory (System)	31.93GB (15.97GB free)
Process Argv
Screen Reader	no
VM	0%

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Prettier extension is not longer working in vscode Insiders. (#68155)

[jrieken]

it doesn't happen in 1.32 and I know there was work done to code formatting this iteration.

Are you really sure that in 1.32 prettier was used for formatting? Before 1.33 it wasn't well defined which formatter was used and I am asking because we changed a lot how we pick formatters but not how the actual formatting edits are applied.

[eamodio]

Yeah, it was using prettier extension formatter. And it was fine for most of the insiders of 1.33 until the last week or so. And to be clear the formatting is working just fine, it's just that after the format (on save) the editor is scrolled down a page or 2 below where the cursor was and the cursor gets placed at the end of the file.

[jrieken]

And this changed with format-on-save only or all formatting?

[martinschayna]

I can confirm this bug too, it occurs only when "editor.formatOnSave": true. Whenever I save the file, its content is reformatted and the cursor caret is moved to the end of the file, but the visible area of text keeps the same (or is moved slightly according to changes made by Prettier).

For "editor.formatOnSave": false and applying Format Document action, everything is fine.

I'm pretty sure that this bug is a regression, it's been here several months ago and was fixed.

[HerveSeger]

I fully second @eamodio and @martinschayna on this issue. I have exactly the same problem since my upgrade to 1.33 yesterday.

The pattern described by @martinschayna is accurate.

[jrieken]

Indeed an unfortunate regression. Before, we would attempt to apply the formatting edits using the editor (when available during save) and now we always use the model (which is not as good as using the editor itself).

[fabb]

I noticed the same bug since updating to the newest VSCode version two days ago.

[olafurpg]

This regression is not limited to the Prettier extension, it also impacts language servers that implement textDocument/formatting. A workaround is to downgrade to 1.32 by downloading VS Code from here https://code.visualstudio.com/updates/v1_32

I'm wondering if it would be possible to update the DocumentFormattingEditProvider API (https://code.visualstudio.com/api/references/vscode-api#DocumentFormattingEditProvider) so that the request could optionally include the old cursor position and the result could return the new cursor position 🤔 In some cases the formatter can provide this information

[TomasB]

Happens only when file size is > 10000 bytes.
Happens only when go formatter changes content of the file that is being saved.

To reproduce:

get a file with 10000 bytes.
add a space somewhere which is going to be removed by formatter (at the end of a line will do the trick)
now you have 10001 bytes. Upon saving, your cursor will jump to the end of the file.
Now, make your file 9999 bytes, do the same, and your cursor position will be preserved.

Yet another test:

get a file with 10000+ chars
add some content that formatter won't be removing (add some chars to a string, or comment (not to the end of the line, though)
saving will maintain the cursor's position
Conclusion: cursor's position is lost (goes to the end of file) when file size > 10000 and golang formatter changes file

[jrieken]

This is fixed (for next insiders) and will also be part of 1.33.1

[delgermurun]

Hello @jrieken,

Thanks for the quick fix. When it will merge into a stable release? or how often stable release occurs?

[Racle]

microsoft/vscode-go#2426 (comment)

Some reformatting issues still happening after 1.34.0-insider

vscode-go extension: 0.9.2
vscode version: 1.34.0-insider
Commit: 07d9e44
Date: 2019-04-10T05:13:47.193Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.15.0-47-generic (Ubuntu 18.04)

After ctrl+s, cursor doesn't jump to bottom of file anymore (like it did in 1.33)
BUT
If I add space after row and press ctrl+s, cursor moves to start of next line.
If I add space inside row and press ctrl+s, cursor stays in static place, so losing "correct" place in code after automatic reformat.

Screen record: https://i.imgur.com/nV7urMG.gif
First is old behaviour (1.33), then switching to 1.34.0-insider

This might be issue with vscode instead of vscode-go, as result changes while updating vscode, but keeping same extension version.