Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

hideOnClickOutside: true

edited March 2014 in Tipped
To move forward with mobile safari, I have set hideOnClickOutside to true ONLY for user agents (iPhone|iPod|iPad) to fix tips not hiding.

Now there is a second (bug) issue for hideOnClickOutside: true. The same tip won't re-fire after hiding (iPhone|iPod|iPad).


  • edited March 2014
    I guess that has to do with your elements changing classes or doing things on hover since I can't replicate it in my tests.

    iOS emulates things like class changes and hover states on mouseover/click and only registers a second click event once you first click something else to cause an emulated mouseleave event, putting the element out of its hover state. This is not something Tipped can address, it's just how iOS handles hover like states. Easiest way to handle that is by not using hover like states on touch based devices.
  • Thanks for the feedback.
  • I can reproduce this problem quite easily and made video of this problem occurring on the iPad simulator and on my iPad Air:
  • edited June 2014
    As I've explained in my previous post, iOS doesn't have mouseover/hover states since it is touch based, so it emulates these events. That's why you can get strange behavior when using elements that need to do something on click and also show something on mouseover. On a touch based device you can only tap, so the emulation in iOS itself interupts things to show you two different states, the mouseover state and the actual click the second time you tap. iOS is actually trying to do the right thing, it would otherwise never be able to show the mouseover state, but that breaks what you'd expect if you're not aware of how iOS implemented this.

    That's just how iOS handles multiple states, there's nothing Tipped can do to change it, you can work around it by not using elements that have both a click and a mouseover state.
  • Hey Nick, I understand where you are coming from, but this issue basically makes several Tipped options unusable on iOS. This pretty much means those options are not useful for anyone.

    The only solution that works well across devices we could find is to always include 'close: true' so iOS users have a way to close the tooltip.

    The disappointing thing is that Android doesn't seem to have the same problems. If Tipped could somehow emulate Android's behaviour on iOS we wouldn't have to add the (IMHO ugly) close button just because of these issues.

    I get that this might be kind of a hack, but can you take another swing at this?
  • edited December 2014
    As for hover states described above, hideOnClickOutside responds to clickable elements on iOS. You don't need a closebutton to work around that, the behavior is just different. Tooltips will close the next time you press a clickable element, that's how people expect things to work in iOS, it's how that browser works.

    Tipped can't work around this, even if there was a hack it should be avoided to not break expected browser behavior. If you think this should change you can file a bug with iOS. If they decide to be more like android that'll automatically improve things.
  • There are a couple situations where our users are unable to close tooltips.

    One page we have a form which gets covered when the tooltip is active (we could move it but, this is an example gotcha). There are no other clickable elements except for the submit button. Users have to refresh the page if they click the tooltip. Also, if users press the next field button (>) they are able to type in the form, but the tooltip still doesn't hide even though another element has gained focus.

    Another issue are pages with only content and one tooltip. The tooltip covers the content, but the user has no way of closing it.

    I don't want to push for a specific implementation, but these are real issues that should be solvable. If special-casing iOS is the solution then I'm all for it. Even if it means some terrible User Agent hack.
  • edited December 2014
    Those things are caused by iOS behavior, that's not something Tipped itself can change. If you'd like to add a close button on iOS only you can do that by sniffing out the user agent to set that option and deal with it that way.
  • edited December 2014
    One thing you could try that Apple mentions in their iOS docs is attaching an empty click handler to the body or other containing elements, so clicks register on them.

    <body onclick='void(0)'>


    $(function() {
    $('body').on('click', function() { });
  • I've added this workaround to 4.2.2, attaching an empty click handler to the body.

    It would probably work even better when attaching empty click handlers to every parent of the element that triggered the tooltip, but that could drastically change the way the page behaves, breaking things like :hover because of the way iOS handles these states.

    Tipped can't do this since it has to work everywhere, but if you know that it's safe to do so on your page you can expand the selector in my javascript example above to include more elements.
  • Hey, great!

    Can't wait to checkout the update.

    Thank you.
  • edited March 2015
    I just encountered a similar issue. For what its worth, I have been able to tie the unexpected behavior to the skin.

    1. If I use the default skin or explicitly set the skin to 'dark', then hideOnClickOutside:true correctly closes the tooltip and allows me to re-initiate it

    2. If I use a different skin, 'light' for example, then hideOnClickOutside:true correctly closes the tooltip but I am unable to re-initiate

    3. Going back to an earlier topic of needing to double tap the (x) to close the tooltip - with the default skin I have to double tap, and with 'light' I don't.

    Toggling the skin, as mundane as that would seem to be, appears to significantly affect the behavior of the tooltip and its compatibility with iOS.

    We're running v4.2.2 - I'm going to try applying v4.2.5 and hope it makes the difference.

  • :( And 4.2.5 did not have any effect...
  • I can't replicate that, switching skins doesn't affect anything in my tests.

    As for double clicking 'x', I've explained why this works the way it does here:
  • Thanks for the reply... I will continue to try to isolate the problem. And attempt to establish a test case for you to evaluate. Thanks again!!
  • The original bug is still in place (((

Sign In or Register to comment.