autocomplete: suggestion box not closing on blur

[reppners]

Reopening #7419 as suggested by @EladBezalel

Actual Behavior:
Inputs are not blurred when tapping outside of a focussed input element.

The autocomplete suggestion box is not closing when the user taps outside the autocomplete to close the suggestion box without selecting a value.

This only happens on touch devices. Tested on Android/Chrome 52.0.2743.98 and iPhone/Safari 9.

When using the "Done" on iOS keyboard the suggestion box closes.
Hiding the keyboard on Android did not close the suggestion box.

Expected Behavior:
The autocomplete suggestion box should close when the user blurs the control by clicking/touching outside of it.

Additional Info

According to the comments in #7419 it worked in 0.11.4.

The issue might origin from function mouseInputHijacker and a quick-and-dirty fix for the autocomplete may be applying a css rule:

.md-scroll-mask {
  display: none;
}

[devversion]

Related to the planned gesture improvements - #9362

In meanwhile, disabling the click hijack fixes that issue

$mdGestureProvider.skipClickHijack();

[reppners]

@devversion Has $mdGestureProvider.skipClickHijack(); any negative side-effects?

[devversion]

Quote from the source

If hijack clicks is true, we preventDefault any click that wasn't sent by ngMaterial. This is because on older Android & iOS, a false, or 'ghost' click event will be sent ~400ms after a touchend event happens.

The only way to know if this click is real is to prevent any normal click events, and add a flag to events sent by material so we know not to prevent those.

Two exceptions to click events that should be prevented are:

• click events sent by the keyboard (eg form submit)
• events that originate from an Ionic app

Basically the Fastclick solution wouldn't be available for older devices anymore.

A very good article about the ghost clicks (and Fastclick)

• http://ariatemplates.com/blog/2014/05/ghost-clicks-in-mobile-browsers/

[clshortfuse]

Possible dupe of #8996

[devversion]

@clshortfuse Yeah those are kind of the same, but I personally prefer this one, because it includes more information e.g a workaround and why it's happening (also is about the input)

We can close on of both :)

[clshortfuse]

@devversion Yep, I'm tagging gestures to things that will have to be revisited after/with HammerJS.

[clshortfuse]

@devversion I think we can more accurately target devices so click hijacking isn't done on newer devices. It's mix of reading the user agent, browser version and viewport scaling. I have to write it anyway for an app I'm writing. Of this top of my head, Safari Mobile pre-July 2016 need it and Android pre-2013/2014. I can get the exact version numbers later.

[devversion]

@clshortfuse There is no need for Click hijacking with HammerJS anymore. We should just wait for this and not make any big changes to $mdGesture's yet.