WordPress.org

Make WordPress Core

#22257 closed defect (bug) (fixed)

Visual editor is locked after inserting an image/a gallery

Reported by: ocean90 Owned by: koopersmith
Milestone: 3.5 Priority: low
Severity: normal Version: 3.5
Component: TinyMCE Keywords: needs-patch
Focuses: Cc:

Description

From the alpha/beta forum

  • Create a new post
  • Switch to visual editor if not yet
  • Insert an image through the new media modal
  • Try to add some text to the editor

The last step doesn't work in Chrome and Safari. Seems like the editor is locked.

Attachments (2)

22257.patch (3.5 KB) - added by azaozz 18 months ago.
floated-views.png (44.9 KB) - added by azaozz 17 months ago.

Download all attachments as: .zip

Change History (11)

comment:1 ocean9018 months ago

  • Priority changed from normal to high

comment:2 ocean9018 months ago

#22313 was marked as a duplicate.

comment:3 azaozz18 months ago

Been looking at this for some time. The only way to place the caret before/after a "view" is to have a visible spaces there. That means we will have to change the styling for block element views (make them inline-block with width=99%) so the before/after spaces aren't pushed on separate lines, or it looks like there are empty lines above/below the view.

azaozz18 months ago

comment:4 follow-up: azaozz18 months ago

In 22257.patch:

  • Add padding before and after a view if the surrounding strings don't end/begin with a space.
  • Drop the 'div' view wrapper. All wrappers are now spans with display: inline-block (todo: remove the wrapper from the view options).
  • Some css tweaks to display the image and gallery views properly.

comment:5 in reply to: ↑ 4 koopersmith18 months ago

I'm loving the comments in 22257.patch.

comment:6 koopersmith18 months ago

From quick testing, the spacing doesn't seem to be respecting any of the alignment classes. In some alignment cases, I'm seeing carets that place text before the view appearing after the view, and in others, I'm seeing carets that place text after the view appear before the view.

Any ideas?

azaozz17 months ago

comment:7 azaozz17 months ago

Yeah, that's when the view wrapper is floated. The spaces are normal text nodes around it, so they follow the normal css logic and move to the opposite side of the floated view.


Another thing I've tested was to add space only after a view (if there's no text node or if the text doesn't start with a space). This wouldn't let the caret to go before a view but that will be a problem only if the view is the first element in the post, pretty much the same as images behave in 3.4.

Then we can insert a zero-width text node and force the caret in it when the left arrow key is used for navigation.

Yet another possibility would be to do that on both sides, i.e. when a view is selected, pressing the left/right arrow key would insert zero-width text note and force the caret there. Tried that too but didn't work straight away (currently the views "lock" the caret when it reaches them and attempts to get it out of there don't work).

Last edited 17 months ago by azaozz (previous) (diff)

comment:8 nacin17 months ago

  • Priority changed from high to low

Removing views, see #21813 (comment 30), should resolve this for 3.5.

comment:9 koopersmith17 months ago

  • Owner set to koopersmith
  • Resolution set to fixed
  • Status changed from new to closed

In 22567:

Media: Restore 3.4 editor behavior and remove TinyMCE views.

  • Reactivates the wpgallery and wpeditimage TinyMCE plugins. Deactivates the wpviews TinyMCE plugin.
  • Moves still-relevant logic from mce-views.js to media-upload.js and shortcode.js.
  • No longer include wp-includes/js/mce-views.js. This code will not be used in 3.5, and should be considered unstable.
  • Currently, this is the real 3.4 experience; as such, editing triggers the old modals. Changing this is the next major step.

When reassessing views, we should look over all of these tickets and anticipate these bugs accordingly.

fixes #21813, #22123, #22155, #22161, #22257, #22266, #22318, #22407, see #21390.

Note: See TracTickets for help on using tickets.