Tooltips cannot be dismissed on iOS

[upngo]

Tooltips can be shown on mobile by clicking, but you cant get rid of them.

They swallow up click events too so you can't add click handlers to the body to hide them.

Same as the problem noted in #3417 #6232 - both full of exasperated users..

If this isn't going to be fixed, at least a note could be put in the docs saying don't use tooltips if you want it to work on mobile without custom code disabling them for mobile devices...

[cvrebert]

You're referring only to iOS and not Android, correct?

We could give body { cursor: pointer; } a try.

[upngo]

Yes. That would make it more intuitive for iOS users but the problem is you
can't get them to disappear after the tap on iOS

On Tuesday, 10 March 2015, Chris Rebert notifications@github.com wrote:

You're referring only to iOS and not Android, correct?

We could give body { cursor: pointer; }
https://developer.mozilla.org/en-US/docs/Web/Events/click#Safari_Mobile
a try.

—
Reply to this email directly or view it on GitHub
#16028 (comment).

[cvrebert]

Uh, no, I mean that should literally theoretically (with some minor additional changes) fix the dismissibility problem. See linked article.

[upngo]

Woops! True, that's convenient. Good find

On Tuesday, 10 March 2015, Chris Rebert notifications@github.com wrote:

Uh, no, I mean that should literally theoretically fix the dismissibility
problem. See linked article.

—
Reply to this email directly or view it on GitHub
#16028 (comment).

[fat]

@cvrebert is this a css issue?

[cvrebert]

@fat It's an iOS Safari quirk/bug: https://developer.mozilla.org/en-US/docs/Web/Events/click#Safari_Mobile

[fat]

@cvrebert i just meant more, that if we wanted to pursue a fix, woudl we just add that css snippet to the tooltip component… or did you expect the js to fix this somehow? (label wise)

[cvrebert]

@fat I guess it would need to be in the JS. Something like:

if ('ontouchstart' in document.documentElement) { // or whatever "is this a touch device?" test we want to use
  $('body').css('cursor', 'pointer');
}

[patrickhlauke]

or whatever "is this a touch device?" test we want to use

there is no bullet-proof way for this part though...and it would likely cause quirky effects on hybrid devices like touch-enabled laptops, surface, etc

[cvrebert]

I guess we'd ought to toss in some iOS Safari detection/UA-sniffing for good measure.

[kkirsche]

@cvrebert Why not just use the Touch object safari defines on mobile?

// Safari Mobile
if(window.Touch) { /* JavaScript for your touch interface */ }

[cvrebert]

@kkirsche I'm pretty sure that's not specific enough. There are browsers besides Safari that support Touch Events.

[kkirsche]

Ah, ok. Thank you for the information. I wasn't aware of that 😃

[deksden]

If JavaScript will fix this bug, it would be cool to have auto-hiding tooltips (after 2sec for ex).

[patrickhlauke]

auto-hiding would potentially cause issues for keyboard (and particularly assistive technology) users, depending on who it's implemented...

[deksden]

@patrickhlauke : problems are related with keyboard be hiding when DOM changes?

Maybe if we can preserve input focus and did not reset viewport - all will be ok?

[patrickhlauke]

I'd need to see an example implementation to give a definitive yes/no, but in principle: what happens if a user moves focus to something which then triggers a tooltip. Will they have enough time to read it before it disappears. And with assistive technologies, will AT still announce the content if it disappears suddenly. Even for sighted mouse users, will they have enough time to see the tooltip before it disappears again. etc

[beej75]

I see this is still a problem in v4 as well in iOS.

I don't know if it's worth mentioning, but whatever they're doing in this jquery plugin over here - it works in iOS. It ain't smooth (unless that's just the crappy iPhone 4S I was testing on), but at least it works:
http://swisnl.github.io/jQuery-contextMenu/demo/trigger-left-click.html

[ddalairac]

solution http://jsfiddle.net/stereotipo/suhq88b0/17/

test on iOS (ipad and iphone), android and windows

[twbs-lmvtfy]

Hi @stereotipo!

You appear to have posted a live example (http://fiddle.jshell.net/stereotipo/suhq88b0/17/show/light/), which is always a good first step. However, according to the HTML5 validator, your example has some validation errors, which might potentially be causing your issue:

• line 96, column 362 thru column 368: Stray end tag span.

You'll need to fix these errors and post a revised example before we can proceed further.
Thanks!

(Please note that this is a fully automated comment.)

[ddalairac]

solution http://jsfiddle.net/stereotipo/suhq88b0/18/
test on iOS (ipad and iphone), android and windows

[twbs-lmvtfy]

Hi @stereotipo!

You appear to have posted a live example (http://fiddle.jshell.net/stereotipo/suhq88b0/18/show/light/), which is always a good first step. However, according to Bootlint, your example has some Bootstrap usage errors, which might potentially be causing your issue:

• line 94, column 3: W013: Bootstrap version might be outdated. Latest version is at least 3.3.5 ; saw what appears to be usage of Bootstrap 3.1.1

You'll need to fix these errors and post a revised example before we can proceed further.
Thanks!

(Please note that this is a fully automated comment.)

[fat]

oh yeah… i think the best solution imho for ios is using an invisible screen… surprised i didn't already do that in v4

[alekseyg]

I recently had this issue and resolved it by using touch events and ignoring mouse events that come immediately after said touch events. I used Bootstrap's trigger: 'manual' option when initializing to avoid hacks. This solution uses hover on desktop, but can be expanded to work with click, focus, etc. There are a few issues with the solution: 1) on some Android devices, the touch events tend to fire unreliably, and 2) on Opera Mini, you can still touch through the tooltip, which is undesirable, but would require a 360ms delay when closing the tooltip to work around. On Android, 10ms was sufficient.

Here is a gist with the solution. Let me know if this is something that could be adapted as an official solution, if there are any major flaws with it, and/or if there's really a much better way of doing things already brewing. I'd like to be able to help with resolving this issue and would definitely like to improve what I have as well.

[rrfranco92]

@alekseyg I confirm your solution is working today at version alpha 5.

Just used it in order to fix this issue and got it working.

[bashhack]

@alekseyg - just chiming in to second that confirmation of success with the solution - thank you!

[stelco]

this worked for me...

$('[data-toggle="popover"]').popover(); // close on body click // iOS doesnt recognise 'body' click so using :not $(':not(#anything)').on('click', function (e) { $('[data-toggle="popover"]').each(function () { if (!$(this).is(e.target) && $(this).has(e.target).length === 0 && $('.popover').has(e.target).length === 0) { $(this).popover('hide'); } }); });

[stevenbriscoeca]

oh yeah… i think the best solution imho for ios is using an invisible screen… surprised i didn't already do that in v4

@fat do you still plan on adding the invisible screen in v4? I just checked it doesn't seem to been added. Are you in a "let's wait and seewhat IOS does before I put time implementing this" stance ?

Thank you

[stevenbriscoeca]

Actually probably the reason why the invisible screen was never implemented is probably because this doesn't make sens if you have a clickable element in the page, you will need to click twice to focus into an input...I guess it's going to be a waiting game on IOS at this point =/

[bkdotcom]

probably the reason why the invisible screen was never implemented is probably because this doesn't make sens if you have a clickable element in the page, you will need to click twice to focus

counter-intuitive, but would
pointer-events: none;
on the screen solve the problem?

[jlavoie13]

@alekseyg Is there a way to update your code so it doesn't close on scroll?

[alekseyg]

@jlavoie13 I've run into several tiny issues with this approach and have been working on improving it. I'll update the gist soon with some improvements.

[patrickhlauke]

see the contortions one has to go through for iOS here #22426

i'd really like to avoid having an invisible backdrop, as that just causes new problems (on touch-enabled devices with additional inputs, like touchscreen laptops/tablets with paired mouse).

i really wish iOS followed what Android and co do, which is to NOT have weird quirks relating to event bubbling/delegation...

[alekseyg]

@jlavoie13 I've updated my gist. Here's a summary of what I changed:

• The wasTouchedRecently function used event timestamps to calculate when a touch happened. Unfortunately, different browsers use different timestamps, so it was unreliable when comparing to the current time. I replaced it with a data attribute and a timeout for better reliability.
• I added e.preventDefault() on touchend of the element with the tooltip and on the body if a tooltip is shown to prevent tap-through actions from taking place when showing or hiding a tooltip. This also allowed me to get rid of the delay when hiding the tooltip.
• I added a wasTapped check on the body in order to differentiate between taps and other gestures, like when toggling the tooltip. This should prevent scrolling from hiding the tooltip.
• I replaced the e.stopPropagation on touchend of the element with the tooltip with a check in the body's touchend event for the current target. This allows one tooltip to dismiss another if you have multiple tooltips on one page.

[patrickhlauke]

not tested this yet, but as a note: adding a touchstart to the body indiscriminately will lead to bad scroll performance (since the browser can then only scroll sync rather than async, and can't thread), unless using passive event listeners (which removes the problem, but only in modern supporting browsers)

[patrickhlauke]

#22481 ports the same hack i used for dropdowns to tooltips. while hacky, it's relatively small and has no known side-effects - all it does is coax iOS into doing event delegation/bubbling like all other touch-enabled browsers (grumble grumble)

[PlPadraig]

@gregblass I checked out https://github.com/sandywalker/webui-popover and it worked for me as well right out of the box! Thanks! That saved me a lot of time in resolving this problem in my application.

[turigeza]

I ended up with this so far so good ...
@supports (-webkit-overflow-scrolling: touch) { /* CSS specific to iOS devices */ body{ cursor:pointer; } }

credit to:
https://stackoverflow.com/questions/30102792/css-media-query-target-only-ios-devices

[Joyrex]

While @turigeza solution works so tooltips are dismissible, this is only for iOS Safari, and in cases where a button invokes a modal or similar, the tooltip remains until you tap elsewhere.

I really think a solution that targets touch-enabled devices (not just iOS Safari) that auto-dismisses a tooltip after [x] seconds would be the best, and with Bootstrap 4 being mobile-first, I think should be part of the framework.

[patrickhlauke]

so let's be clear...is there still a current issue even after fixes etc? if so, please file a fresh issue with a reduced test case

[chrisbo]

I agree with Joyrex. I have just removed every single tooltip from a site because I noticed in iOS they stack and won't go away.

[Joyrex]

@patrickhlauke - well, yes - there really never was an adequate “fix” to begin with, for the reasons I pointed out.

[patrickhlauke]

and again, i'll ask you to post a reduced test case to show the issue, and post a fresh issue. the workaround implemented at the time covered the common scenario of tooltips like http://getbootstrap.com/docs/4.1/components/tooltips/#examples and they work fine on iOS. if there's further situations that currently fail...post a new issue instead of adding to a closed thread started in 2015

[BonBonSlick]

On iOS after click tooltip does not disappear BS 3.

[kiler129]

@turigeza: FYI, this no longer works :(

[Johann-S]

If you have an issue please create a new one with a live test on a CodePen thanks