Subsequent image insertion after captioned image causes breakage

[hew]

Repro (trunk):

1. Insert an image with a caption. The Visual Editor should now report a path like this:

   Path: div » dl.wp-caption alignnone » dd.wp-caption-dd
   

2. Immediately click "Add Media" and insert another image again (don't move cursor or anything else) with another caption. The insertion should mangle the previous image and leave a path like this in the Visual Editor:

   Path: div » dl.wp-caption alignnone » dd.wp-caption-dd » div » dl.wp-caption alignnone » dd.wp-caption-dd
   

Bonus: Enter can be pressed in the Visual Editor after step #1. That inserts a new paragraph as expected with the Visual Editor reporting "Path: p". Toggle to the HTML editor and then back to the Visual Editor. The caption element is now active (Path: div » dl.wp-caption alignnone » dd.wp-caption-dd) and an insertion at this point will cause chaos (step #2).

Repro (3.2.1):
Same as trunk except that the "Bonus" (toggling to HTML and back to Visual) does not apply.

Expected behavior:
That a subsequent image insertion would be cleanly inserted without requiring manual cursor movement.

[nacin]

Not much worse in trunk, setting to 3.2.1.

[DrewAPicture]

Related: #18134

[azaozz]

This has been around since image captions were introduced back in 2.7. The problem is that to place the caret in contentEditable mode the browsers need a block level element with some sort of content in it. FF has <br data-mce-bogus="1">, WebKit has U+00A0 (UTF for non-breaking space), etc. So for placing the caret we would need to insert something like <p><br data-mce-bogus="1"></p> or <p>u\00a0</p> after the caption which brings other problems when another caption is not inserted in the editor straight away.

The current behavior is a compromise. On the other hand we probably can re-examine the process of inserting a shortcode in TinyMCE and converting it to a bunch of DOM elements as the browsers have evolved a bit in that area since the last time.

[hew]

I consider myself rather careful yet I inadvertently encountered this problem multiple times trying to arrange some screenshots in a post. It can be pretty painful as a user if the situation arises. The re-examination idea sounds neat.

[azaozz]

Replying to hew:

We can also make the whole image caption <dl> non-editable in the editor. That will prevent inserting anything where it doesn't belong but will also prevent editing the actual caption text which is possible at the moment. This had some problems when trying to drag the image before, seems to be working better now. Still needs some serious testing for all possible actions in all browsers though.

[DrewAPicture]

Related forum thread: ​http://wordpress.org/support/topic/cursor-position-after-inserting-captioned-image?replies=8

[azaozz]

Will make a patch that adds another <p> after each caption (as described in comment 3) so this can be tested in action.

Could also be fixed by looking at the caret position before inserting a caption. If it's already in a caption, can try to move it after.

[azaozz]

This is handled in the new media workflow. Closing as a subset of #21390.

[nacin]

Worth pursuing?

[azaozz]

Replying to nacin:

Yes, been testing few things that would fix this and any 'send_to_editor()' while a captioned image is selected. Will have updated patch later today.

[trepmal]

#22457 was marked as a duplicate.

[azaozz]

19389-2.patch works well in all supported browsers. Couldn't find any side effects/interactions with other functionality too so thinking to commit it for further testing.

[azaozz]

In 22644:

TinyMCE: place the caret after/under images with captions when inserting content, fixes #19389