Page MenuHomePhabricator

Visual editor should preserve text selection status on editor startup
Open, Needs TriagePublicFeature

Description

One of the most annoying things about VE is that the article text reflows when the editor starts. So every time I want to make an edit, I have to start by doing a search to find where I was before I clicked the "edit" link. Consider this sequence of screenshots:

Screenshot 2023-12-03 at 10.47.14 AM.png (2×2 px, 2 MB)

Screenshot 2023-12-03 at 10.47.30 AM.png (2×2 px, 1 MB)

Screenshot 2023-12-03 at 10.47.46 AM.png (2×2 px, 1 MB)

In the first one, I have found a word I want to change ("operation") and highlighted it. In the second, I have scrolled back to find the nearest "edit" link. In the third, the editor has started. Note that at this point, the word I want to change is no longer visible on the screen. In fact (not shown in a screenshot) if I scroll back down to it, it's no longer highlighted, so I have to start searching for it. In this case, there are five instances of "operation" in the article that I have to look at before I find the right one. Imagine if I wanted to change "the", which appears 325 times?

Sometimes what I do is select a bunch of surrounding text, copy it, click "edit", then do a find and paste that text into the search bar. But that often doesn't work because the copied text includes the interpolated output of templates, which VE's find doesn't recognize.

I am not a javascript/DOM expert, but wouldn't it be trivial to make a call to window.getSelection() before invoking the editor, remembering that, re-select that text after the editor starts, and use element.scrollIntoView() to get back to it? This would be a huge win for productivity.

Event Timeline

I am not a javascript/DOM expert, but wouldn't it be trivial to make a call to window.getSelection() before invoking the editor, remembering that, re-select that text after the editor starts, and use element.scrollIntoView() to get back to it?

Unfortunately not. The issue with that approach is that the text you see before you start editing and the text you see afterwards are completely different sets of elements, so having the pre-edit selection doesn't automatically translate into a post-edit selection.

There's some further discussion of the issue here in T296910, which is where we implemented preserving the (approximate) scroll position when you enter VE from the vector 2022 floating toolbar.

That said, this is another on the pile of tasks that'll potentially get simpler as the Parsoid read-views roll out, because then VE and read-mode will be operating off of basically the same HTML.