Assign to Art to review the delegate scenario to see what can be done, if anything, to support it as well.

The delegate mode is implemented in the menu.js resource, in the ice.ace.ContextMenu function (constructor). As it can be seen in that function, the DOM event registered on the delegate container is the 'contextmenu' event. That doesn't seem to be triggered by a long press on touch devices, so the delegate mode doesn't work at all for ace:contextMenu on these devices. What could be done is to also register the same event handler on the 'touchstart' event, and we would have to do the same thing that wijmo is doing to detect a long press, which seems to consist in setting a timeout function that gets to be executed if there's a touchend event registered after certain amount of time.

Added conext menu delegate callback on 'touchstart' event in menu.js.

Verified long touch ios functionality ICEfaces 4 trunk r51693, Tomcat 8, ipad ios 10.3.2 however sometimes when using a long press I end up with both the contextMenu and the native functionality such as 'select all' and 'copy'.
When testing on android 6.0.2 nexus 5 device performing a long press over text does not always render the contextMenu, usually only the native menu appears. When the contextMenu menu finally does render it appears to flicker.

The current behaviour is as good as we can make it with the available APIs in the mobile browser. It is unavoidable to have the native mobile OS features activating on the long press causing text selection and/or the native browser content menu to appear in addition to the ace:contextMenu. If we attempt to block the native events to prevent the native features such as pinch to resize and drag to scroll from working as well, which is unacceptable. The main thing is that the user IS able to present the ace:contextMenu and activate a menu item.