Bug 12250 – No support for "control selections" to select or drag images in editable content (affects TinyMCE, FCKEditor and Vox)

• Status: ASSIGNED
• Component: HTML Editing

In an editable document, there are no ways to select objects, like images, form fields and tables. Also, not being able to select them, it is not possible to drag them inside the editor contents and no context menu is also available for the specific objects.

[Justin Garcia]

Retitling.  It is possible to drag and drop any element in an editable region afaik, but doing so is tricky for some elements, like form fields and tables.  The issue here is really that you can't create control selections around single elements.  Control selections appear in FF and IE when the user clicks on certain elements, like tables, form fields, and images.  The control selection allows the user to easily resize and drag these elements.  We don't yet support this type of selection.

[Justin Garcia]

*** Bug 7154 has been marked as a duplicate of this bug. ***

[Justin Garcia]

Re-titling as this effects all the editors

I would say that for now it is not important to resize objects, showing the resize handlers. The most important and basic feature is the simple possibility of selecting them. So, a user clicks on it and it gets the selection.

This is what Opera proposes today. They only show a simple border in objects when clicking them. No resize, but it is ok for now.

By not being able to select an image, there is no way to change its properties, which is a very basic feature of a text editor like FCKeditor.

[Galen Rhodes]

This is a problem for our project since the users want to be able to resize images using TinyMCE and for now we're telling them to use Firefox or Camino and they're not happy about that.  They want to use Safari and they're blaming us for it.

[David Kilzer (:ddkilzer)]

<rdar://problem/5696409>

[Justin Garcia]

I'm working on this.

[Justin Garcia]

Created attachment 20078 [details]
first cut

[Moxiecode Systems]

This is really good news. I hope that you guys implement the ability to do the image selection from JS as well. This is currently only possible in IE with their control range type. But it should be possible to check when the focusNode and anchorNode of the Selection object is set to an image element it selects it with some dotted border basically the same thing as selecting it with the mouse. This is not very important but more of a nice to have since it will then be better than most other browsers out there.

[Justin Garcia]

Created attachment 20119 [details]
updated patch

[Justin Garcia]

> I hope that you guys implement the ability to do the image selection from JS as 
> well. This is currently only possible in IE with their control range type.

Probably not in the first pass, but I definitely want to do this eventually.

[Sigurd Magnusson]

Justin - love to see this patch progressed and shipped with Safari 3 or 4 as it is one of the few things that causes major usability reduction in Safari with the SilverStripe open source CMS (http://www.silverstripe.com)

It affects us in this way: http://open.silverstripe.com/ticket/1687

[philip magnusson]

This seems to still be an issue for safari as far as I can see - at least with PC-safari combination.  

[Jubal Kessler]

Using Webkit nightly ("41443") version "530.1+", OS X 10.5.6.

When using FCKEditor version 2.6.4 (21629), and inserting an image in the textarea, I am unable to afterward select the image object and change its properties.

I have not tried with Safari 4 beta, but given I'm running a recent nightly, I doubt anything has changed.

I notice that this bug was opened 26 months ago, and a patch has been attached, yet the bug still has a status of "NEW". This is discouraging.

I look forward to a resolution, either with WebKit or with FCKEditor.

[Michael B]

Looking forward to updates on this case. I had to write special code for Safari to be able to select an image and to display handles around it's edges, enabling users to resize the image.
It solves the problem for now, but is it the right way to go?
Using Safari 4 beta 528.16 on windows.

[Alexey Proskuryakov]

This bug seems to have an unfortunate mismatch between title and content. Is it about control selections, or just about being able to single-click to select an image? The latter has been also reported as bug 29125, and I'm not sure if it should be marked as a duplicate.

[Qazaq]

This 'bug' (missing feature) is the main reason why all my clients are advised to use Firefox instead of Safari / Chrome.
Any updates on this subject would be very welcome.

Is anyone still working on this? Is there any plan to fix it?

I am in the same position as many others. I would love to recommend Chrome to people (heck I would like to use it myself), but this one lacking feature stops me from doing so.

This even breaks google docs when you use chrome.

Looking forward to an update.

[Qazaq]

Chrome 5 and still no way of resizing objects. I would be really interested in having this feature added.
Any update on this would be very very welcome.

[Justin Garcia]

I'm not currently working on this.

[Andrew]

Bump!
This feature would be very nice.

[alexbk66]

I like that it's assigned to nobody! So there's no intention to fix the bug?
All my customers are switching to Firefox or IE (even if everybody hate MS) :(

[Ojan Vafai]

There's a lot of comments on this bug. Just to be clear, the core request here is that WebKit select the element when you click on an image or form control. Stated more generally, clicking on an element with unselectable children should select the element?

For example, the following cases?
<img>
<input>
<textarea>
<div style="-webkit-user-select:none">foo</div>

I'm not sure what the ask is for tables. If you click on a table, presumably we should be putting a text cursor inside the table.

(In reply to comment #23)
> Stated more generally, clicking on an element with unselectable children should select the element?

This sounds correct and it's a good way to define it.

> For example, the following cases?
> <img>
> <input>
> <textarea>
> <div style="-webkit-user-select:none">foo</div>

Correct. I would also add <span contenteditable=false> and the such. Basically, anything that can't be edited inside.

> I'm not sure what the ask is for tables. If you click on a table, presumably we should be putting a text cursor inside the table.

IE makes it possible to select the table only, by clicking on it's border. It's a nice feature. Firefox instead has another nice one, where you can click and drag through table cells to select them. So even cell selection is possible. Those features, while not totally required, are definitely wanted.

[Kalle]

Please fix this problem as soon as possible!!!

More and more people are using Chrome/Safari and a lot of our support issues are currently about this single issue.

The only recommendation we can give our customers today is to use Internet Explorer or Firefox instead of Chrome/Safari and that is not a good recommendation, but it is the only one we can give since this issue has not been fixed :(

[Vidar Langberget]

Like a lot of the other comments are saying, we are forced to recommend users of our CMS to use non-webkit browsers due to this issue. 

When are you going to fix this critical issue?

[Alexey Proskuryakov]

It seems that bug 29125 tracks selecting images in editable content, and bug 68801 tracks adding resize handles.

I'm not sure if there is anything actionable left in this bug. It appears to only confuse everyone, as people add "met too" comments without clarifying what exactly they need. Should we close this one, and track specific parts separately?

[Ryosuke Niwa]

(In reply to comment #27)
> It seems that bug 29125 tracks selecting images in editable content, and bug 68801 tracks adding resize handles.

I don't think this bug blocks the bug 68801 since control selection doesn't necessarily provide resizing UI (e.g. Opera). Rather, this bug blocks the bug 68801.

> I'm not sure if there is anything actionable left in this bug. It appears to only confuse everyone, as people add "met too" comments without clarifying what exactly they need. Should we close this one, and track specific parts separately?

I think it's worth keeping this bug so that people can find it by the keyword "control selection(s)".

[Ryosuke Niwa]

*** Bug 29125 has been marked as a duplicate of this bug. ***

[Pablo Mazaeda]

Please, fix this bug!

[alexbk66]

The problem exists for 5 years now, shocking!

[Elijah Lynn]

Here are three issues that I know of that are waiting for this bug fix/feature request.

http://drupal.org/node/746490 (2010.03.18)
http://drupal.org/node/367655 (2009.02.01)
http://www.tinymce.com/forum/viewtopic.php?pid=71770 (2008.10.29)

Now, there does seem to be a Javascript hack which I will try shortly but I would rather not add bloat to a page if I don't have to. http://www.editorboost.net/webkitresize

[Ryosuke Niwa]

Created attachment 158167 [details]
Shadow DOM-based approach - WIP prototype 1

[Ryosuke Niwa]

Created attachment 158169 [details]
Screenshot

Oops, sorry, you need to modify the patch to use ShadowRoot::AuthorShadowRoot instead of UserAgentShadowRoot because it relies on HTMLImageElement's native shadow being alive.
The image appears properly when I click for the first time, but it disappears as soon as I move the selection away. It appears that the shadow element doesn't have the right intrinsic width and height :(

[Ryosuke Niwa]

Created attachment 158170 [details]
Screenshot 2 - the image has disappered

This second screenshot shows what happens when I click outside of the image. The image simply disappears :(

[Ryosuke Niwa]

Created attachment 158178 [details]
Shadow DOM-based approach - Delete old shadow roots

[Ryosuke Niwa]

Created attachment 158194 [details]
Shadow DOM-based approach - prototype 2; just adds resizing corners

[Ryosuke Niwa]

Created attachment 158522 [details]
Shadow DOM based approach - prototype 3 (kinda works)

The image in the shadow DOM doesn't resize properly due to the bug 94077 but everything else works more or less.

[Ryosuke Niwa]

Comment on attachment 158169 [details]
Screenshot

This screenshot is still a good representative of the prototype.

[Ryosuke Niwa]

Created attachment 158980 [details]
work in progress 5

[Ryosuke Niwa]

Created attachment 159042 [details]
work in progress 6

[Nate Haug]

@Ryosuke Niwa, really excited to see this being taken on! With Chrome being the new dominant browser this sort of problem with WYSIWYG editors isn't something I can rationalize away with my clients.

p.s. Looks like we're almost neighbors! I live nearby in Berkeley. Free beers on me when we meet. :D

[Elijah Lynn]

(In reply to comment #42)
> @Ryosuke Niwa, really excited to see this being taken on! With Chrome being the new dominant browser this sort of problem with WYSIWYG editors isn't something I can rationalize away with my clients.
> 
> p.s. Looks like we're almost neighbors! I live nearby in Berkeley. Free beers on me when we meet. :D

For everyone who is finding this via Google and also uses TinyMCE, v3.5.5 has issued a fix for this bug. 

http://www.tinymce.com/forum/viewtopic.php?id=29222

[WebKit Review Bot]

Attachment 159042 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/WebCore.exp.in', u'Source/W..." exit_code: 1
Source/WebCore/editing/FrameSelection.cpp:51:  Alphabetical sorting problem.  [build/include_order] [4]
Source/WebCore/editing/FrameSelection.cpp:76:  Alphabetical sorting problem.  [build/include_order] [4]
Source/WebCore/editing/FrameSelection.cpp:2114:  This { should be at the end of the previous line  [whitespace/braces] [4]
Total errors found: 3 in 7 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[WebKit Review Bot]

Comment on attachment 159042 [details]
work in progress 6

Attachment 159042 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14391155

New failing tests:
editing/pasteboard/drag-selected-image-to-contenteditable.html
fast/forms/range/slider-delete-while-dragging-thumb.html
editing/undo/orphaned-selection-crash-bug32823-2.html
editing/pasteboard/styled-element-markup.html
editing/selection/drag-to-contenteditable-iframe.html
editing/inserting/replace-at-visible-boundary.html
fast/replaced/selection-rect-in-table-cell.html
editing/pasteboard/drag-image-to-contenteditable-in-iframe.html
fast/loader/text-document-wrapping.html
editing/deleting/delete-image-003.html
http/tests/security/drag-drop-same-unique-origin.html
editing/selection/select-missing-image.html
fast/forms/range/slider-mouse-events.html
fast/replaced/selection-rect-transform.html
editing/pasteboard/drag-and-drop-image-contenteditable.html
editing/pasteboard/drag-drop-iframe-refresh-crash.html
editing/pasteboard/drag-image-in-about-blank-frame.html
editing/pasteboard/4989774.html
http/tests/xmlhttprequest/xmlhttprequest-unsafe-redirect.html
editing/deleting/delete-image-004.html
editing/pasteboard/4947130.html
fast/events/drag-selects-image.html
fast/loader/javascript-url-in-object.html
editing/execCommand/remove-format-image.html
editing/execCommand/5080333-2.html
fast/events/standalone-image-drag-to-editable.html
fast/forms/range/slider-onchange-event.html
editing/selection/doubleclick-whitespace-img-crash.html
editing/selection/legal-positions.html

[Alex]

Any news about this? It's a rather basic feature for any contenteditable editor.