Tinymce: Click events do not fire on touch devices when using contenteditable attribute

[robfenlon]

Elements that have the contenteditable="false" attribute set do not fire click events when tapped on a touch device. Working demo can be seen here. In this demo, there are four elements that we would like to capture click events on. The first two are inside a TinyMCE editor, the second two are outside. In each pair, the first element has the contenteditable="false" attribute set. Each element has a native JS click event, a jQuery click event and a TinyMCE click event registered on it. So for each element, when clicked it should fire off three events. Each event callback has a write to console.log to show it has fired.

Can be reproduced using Chrome device emulator (but also reproduced locally using physical devices).

Without using device emulator:

1. Open dev tools
2. Click each span in the demo
   ER: Each span should write a console log
   AR: Each span writes a console log

Using device emulator in dev tools (I used iPad Pro in landscape but it seems to be consistent across all resolutions)

1. Open dev tools
2. Click each span in the demo
   ER: Each span should write a console log
   AR: The first span does not write a console log

From this, it appears that when a when an element with the contenteditable="false" attribute is touched in TinyMCE, the editor is preventing that event firing at some stage. This causes issues for us, as we use click events on certain editor elements in our application to carry out actions, such as changing the content and showing dialogs, and our application should be usable on touch devices.

[lostkeys]

After a bit of digging the event is prevented here. We still need to investigate why it's there so we don't break anything else.In the meantime, I've been told that you could try listening on the touchend event instead.

[robfenlon]

That's great, thanks Fredrik! We can roll our own event wrapper to keep us going in the mean time 👍

[lnewson]

Using click for touch devices isn't a very reliable option anyways, as there's so many more ways it can be prevented and it's generally a simulated event which isn't actually fired on some devices we've found. As such I'd suggest using the new tap event we added in 5.1.0 for touch devices. It's still a simulated event, but it fires on touchend so it shouldn't be impacted by the SelectionOverrides preventDefault logic.

Note: In 5.1 we only pass back some details from the touchend event, but in 5.2 we've changed it to pass back all the details.