hammer.js prevents contenteditable div from getting focus

[ronancremin]

I have document something like this:

<div id="wrapper">
    <div contenteditable="true" id="1">Item 1</div>
    <div contenteditable="true" id="2">Item 2</div>
</div>

with hammer.js configured as follows:

var hammer = new Hammer(document.getElementById('wrapper'), {
    drag: false,
    drag_vertical: false,
    drag_horizontal: false,
    transform: false,
    transformend: false,
    swipe: false,
    tap: false,
    tap_double: true,
    hold: false
});

hammer.ondoubletap = function(ev) {
    $('#1').focus();
}

The problem is that as long has I have Hammer bound to the wrapper div, I can't get the focus to any of the contained divs, programatically or otherwise, in order to edit its contents (the element highlights but the cursor doesn't show up). If I remove Hammer, or focus it just on a particular div rather than the wrapper, I can use .focus() as expected. I'm using Chrome on OS X and Android.

Is this a known problem with Hammer?

Is there a nice way to disable it temporarily?

Thanks, Ronan

[sudo-ben]

Any quick fixes for the issue?

[DemonWarlord]

I had the same problem, and i fixed that by add css_hacks: false when creating new hammer.

Some thing like this:

var container = $('#container').hammer({
                                               prevent_default: true,
                                               scale_treshold: 0,
                                               drag_min_distance: 0,
                                               css_hacks:false
                                               });

[denoww]

Thanks very much, i disable css_hacks and now it's ok

[ronancremin]

DemonWarlord, thanks so much for the fix, really appreciate it.

[re1man]

Hello, this issue seems to have not been fully resolved. When I comment all code in the method stopDefaultBrowserBehavior, contenteditables and basic functionality is still present. I looked into it, and it seems that css_props.userSelect is the culprit.

[jtangelder]

in the new hammer you can change the properties, maybe you should give it a try :-)

[pyramation]

yea I was able to use this for the same issue

        stop_browser_behavior: {
            userselect: false
        }

but honestly seems that some of these properties should only be modified if those events are actually detected. For example, if you want to handle a swipeleft event, a click/hover over a contenteditable is still captured by these stop_browser_behavior options, which is a issue/bug IMHO.

In other words, hammer should only modify what the browser's behavior is on the specified events, not on events unrelated, which some of these css properties affect.

[jtangelder]

It's a kind of chicken/egg situation, those properties help detecting events, without, some gestures/events aren't detectable... maybe is could be explained on the wiki what properties are needed per gesture, so you can disable it safely.

[thevinci]

Is there a way to disable the user select for specific elements (eg: $('[contenteditable]'))?

[GittiHab]

stop_browser_behavior changed to behavior. And use it like this

hammerObj.hammer({ behavior: { userselect: false } }); See this Issue/Comment