Programming exercises: Scrolling position does not persist over a file switch in the online editor

[BaumiCoder]

Describe the bug

When I use the new online editor (Monaco) the scrolling position of the editor is always on the top of a file after opening it. I would expect that the previous scrolling position be retained for each file.

This problem applies to online editor for student submission (#8130) and for the online editor for instructors (#8389). Technically it should be quite the same situation.

To Reproduce

Example for the student submisson:

1. Go to a Programming Exercise that allows the usage of the online editor for submissions.
2. Open the exercise with the online editor
3. Open a file (lets call this file1)
4. Scroll down some lines
5. Switch to another file
6. Switch back to file1

Expected behavior

The editor is still in the scrolling position from step 4.

Screenshots

The editor is again at the top of the file.

Which version of Artemis are you seeing the problem on?

7.0.0

What browsers are you seeing the problem on?

Firefox

Additional context

The situation in the online editor for instructors (#8389) was tested with the branch feature/programming-exercises/monaco-instructors at Commit 25d4fe5.

Relevant log output

No response

[BaumiCoder]

A similar problem with the old online editor was reported in #7393.

[pzdr7]

Thanks for reporting - I'll have a look

[pzdr7]

There are two underlying problems:

• setting the cursor position does not scroll it into view (and the editor is not focused when you select a different file)
• we're not updating the stored cursor position at the correct moment (needs to happen when we switch files, rather than when the file is modified)

I think Monaco provides a nice solution for this. There's a method saveViewState that stores the current position of the editor, its scroll position (among other things) and returns an object containing this information. Instead of manually restoring the cursor position, we could try saving and restoring the view state of the editor instead.

We'll have to see how this interacts with the feedback widgets rendered in the editor, though

(Edit: after trying it locally - the widgets do cause problems here, as they are rendered just a little bit later than the rest of the editor. we'll have to be careful about when to restore the view state of the editor)