[Solved] QTIP in IE8 not pointing to spot it should

[scylla]

Please see attached image.

Now the fun part is the second time I hover its correct. Just the first time it points to the wrong spot and not always is it wrong the first time either.

[Craig]

Make sure you have a set width/height for the image, otherwise you'll get positioning issues.

[scylla]

Ahh. I am not doing that on the images. I will add that code.

For all browsers except IE it works find without the width/height properties set.

Is this a known problem in IE?

[Craig]

Not so mcuh a problem as it is a side effect of not supplying dimensions to images explicitly. It's recommended you do this anyway since if you don't, the image triggers a full page reflow once it's dimensions are known.

[scylla]

Thank you Craig, awseome support.

I will post a followup once I do the code changes to let you know if it fixed it for my case.

---

(21st July 16:08)scylla Wrote:  Thank you Craig, awseome support.

I will post a followup once I do the code changes to let you know if it fixed it for my case.

It is still not working, here are two screenshots. First one IE, second Firefox

IE



FF


And here is my QTIP function:

JS Code

function doQTip()
{
		// Select all elements that are to share the same tooltip
	var elems = $('img[title]')
 
	// Store our title attribute and remove it so we don't get browser tooltips showing up
	.each(function(i) {
		$.data(this, 'oldtitle', $.attr(this, 'title'));
	})
	.removeAttr('title');
 
	// Create the tooltip on a dummy div since we're sharing it between targets
	$('<div />').qtip(
	{
 
		content: ' ', // Can use any content here <img src="images/smilies/smile.gif" style="vertical-align: middle;" border="0" alt="Smile" title="Smile" />
	   	position: {
	      target: 'event', // Use the triggering element as the positioning target
	      my: 'left center',
	      at: 'right center',
	      adjust: { x:-13 },
	      viewport: $(window)         
	   	},
/*	   
	   		position: {
			target: 'event', // Use the triggering element as the positioning target
			adjust: { y:-36 },
			viewport: $(window)			
		},
*/
		show: {
			target: elems,
			solo: true
		},
		hide: {
//			when: 'mouseout',
			target: elems,
			fixed: true,
			delay: 0
		},
		style: {
			border: {
         		width: 3,
         		radius: 8
	        },
			width: 320,
			classes: 'ui-tooltip-shadow', // Optional shadow...
			tip:  {corner : true, height:24, width:12 } // 'left top' is what I had when working
//			tip:  'left top'  // is what I had when working
			/*
			 * The important part: style.widget property
 
			 * This tells qTip to apply the ui-widget classes to
			 * the main, titlebar and content elements of the qTip.
			 * Otherwise they won't be applied and ThemeRoller styles
			 * won't effect this particular tooltip.
			 */
//			widget: true // this is supposed to do our look and feel and it does not
		},		
		events: {
			show: function(event, api) {
				// Update the content of the tooltip on each show
				var target = $(event.originalEvent.target);
				api.set('content.text', target.attr('title'));
//				api.set('content.title.text', 'This is a title');
			}
		}
	});
 
}

[Craig]

Does the position update properly when you resize the browser?

[scylla]

(21st July 18:46)Craig Wrote:  Does the position update properly when you resize the browser?

The qtip popup closes when not hovering over image or popup, so I can't resize the browser..

However - After the FIRST mouseover the position is always right.

It is only the first time the image is ever seen by IE. All subsequent moveover events positioning is accurate as in the Firefox picture I provided.

[Craig]

Hmm this is happening even with the image dimensions set with width/height attributes?

[scylla]

(21st July 19:19)Craig Wrote:  Hmm this is happening even with the image dimensions set with width/height attributes?

Yes. I triple checked image properties that image and width attributes are set.

I set it in PHP before it ever gets to the browser.

---

I am not running the latest build, I am doing one from MARCH.

Could it be that?

---

I tried upgrading to lastest nightly build and now I get this:

my qtip code from 2-3 posts ago is the same, just updated .js and .css



So I don't know if latest version would fix my IE problem since the whole qtip stops working right with the latest

[Craig]

O_o that looks very odd, can you link me to a live page please?

[scylla]

(22nd July 12:33)Craig Wrote:  O_o that looks very odd, can you link me to a live page please?

I agree. It does look very odd.

Unfortunately this is a USA federal website in development for the National Library of Medicine and not available for public release yet and is thus behind 4000 firewalls.

I *think* we may have a an early release of the site up and running in a week or so.

Any suggestions on how to move forward given the firewall issues?

I'd rather not go public with the IE bug and of course with the latest nightly build it doesnt work at all.

[Craig]

Oh wow, ok well... can you check using Firebug or similar the stylesheet is included properly and then check whether the tooltip content has any weird CSS styles pplied, like float or position: absolute?

[scylla]

I am PMing you the info to login. The URL and its password protected website.

This version you will see is using the MARCH build.

[scylla]

As a note to anyone reading this thread. This bug I am having exists in IE9 as well. Just tested and confirmed same exact problem. I wish IE would just GO AWAY!

[BrendonKoz]

I searched these forums to try to find a solution to this problem in IE9. Good to know that I'll definitely need to add width/height for IE7-8 since I haven't yet tested them.

I'm grabbing my image URLs from an API so don't have the dimension information. I'll need to run them through PHP's getimagesize() to determine the proper dimensions before generating the HTML. Not too difficult - in thanks to that function.

However, in testing this bug with IE9, I also noticed that rounded corners were not being generated and the box-shadow looked crappy, as if it was DirectX generated. In fact it was. I looked up and saw that IE9 was in compatibility mode because I had errors in my HTML. IE9 was in quirks mode.

Double check your HTML and make sure it passes validation. If it does, it should work a lot better (and IE9 did not display this bug afterwards).

I know I'm bumping this rather old post, but if someone else is searching, hopefully it'll help 'em out.