WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#29492 closed enhancement (wontfix)

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

Reported by: azaozz Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.0
Component: Editor Keywords: has-patch
Focuses: javascript Cc:

Description (last modified by 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.

Attachments (2)

29492.patch (3.6 KB) - added by iseulde 5 years ago.
29492.2.patch (1.9 KB) - added by azaozz 5 years ago.

Download all attachments as: .zip

Change History (11)

#2 @iseulde
5 years ago

  • Focuses javascript added
  • Keywords close added

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
5 years ago

#3 @iseulde
5 years ago

  • Keywords has-patch added; close removed
  • Milestone changed from Awaiting Review to 4.2

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
5 years ago

#4 @azaozz
5 years ago

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.

Last edited 5 years ago by azaozz (previous) (diff)

#5 @DrewAPicture
5 years ago

  • Keywords reporter-feedback added

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.

#6 @SergeyBiryukov
5 years ago

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.

#7 follow-up: @iseulde
5 years ago

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?

#8 in reply to: ↑ 7 @azaozz
5 years ago

  • Milestone 4.2 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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%.

#9 @SergeyBiryukov
5 years ago

  • Keywords reporter-feedback removed

Related: #18943, #7756

Note: See TracTickets for help on using tickets.