On the site I'm working on, there is a series of links. Most of the links are using fbTooltip to display a tooltip with additional information related to the thing being linked. Some of these things only have a little bit of additional information, and thus, a short (in terms of vertical pixels) tooltip (I set maxContentWidth:700). But some of them have lots of additional information, resulting in tall tooltips. This is working great everywhere except for in Firefox. In FF, some of the tooltips are "blinking" - they are visible for a fraction of a second, then they disappear for a fraction of a second, then they reappear, then they disappear, etc. As far as I can tell, this is only happening on the ones with tall tooltips. And, as far as I can tell, it seems to be that Firefox is getting confused by hovering or not. I mean, something like the following is happening (in my best guess):

1. You hover your mouse over the link.
2. The tooltip appears. Because it is so tall, it can't _just_ be placed above or below the link; its placement is adjusted and part of the tooltip appears directly on top of the link, where your mouse happens to be.
3. Firefox sees that you are now hovering over something other than the link (i.e. the tooltip itself), so it hides the tooltip.
4. Now, with the tooltip gone, you're once again hovering over the link itself, so Firefox sees that and brings the tooltip back.
5. Repeat ad infinitum.

Have you seen this problem before? Is there a suggested workaround or fix for it? FWIW, maxContentWidth is currently the _only_ option I'm setting. My links look like this (complete with Django variables):

<a class="fbTooltip" data-fb-tooltip="source:#{{ doc.title|striptags|truncatewords:4|slugify }} maxContentWidth:700" onclick="fb.end(this);return:false;" href="{{ doc.url }}">{{ doc.title|title|striptags|escape }}</a>

The actual project I'm working on is not yet accessible to the public, so hopefully my description here will be good enough for someone to sort it out and make a recommendation for me. But if not, let me know and I'll see if I can put together a simple demo page illustrating the problem.

Even if this is related to Firefox getting confused about the hover state, I need to be able to mouse over the tooltips, anyway (because they contain links). And actually, I can, on all the ones that are displaying properly.

I have seen that behaviour before, but was unable to build a consistent test case for it with which I could track down the details. I think your description of what's happening is likely to be right on the money.

Can you please do us both a favour and set attachToHost:true for those jittery tooltips. When 'attached' to the host element, the tooltip remains open when moused-over. I think there's a reasonable chance this will settle your tooltips down, and I'd really like to hear if it does or not.

Cheers...

Thanks for the response! I set attachToHost:true on my tooltips, but I'm still getting the same behavior.

OK, I'm going go and try to put together a consistent test case. I might get that up today, or I might not finish until Monday. I'll post a link here when it's ready.

I too am taking the weekend off, so won't be looking at this with any seriousness until Monday. Based on your description, I should be able to assemble my own test case so you probably don't need to spend time on that. If I can't replicate it I'll ask for your help.

I'm pretty sure this will require a new Floatbox release to fix. In the meantime, I think your only options are to use smaller tooltips that will fit the available space or consider using context boxes instead. The context boxes open on click or touch, not mouseover or touch, and so may not be appropriate for your usage.

Note that if a tooltip cannot fit on one side of the host element, it will first try the other side before sliding towards the screen center to get itself visible (top/bottom or left/right). A tooltip that is a little bit less than half the browser viewport size should be ok.

I went ahead and built a test page here:

http://kage23.com/floatbox-test.html

I'll think about content boxes, but I'm pretty sure they won't work; I think we need mouseover in this usage, not click or touch.

I might be able to truncate some of the content of the tooltips and limit the height of the tooltip that way. Or possibly I can set maxContentHeight ... I'm not sure if that's desirable, though, because I don't know if we want to have a scrollbar in the tooltip or not. I'll have to check in with my project manager on Monday.

In the meantime, thanks for looking into it!

Thanks. Yup, it's blinky, but only in Firefox. It will be interesting to figure out why.

Another option for you would be to open a standard floatbox using the fb.start() function on mouseover. Use the appearance options to make it look the way you want, put an outerClose button on it, and have folks click on that (or click on the box content, or press 'esc') to dismiss the tooltip replacement. I've added this as link #6 to your test page and posted it at http://floatboxjs.com/misc/tt. View-source to see how it's setup. Note that I've put it on a timer that is cancelled on mouseout to prevent the box from opening on just a quick mouse-transit.

Not related, but worth mentioning...
I moved the floatbox.js script up into the doc head. This is so the fb.start function will be present before the element that uses it is drawn. The particulars of this case notwithstanding, for code such as Floatbox that adds event handlers to DOM elements, I think it's best practice to load the code early in the head and not at the bottom of the body. This reduces the time between the element draw and the event handler being present -- the window of time where a user could quickly click on a floatboxed link at page load time and navigate to the content rather than show it in a floatbox. Moving the js to the head changes the load sequence from render-load-activate, to load-render-activate.