WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#42059 closed defect (bug) (fixed)

Editor: preview for embedding from URL breaks on switching Text to Visual when selected

Reported by: azaozz Owned by: biskobe
Milestone: 4.9 Priority: normal
Severity: normal Version: 4.9
Component: Editor Keywords: has-patch needs-testing
Focuses: Cc:

Description

To test:

At this point the preview is not shown, the URL remains as string. If the selection is outside the URL in Text mode, the preview is shown properly.

Attachments (3)

42059.diff (5.9 KB) - added by biskobe 4 years ago.
42059.2.diff (9.7 KB) - added by biskobe 4 years ago.
42059.3.diff (9.0 KB) - added by biskobe 4 years ago.

Download all attachments as: .zip

Change History (13)

#1 @azaozz
4 years ago

  • Keywords needs-patch added
  • Owner set to biskobe
  • Status changed from new to assigned

#2 @azaozz
4 years ago

Couple more ideas:

  1. Instead of using span(s) for the selection marker, perhaps better to use a zero-width element like <wbr data-wp-selection="start|end" />. These will be quite easier to remove from HTML strings. We can also style them in CSS, no need for inline styles.
  1. Keeping selected text is ok, but not essential imho. It's rare to switch editors while something is selected. The important part is to keep the position of the caret and to scroll to it after switching. If there is a selection, consider collapsing it to the beginning and using only one <wbr> for a marker. For images, shortcodes, and other embeddable "blocks" we can collapse to before the beginning, even insert an empty paragraph in MCE then remove it after switching to Text. That way all previews and "dynamic blocks" will work properly no matter where they come from.
Last edited 4 years ago by azaozz (previous) (diff)

#3 @biskobe
4 years ago

Instead of using span(s) for the selection marker, perhaps better to use a zero-width element like <wbr data-wp-selection="start|end" />. These will be quite easier to remove from HTML strings. We can also style them in CSS, no need for inline styles.

Great suggestion. Going to implement that, together with the other issues you mentioned in the ticket.

Keeping selected text is ok, but not essential imho. It's rare to switch editors while something is selected. The important part is to keep the position of the caret and to scroll to it after switching. If there is a selection, consider collapsing it to the beginning and using only one <wbr> for a marker.

I kind of disagree with that. It's not common, because we're used to not having the selection transferred between the Editor modes. Keeping the whole selection creates a better experience as the user can see what they have selected when going to the other mode.
Collapsing the selection to either end will only give us the cursor, which is hard to find in either mode. Imagine having a full screen of text and you have to find a tiny cursor that blinks somewhere in it.

That way all previews and "dynamic blocks" will work properly no matter where they come from.

So far the only exception I could see to the general Dynamic Blocks / Live Preview is the URL embed issue you mentioned in the ticket, as it's not a defined shortcode with a Live Preview functionality. Do you see any possibility of having dynamic blocks that do not follow the general rule for Live Preview? If there is such case, it would be awesome to see it and test with it, since even having a single marker can break them if it's not positioned properly.

@biskobe
4 years ago

#4 @biskobe
4 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

#5 @biskobe
4 years ago

Things the patch fixes:

  • Pasted URLs are now treated as blocks. If the cursor is inside one of them, the cursor will be pushed to the start/end of the URL, like HTML tags and shortcodes are treated.
  • Refactored underscore.js usages to use native JS
  • Marking the selection markers as data-mce-bogus as early as possible, so they are removed from the content if something happens down the line in the script.

#6 @biskobe
4 years ago

@azaozz I decided to forego the migration to <wbr data-wp-selection="start|end" />, since it introduced some interesting issues with detecting the selection positions and at least Chrome can't detect its position on the page, since it's rendered display: inline by default.

I'll be happy to circle around later after finishing up issues that may arise from testing the selection functionality.

@biskobe
4 years ago

#7 @biskobe
4 years ago

42059.2.diff adds some more improvements over the previous patch:

  • A fix for a JS error that was reported in #40854 ( https://core.trac.wordpress.org/ticket/40854#comment:33 ).
  • Introduced Editor settings/properties to allow/disallow selection keeping and scrolling to the selected position.
    • They're false by default.
  • A minor cleanup to remove a parameter that was passed, but wasn't required by the function.

@biskobe
4 years ago

#8 @biskobe
4 years ago

42059.3.diff merges the wp_keep_editor_selection and wp_keep_scroll_position properties into only wp_keep_scroll_position to keep things simple.

#9 @azaozz
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 41783:

Editor:

  • Fix keeping text selection and scroll position when there are embeds from URL.
  • Add editor setting to disable keeping selection and scroll position.
  • Remove dependency on Underscore.js.
  • Fix error in the Text widget editor.

Props biskobe.
Fixes #42059, see #40854.

#10 @SergeyBiryukov
4 years ago

In 41785:

Editor: Fix JSHint errors after [41783].

See #42059.

Note: See TracTickets for help on using tickets.