Jump to content


Draggable clashes with contenteditable="true" (using Froala Editor)

Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I've just discovered that Draggable will clash with contenteditable="true" elements in a way that:

  • it sometimes puts edit cursor at the beginning of the editable element
  • most of the time it prevents editable content to be edited, except when it contains clickable elements, like A, INPUT, BUTTON...

Example: http://jsfiddle.net/9j2r56md/


... in the example, there are 2 boxes, both enhanced via Froala Editor which basically just adds a DIV with contenteditable="true". First div has data-clickable="true" on the draggable container DIV, so the DIV is not draggable but the issue is still visible. The second one has an additional strange behaviour, as it starts to drag the box when the contenteditable="true" element is clicked.


An updated version is available here that just adds one extra DIV with contenteditable="true" only, so it's obvious that it's not a Froala thing: http://jsfiddle.net/9j2r56md/1/

Link to comment
Share on other sites

Thanks Diaco.AW ... this solves it for me on Desktop and with some modifications on touch devices as well, I guess.

Should this not be kept here and reported as a bug then? Do I mark this as solved?

Link to comment
Share on other sites

Sure, this issue will stay here. We don't delete them.

We will take a deeper look at this and let you know if it is something that can be addressed inside Draggable.


(nice job, Diaco!)

  • Like 1
Link to comment
Share on other sites

Eventually, it would be great if this could be addressed inside Draggable, as I've already came across a use case where a person clicks inside the contenteditable area and moves their mouse away, thus bringing the issue back.


The only way I can work around this now is by creating an "edit" mode which disables all draggables on page, so elements are editable there. This works but needs an additional switch/click added to the workflow, and we're very much trying to avoid such a need :)



Link to comment
Share on other sites

Would you mind trying the updated version of Draggable that I attached to the following post?: http://greensock.com/forums/topic/11342-expose-lockedaxis-variable-in-draggable-object/?p=45957I believe it should work better in your particular scenario. Before officially releasing it, I'd love to get your feedback. 

  • Like 3
Link to comment
Share on other sites

Thanks Jack, I've tried the new Draggable version and it seems that it fixes the ability to click inside the contenteditable areas and start editing. However, the moment I stop typing on a keyboard, the editable area seems to loose focus, which will disable editing the content altogether until I click inside again.


This is the behaviour that has driven me to write this bug report, so the updated version basically solves the ability to click inside a contenteditable but won't allow me to continuously edit that content if I stop typing or move my mouse out of the area.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.