Some people (me) find the vibrate on every single click to be quite a nuisance. There needs to be a way to disable this (or perhaps remove it, as, AFAIK, no other browser does this). (see also "Support vibrate on long-press")

Aaron/Tony can we have your input on this bug?

This is a UX or Engineering decision. UX if they want to add a button to control this (doubtful). Engineering if they are willing to add an about:config pref.

FYI, this should be (currently) controlled by a system wide Android setting. For me its under Settings->Sound->Haptic Feedback.

(In reply to Wesley Johnston (:wesj) from comment #3) > FYI, this should be (currently) controlled by a system wide Android setting. > For me its under Settings->Sound->Haptic Feedback. I agree. I don't want to create too many layers of options here. The system option should be enough, right?

The intent of this bug appears to have been missed- It is quite annoying and unnecessary to vibrate on every user action. No other browser i am aware of does this. On the other hand, it is very useful to have it vibrate on a long-press, as an indication that the screen was touched long enough. See, e.g., the stock browser and most others. The problem of over-using the vibrate effect will be more clear when vibrate on long-press is implemented- it'll be hard to tell the two indications apart. The Android system setting applies to all apps- to get the desired functionality, i would have to disable vibrate globally when using Firefox, then re-enable it when opening the keyboard and leaving, and still wouldn't address keeping the long-press vibrate enabled. Ideally, this would simply be removed or at least turned off by default.

We should only be vibrating on clicking on a link. There is an open bug on vibrating on each touch after clicking a link and pressing back.

We honor the system vibration settings in settings > sound > vibrate on touch.

How do i achieve the desired behavior (compare with vibrate implementation in stock browser) then?

For me, stock only vibrates on long tap? Haptic feedback on single tap is here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#2301 so you'd remove that, and to add it on long tap, you'd need to add a call here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1332 (that code looks like we should be passing Haptic.ShortPress in one case and Haptic.LongPress in the other. Although in my testing, the difference is pretty slight)

This bug is not invalid; there's definitely an actionable request to vibrate on long-tap only. At the very least, it would be easy to make this a hidden pref. In fact, I'd argue along with CoJaBo that the default should be to vibrate only on special gestures like long-tap and *not* for regular clicks. That would be more standard Android platform behavior, and it would match XUL Fennec and other Android browsers. Let's ask UX what the default behavior should be. See bug 708379 for previous discussion.

Soft blocker nom?

Nominating for tracking as I'm seeing this come up on SUMO and Google Play reviews

This issue hasn't been fixed yet. It's a simple matter to give us an option to disable the haptic feedback within firefox. Telling us to use the system settings to disable haptic feedback completely is unacceptable, because the haptic feedback is useful elsewhere. Please fix soon.

I'm professional UX Designer. In general, when a decision is made to do something that goes against the behavior of other software or the default software (such as in this case), the benefits of the decision need to either be backed up user research that is accessible by the community, or an option to disable it should be present. People will always resist a change. The first course of action allows people to see why the new version is better and the bandwagon effect will usually sway most of them. The second option fixes the problem entirely. In this case, as a UX professional, I believe the option to choose is the better course of action. Not just because I'm skeptical that any real UX research was done, but because it is parasitic to the overall phone settings. Installed software should conform, or at least have the option to, conform to the default software affected by system settings. I see above that attempts have been made to honor the system settings. However, explicitly, until the software can be made to behave exactly like the default browser, it is parasitic.

I think a better approach here would be to first make our haptics less laggy. Part of what can make the experience of tapping a link irritating right now is that the feedback comes a noticeable amount of time *after* the tap. If the vibrate happened when you tap, it would feel like a more designed experience, and probably a lot more responsive. Once that is fixed, if people are still troubled by vibrations every time a link is pressed, we can look at an option to fine tune when and when not to trigger a vibration.

Ian, you're missing the point. Not one person here has complained about the haptic being laggy. They've been complaining about their very existence. The response to "we don't want the haptics" isn't "Oh, you must mean you don't like the laggyness, so we'll make it less laggy". The appropriate response is "Oh, sorry. Here's a button to turn them off".

Relating to my previous comment about providing user research or an option to disable, the above comment makes little sense to me. The clear best answer is to provide an option to disable the unwanted vibration. That will make users happy, the designers and developers notwithstanding, which is most important. Once the fix for best UX is in place, *then* fix the haptic feedback and release it as a patch. (still providing either user research or an option to disable) Without user research or an option to disable, it is simple forcing an (often unsubstantiated) opinion on a user base. UX exists as a discipline to prevent this kind of thinking and behavior. Forcing unhappy users to suffer while attempting to optimize laggy feedback, which will highly likely be widely variable on different devices, is not best practices. Especially when a clear solution (and an established standard) is present that is requested by the user base. Please understand that Android devices all vibrate differently. Samsung devices vibrate rather gently, akin to the iPhone whereas Motorola devices vibrate like a sex toy. People with Motorola devices will likely never want the vibrate on every press.

It actually is not an unsubstantiated opinion that our haptics need to be improved. I've heard on many occasion that it makes our browser feel slower, and out of sync with what is happening on screen. That kind of dissonant behaviour can often magnify a sense that something is out of place, when if it were working in concert with a user's actions it would feel much better. Having said that, I didn't say no to a switch either. I just don't want us to start using switches to turn features on and off that haven't been fully exectuted yet, and as such don't represent the intended experience as well as they could.

I dunno about that, JT, my gnex is pretty adamant when it vibrates. Ian, the only thing preventing me from using and promoting firefox, and even giving it 5 stars on market is the fact that you're forcing the haptics down our collective throats. If you gave us the ability to turn the on-every-godforsaken-click feedback off, firefox would be pretty much ideal. It's that link vibrate that makes it infuriating to use.

"I just don't want us to start using switches to turn features on and off that haven't been fully exectuted yet, and as such don't represent the intended experience as well as they could." While this is valid sentiment, best UX practices dictate that in many cases, pulling a feature is better than having a buggy feature. Were I project manager, I would release a hotfix right now removing this functionality entirely until it's fixed. This way, when it works properly and is rolled it out, less people would be exposed to the faulty behavior.

As a short-term measure, if we add a hidden pref then at least it would be possible for users to change the behavior by flipping the pref in about:config or by installing a simple add-on.

(In reply to Matt Brubeck (:mbrubeck) from comment #21) > As a short-term measure, if we add a hidden pref then at least it would be > possible for users to change the behavior by flipping the pref in > about:config or by installing a simple add-on. Works for me.

Now we're on the right track. Pull it until it's fixed. Release it with, check box in the settings (is it REALLY that difficult to add a check box toggle?) and then EVERYONE is happy, because people who want haptic get haptic, and people who don't want haptic can turn it off. Additionally, the toggle will allow this of us against the haptic to try it as it's intended to function (and possibly be swayed to your point of view)

We originally added haptic as a feedback for tapping links in webpages. We now also use it when tapping any widget (button, textboxes, checkboxes, etc). We might want to re-evaluate that. What I'd like to see: * Look at rolling back to just haptic on links * Add a pref to disable haptic when tapping in content (it will be enabled by default)

Why is this not fixed yet? There have been several updates to firefox since this bug was reopened

(In reply to Chris Roller from comment #26) > Why is this not fixed yet? There have been several updates to firefox since > this bug was reopened There is currently no assignee nor any patch attached to this bug.

I spend a great deal of time in courtrooms where the constant haptic feedback is very audible due to the otherwise quiet environment. The feedback is also disturbing when I'm browsing in bed while my wife is trying to get to sleep.

Agree with jcurrie. For new, the solution to this is simple: switch back to Dolphin, where the user experience is less intrusive to my surrounding environment. I'd be willing to overlook the fact that I can't read what I'm writing right now because the browser doesn't automatically zoom in on text fields or its lack of a home screen for my common links or even the difficulty of navigating text fields without a cursor, but the fact that it makes my phone noisy even while it's on silent is a dealbreaker. This is not how haptic feedback was designed to be used; it makes the browser feel awkward, broken, and backwards. I'll come back in a few more months to see if it's fixed, but for note I'm uninstalling.

+1 for removing vibration on every tap. This is also not standard Android behavior. It is really disturbing an annoying. Vibration on long tab is fine! Please fix/change this soon.

This patch removes the haptic on every "clickable" tap. * Removes a single use local var (isClickable) * Removes needlessly re-checking for clickable after we move click point * Removes the actual "if clickable, do haptic" code * Un-linewraps some nearby code

When does this patch become active on Google play?

Comment on attachment 672667 [details] [diff] [review] patch Review of attachment 672667 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me. This will ship in FF19 (~4.5 months). If you want to test now, you can test nightly builds from nightly.mozilla.org (you'll have to enable installs from 3rd party sources in Android settings).

(Note: This change hasn't been checked in yet, so it won't appear in nightly builds until a few days from now.)

Comment on attachment 672667 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: high feedback Testing completed (on m-c, etc.): none yet Risk to taking this patch (and alternatives if risky): low to medium. let's let it bake a few days String or UUID changes made by this patch: none

(In reply to Mark Finkle (:mfinkle) from comment #36) > Risk to taking this patch (and alternatives if risky): low to medium. let's > let it bake a few days We think the risk is manageable, so we'll approve once this has bake time.

Comment on attachment 672667 [details] [diff] [review] patch Approving for Aurora as it has had some bake time now. Adding qawanted,verifyme on this to get this verfied as its a low-medium risk.

This issue is fixed on the latest Nightly and Aurora build. Haptic feedback can be felt just for long taps. Simple taps on links are performed without any vibrations. Closing bug as verified fixed on: Firefox 19.0a1 (2012-10-29) Firefox 18.0a2 (2012-10-29) Device: Galaxy R OS: Android 2.3.4