User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: Using the attached test files, touch a checkbox. I'm using a Galaxy Nexus phone / Android 4.2.2. Actual results: Checkboxes usually don't toggle state. I believe the nearby elements are being acted upon instead of the checkboxes. It works better if I zoom in but I don't want to do that over and over. Expected results: The checkboxes should work more reliably regardless of the zoom level. The problem only happens when I include the attached javascript code which has onclick events. I should mention that I adapted the js code from a website. Its purpose is to allow collapsible outlines. If you touch a checkbox in a non-leaf part of the outline, that part of the outline will usually collapse or expand instead of the desired toggling of the checkbox. It all works fine in Google Chrome for Android but I'd prefer to use Firefox as my default browser.

Would you retest in a day with a March 1st or newer nightly. bug 973348 should be fixed in there. It may impact this bug.

Unfortunately the patch in bug 973348 doesn't fix it. "about:firefox" says I'm using 30.0a1 dated 2014-03-02.

We recently (in bug 788073 and dependencies) changed the code that finds the clickable element under the tap. Can you check on the latest Firefox 35 build to see if you can still reproduce the problem? I tried and was not able to. Firefox 35 is currently on the aurora channel which you can find at https://www.mozilla.org/en-US/firefox/channel/#aurora (or if you want to wait a bit it'll be pushed to the beta channel sometime next week).

It still doesn't work most of the time. I tested against FF Aurora 35.0a2 (2014-11-26). Honestly I no longer need to use the outlines in a web browser so it's fine with me if you close this bug.

Ah, I can reproduce this if I put in the images and stuff properly. I didn't do that the first time. Updating bug URL to the complete web page which reproduces the problem.

So what's going on here is that the <li> has a click listener, so it becomes "clickable". Unless you click directly on the checkbox, you're most likely going to end up clicking on the <li> element (which is much larger) and because it's "clickable" that's where we send the click. In this case we don't even bother searching for nearby clickable elements since the tap lands directly on something that's already clickable. I can't think of anything we can do here that will improve this case without breaking other cases. Given Pete's comment 8 and my investigation I'm going to close this as WONTFIX. If anybody has suggestions on how to deal with this better we can reopen this bug and consider them.