Tooltip positioning does not take into account viewable area #296

bsweeney opened this Issue Jan 21, 2011 · 7 comments


None yet

3 participants


When a tooltip position is determined it is not with respect to the dimensions of the browser window. This results in two different issues:

  1. The tooltip can be positioned such that it displays off the left edge of the screen. Test case: create a tooltip with the option {position : "bottom center"} on an object that is rendered on the left side of the screen.
  2. The tooltip width can get smaller each time it is displayed. Test case: create a tooltip with no defined width and the option {position : "bottom center"} on an object that is rendered on the right side of the screen.

Desired resolution: a configurable option that indicates to the script to place the tooltip within the viewable area.

The following diff will address the cited issues by making the following changes:

  1. modifies the tooltip object's show function to record the tip width on instantiation
  2. modifes getPosition() to check the left position against the browser window and adjust it if necessary

This diff isn't a full solution, it only addresses the issues I cited above. But hopefully it will get you started. Here's the diff:

@@ -105,6 +105,8 @@
        var width = tip.outerWidth() + trigger.outerWidth();
        if (pos == 'center')    { left -= width / 2; }
        if (pos == 'left')      { left -= width; }
+       if (left < 0) { left = 0; }
+       if (left+tip.width() > $(window).width()) { left = $(window).width() - tip.width(); }

        return {top: top, left: left};
@@ -194,8 +196,10 @@

                    if (!tip.length) { throw "Cannot find tooltip for " + trigger;  }
+         'width',tip.width());
+               tip.width('width'));
                if (self.isShown()) { return self; }  

                // stop previous animation

Hi bsweeney,

I'm working on collecting bugs and fixes for 1.2.6 - any chance you could please submit this as a pull request, if you have not already done so?

bsweeney commented Sep 8, 2011

I'll see what I can do. I'm not too familiar with using git, so it may take me a few days to work out the process.

bsweeney commented Oct 7, 2011

So I finally had a chance to sit down and take a look at this again. So far as I can tell the issue is no longer a problem. Perhaps what I experienced was due to the web browser I was testing on at the time because I have been unable to reproduce the problem.

Additionally, in taking a second look at the documentation I would be inclined to use the dynamic positioning plug-in to avoid issues like this in the future. This wouldn't address the problem (if it still exists), but does provide a decent work-around. I recommend closing this issue unless someone can substantiate the issue.

bsweeney commented Oct 7, 2011

O.K. so I don't like to let things go unresolved like that. I managed to load up some "older" browsers (Firefox 3.6 and IE 8) for testing. The problem persists in these browsers. The fix outlined above is fairly simple so I'll go ahead and make the modifications and submit a pull request.

I did not develop a comprehensive sample of test cases so I can't say if any conflicts are introduced. I did look at the sample files and the tooltip placement appeared to be correct except in the case of nested, positioned elements. The placement of tooltips on positioned elements appears to be constrained somewhat by the available dimensions of the containing element (though more testing is needed).


Hi bsweeney,

From reading your posts in more detail - I'm curious about a comment of yours in your last but one post - I'm intrigued as to why you think using the dynamic plugin does not "address the problem, but provides a decent workaround"? As far as I am aware, the reason for the dynamic plugin was to allow for this? Furthermore, whilst I can understand this may exist in IE8, is there a reason you are still using Firefox 3.6, given that the latest version is now version 7?

To me, if a browser window is resized, then yes, you will always have this inherent issue; it is possible that the dynamic plugin would include the functionality that tooltip would otherwise need, but in an additional file, and not as part of the default tooltip? I'm guessing that Tero probably felt that not everyone would want to include the functionality for dynamic plugin as default, as people may not want it present for some reason? This way, it means people can activate it if they need it, at minimal overhead to the rest of the script they are using?


Regarding tooltip placement, you make a valid point. However:

  1. Viewed as a UI object it's a bit of a design failure to have an interface element intended to present information display off the screen.
  2. The behavior is inconsistent across browsers.

It's more the latter point that leads me to believe this is a bug. You could be correct that it was an intentional decision to make dynamic positioning an extra (a moving tooltip could break the intended design of the site), but let's disregard that. The problem I was having is that there was room to render the tooltip, it was just being rendered too wide. I was expecting at least some minimal amount of calculation to account for the available space. And this is how it works in the latest Firefox.

Tooltip placement was only part of the issue. The other being the tooltip width shrinking on successive displays. This behavior seems to me to be a bug. A browser bug, perhaps (it does work as expected in FF7 & IE9). But working around browser inconsistencies is one of the benefits of libraries, right?

I, myself, do not use Firefox 3.6. That just happens to be the browser I was using at the time I ran into the issue. So I went in search of a copy to confirm that the issue was valid. The browser I am using, however, is not as important as the browser in use by visitors to the sites I maintain. I still have a not-insignificant number of visitors using the cited browsers versions (40%-50%).

duclet commented Mar 18, 2012

Please submit pull request with fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment