Attemp to keep both Text and Visual editors scroll position when switching

[azaozz]

When using editor expand, it is nice to try to keep the scroll positions in case the user quickly switches to the Text editor to add something, then back to the Visual, then back to Text, etc.

[azaozz]

Related: #29338 and https://core.trac.wordpress.org/attachment/ticket/29338/29338.8.patch

[iseulde]

I think it is impossible/hard to estimate the respective position well enough in the other mode. Maybe one way to do it is to insert something at the top, switch and detect it in the other mode, but probably not worth adding so much code for this. Another thing we can do is to save the scroll position when switching the mode and apply it again when switching back. That would mimic the pre-4.0 behaviour. But then in most cases you'll still make some changes in one mode so that the content in the other changes so that by the time you switch back, the content is neither at the scroll position you left it nor at the same position as the mode you just came from. The only benefit would be that you might have to scroll a bit less for really long texts.

[iseulde]

Well, here's another way to do it, and pretty simple. Get the # px scrolled down / editor height, switch modes and apply that percentage to the the new height. In most cases this works pretty well! It won't be exact, but the difference in height is in most cases spread out equally over the entire content.

The only thing we'll need is a beforeShow and beforeHide event in TinyMCE, so we don't have to overwrite those methods.

Moving to 4.2 for consideration.

[azaozz]

Was testing with adding a <span id="wp-caret-position"> at the caret location before switching and removing it right after. Works but has quite a few edge cases which make the code pretty complex (and the more complex it is the more edge cases pop up).

Well, here's another way to do it, and pretty simple.

It is even simpler, see 29492.2.patch. No need for editor.beforeShow/beforeHide, etc.

Not sure if we want to do that though, 50/50 at the moment. Using the scroll ratio comes with a limitation: if there are images or wpViews in the post and the user has scrolled past them, the ratio is totally unusable. Can be more confusing than not scrolling at all. Also, the longer the post, the larger the scroll position error/shift.

[DrewAPicture]

Tested 29492.2.patch​ and as far as I can tell, it doesn't work :-)

I suppose maybe I'm not sure what I should expect. Currently, placing the cursor in the Visual editor and switching to Text it seems the cursor isn't anywhere to be found, and switching back to Visual the cursor is at the end of the post.

I can see the merit in trying to do this, but I'm not sure it's worth spending the bandwidth to try to get it to work.

[SergeyBiryukov]

There's also a ​Preserve Editor Scroll Position plugin, though it didn't work in 4.0+ last time I tried. ​This patch was my attempt at a workaround.

[iseulde]

There's also a Preserve Editor Scroll Position plugin, though it didn't work in 4.0+ last time I tried. This patch was my attempt at a workaround.

I think that's to preserve the scroll position after saving.

I can see the merit in trying to do this, but I'm not sure it's worth spending the bandwidth to try to get it to work.

Imo scrolling to the top is just fine, but then I don't switch as much. It's hard to get this right though. Wontfix?

[azaozz]

Replying to iseulde:

It's hard to get this right though. Wontfix?

Yeah, no matter the method there will always be scroll position errors in 20-30% of the cases. If the accuracy was something over 95%, it would have been great. No point with 70%.

[SergeyBiryukov]

Related: #18943, #7756