input, textarea, contenteditable double tap on text doesn't select it on ios safari

[ia3andy]

When I activate fastclick, input, textarea and contenteditable double tap on text doesn't select it on ios safari. The behavior is quite weird on contenteditable, it focus and unfocus on double tap. On input and textarea, it does nothing.

If I disable fastclick, it works fine, text is selected and it's possible to copy, paste, change style...

Thanks for your help.

[ia3andy]

It would be great to have a class like "needsclick" and "needsfocus" named "nofastclick" to use on field elements.

Trying to copy native behavior on those elements could become a nightmare...

I think it's ok to have fastclick everywhere on an app but not on form fields.. Fastclick power is on navigation.

[andersdp]

Yeah. I need this functionality as well.

I'm using the Redactor wysiwyg plugin for all my textareas and because of that I have to stop using fastclick which is a shame since it provides such great value.

The best would probably be if fastclick just avoided form elements and contenteditable elements.

[GeneGenie]

I'm also suffering from this. Need to have copy and paste ability on IOS.

i've assigned needsclick and needsfocus on inputs, but it's breaking IOS popup

[skinandbones]

I was able to make text selection work better with Redactor on iOS by ignoring the touchstart events on contenteditable elements.

https://github.com/skinandbones/fastclick/commit/ad47104b15eb95b5fdf2f1c5df9415045aaf5a58

[erikhansen]

I just tested this in iOs 7.0.4 using v0.6.11 and I am having the same issue. I am not able to double-tap on a word to select it. Double-tapping it does nothing.

[erikhansen]

@skinandbones Can you issue a pull request for your skinandbones@ad47104 commit and link it to this issue?

[hzhu]

@graemeboyd's pull request fixes the issue! https://github.com/ftlabs/fastclick/pull/381 I've verified it on my app that suffers from this problem.

Is someone available to verify and merge this to master?

[RwwL]

I came across this thread after experiencing the issue with my contenteditable editor and I'm a little confused — are the needsclick and/or needsfocus classes described in the README supposed to remedy this? I've tried them in every combination and they don't seem to be doing anything for me, using 1.0.6. Are pull requests like #211 and #381 still open because they're still needed?

[donovancarthew]

One quick work around is to modify the FastClick.prototype.needsFocus function to check for div elements that have "contentEditable" set to true.

[jtara]

There are a couple of problems with Donovan's patch above:

• If not contenteditable, div will fall-through to the input case!
• you may have trouble if you use clicks on divs in other contexts (I did)

I am using this with bootstrap-expandable-input.js. So, YMMV if using your own code or some other plugin.

I tried making-up my own tag (expandableinput) but had trouble with that. The tag seems to have to be a "natural" block element. (At least for bootstrap-expandable-input)

(Even though the CSS for that plugin applies display: inline-text It seems to hinge on whether the node allows block nodes inside. That plugin puts a <div> inside of your contentEditable).

I settled on using <blockquote> which is at least somewhat semantic.

    case 'blockquote':   // Note HTML5 rules permit only alphanumeric characters in tag names - no - or _ etc.
      if (target.contentEditable) {  // Really only needed if we don't use our own unique tag
        return !target.disabled && !target.readOnly;
      } else {
        return (/\bneedsfocus\b/).test(target.className);  // really only needed if we don't use our own unique tag
      }

Note: I just realized this Issue is about DOUBLE clicks. My issue was with single tap, it just wouldn't focus without this. Note also, I am using this in a WebView environment, and use some native code to set a WebView option to allow focus to bring up the virtual keyboard.