Similar to bug 751324, every click on google reader mobile generates a buzz. I notice this in other sites as well. I suspect these sites are installing onclick handlers that capture everything, so it's their "fault" since Fennec doesn't know that most of the clicks are nops. Be that as it may, this consistently degrades my experience: I tap, get the buzz as confirmation, then wait for something to happen for a second or two before thinking "uhh, what happened to my event"? This makes Fennec feel sluggish and buggy, even though it's not Fennec's fault. Perhaps there is some other heuristic we could use? Perhaps we could be more conservative with our buzzes and only generate buzzes for touches that hit an anchor? (If a mobile site author wants a buzz when some random div is clicked, I thought we had an explicit vibrator api.) For reference, my stock browser doesn't generate any haptic feedback that I can find.

We have a few options: 1. Ignore all onclick handlers and just concentrate on the actual clickable elements 2. Ignore onclick handlers for certain elements, like body and maybe div I don't know exactly why Reader is going haptic on all taps. We should verify that it's an onclick handler and see what element it's hooked to.

This has come up a few times now, so I want drivers to think about blocking on it.

Great!

We could also fix this by using haptic feedback only for less-common gestures like long-tap (which would match other browsers and Android apps do). See bug 712772 for discussion.

Asking UX for some feedback

I agree that vibrating when clicking anything might be a bit excessive. I'd be happy with Matt's suggestion to relegate vibrations to secondary actions like long-taps.

(In reply to Ian Barlow (:ibarlow) from comment #6) > I agree that vibrating when clicking anything might be a bit excessive. I'd > be happy with Matt's suggestion to relegate vibrations to secondary actions > like long-taps. One of the original reasons to add haptic was for clicking on links. Giving the user feedback ASAP that they clickined on something, since the page navigation change might be delayed, due to network and/or rendering delays, even a few hundred milliseconds.

Personally I think we should stop haptic feedback when the element is a body or html element and see how that feels. If people still think there's too much feedback we can consider re-evaluating it.

(In reply to Kartikaya Gupta (:kats) from comment #8) > Personally I think we should stop haptic feedback when the element is a body > or html element and see how that feels. If people still think there's too > much feedback we can consider re-evaluating it. Happy to take a patch for this.

Verified fixed on: Nightly 15.0a1 (2012-05-21) Device: HTC Desire OS: Android 2.2.2 No haptic feedback when tapping in the text of a feed. Haptic feedback remains when checking the Keep unread checkbox or tapping next to go to the next feed. Leaving issue open for aurora integration.

Comment on attachment 624851 [details] [diff] [review] To make mfinkle happy [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: too much haptic feedback Testing completed (on m-c, etc.): on m-c Risk to taking this patch (and alternatives if risky): mobile only String or UUID changes made by this patch: none

Comment on attachment 624851 [details] [diff] [review] To make mfinkle happy mobile only, and who doesn't want to make mfinkle happy? approved.