Buttons seem to have problems in Chrome on Android 4.1 about fastclick

[mattcg]

Thanks for reporting. What device/OS/browser are you using? Could you attach the source for your test page here please?

[Pointy]

I'm using a Nexus 7 tablet with Chrome. I'll work on a test page; I realize it's lame to submit a bug without one :-)

[mattcg]

Ah, just saw the title, sorry!

[mattcg]

@Pointy I was unable to replicate this in Chrome on Android 4. I've added a test case in tests/6.html. Does it look anything like your use case?

[tillre]

Same Problem here with a Nexus 7. Tried the test: input works, button not.

EDIT: The Problem is, that chrome on Nexus 7 is not recognized as chromeAndroid by the user agent regex. Then window.devicePixelRatio is not taken into account and the wrong element is found by eleAtWindowPosition(x, y).

navigator.userAgent
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.45 Safari/535.19"

EDIT: Seems like i had the "Request desktop site" checkbox ticked in chrome. Chrome than tries to seem like a Desktop browser. With the checkbox off the useragent is:
"Mozilla/5.0 (Linux; Android 4.1.1; Nexus 7 Build/JRO03D) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Safari/535.19"
And it works fine.

[Pointy]

I've added some console.logs to the code so that I can see what's going on via weinre. What I'm seeing is that the "eleAtWindowPosition()" code is returning the wrong thing; it may be because (on my page at least) there's a slight zoom when I focus on a textarea (or plain text input for that matter) and the keyboard comes up.

According to my tracing, in the touch end handler when I try to click on a button, the event target is indeed the button, but the call to eleAtWindowPosition returns a different (nearby) element.

If I change the way that the code sets "targetElement" variable so that it first checks event.target, things work better (though I realize that may be disastrous in other environments).

For example, in a particular test, I focus in the textarea and then touch the button. The "touch end" handler debug code reports the event target element to be the button, but the "targetElement" variable is set to a different element. The screen coordinates of the touch end were (477, 666), but the computed target element has a scroll-adjusted footprint of (82, 634) to (517, 651) - an area that does not include the touch start coordinates.

(I think maybe Chrome on Android 4.1 might not need the devicePixelRatio adjustment.)

[mattcg]

Could you submit a pull request with your test case please? (Put it in /tests.)

[Pointy]

I will try to come up with a JSBin or something; it's been a little tricky to do so far.

I'm not sure what you'd want in a test; I'm just watching "console.log()" output in weinre.

[mattcg]

All I'm looking for is that the bug is reproducible in the test case you provide.

[Pointy]

Here's a JSBin that (I think) illustrates the problem.

http://jsbin.com/apoboy/2

The page works fine on my desktop browsers (of course) and on my iPad and my HTC One (4.0.3) phone, but not on my Nexus 7 (4.1). (Clicking the "Hello World" button should show a "click" count message above the textarea.)

I'm not sure that the problem has anything at all to do with being focused in a text box; that was an early hypothesis but now I'm pretty sure it's a red herring.

That test uses a slightly old version of FastClick that I've patched for the textarea problem; you can of course fiddle with it to use your own version of the library.

[samgiles]

Edited with Fastclick lib from master for reference: (I've not tested)

http://jsbin.com/apoboy/3/edit

[mattcg]

I've managed to replicate this in Chrome on a Nexus 7. It looks like the issue is caused by the browser zooming the page in.

[mattcg]

It seems that on Chrome for Android (4.1 on a Nexus 7 at least) the only coordinates that work with elementFromPoint when zoomed in are screenX and screenY. The only way to detect whether the browser is zoomed in seems to be using (window.outerWidth - window.innerWidth) > 1. And window.pageXOffset, window.scrollX, window.pageYOffset and window.scrollY are being set to non-zero values even if the page isn't technically scrolled.