[Solved] iPad: qTip position is incorrect, offset by scroll

[kiddailey]

Craig:

Saw your twitter note about iPad compliance. Looks like you haven't had a chance to respond to my reply saying that I had one and would love to help you test, so thought I'd just start posting the bugs for you. Let me know if you'd prefer these done somewhere else, or in a different way.

In some cases, the qTip's position is offset by the scroll amount, making it disconnected from the trigger. For example, with the following init:

JS Code

$('.selector').qtip({
	content: {
		text: $(this).html()
	},
	style: {
		tip: {
			corner: true,
			width: 20,
			height: 10,
			border: 0
		}
	},
	position: {
		my: "top center",
		at: "bottom center",
		adjust: {
			y: 5,
			x: 250
		}
	},
	show: {
		event: 'click'
	},
	hide: {
		fixed: true,
		solo: true,
		event: null
	},
	prerender: false
});

If the user is at the top of the page, the tip is positioned correctly. However, if the user scrolls before opening the tooltip, the y position will be offset by the amount of scroll.

---

Forgot to mention that I don't see this with all tooltips. All of my center/center tooltips display with the correct positioning initially.

[Craig]

This seems like it may be connected to your other post about disconnect... wish I had an iPad of mine to test this out on! Remote debugging is such a pain heh... I'll have another look at the code tonight!

[kiddailey]

If you have an OS X machine handy, you can download the developer tools which comes with a simulator, which is almost as good as the real thing.

In any case, you are right - this might be related, but i'm not entirely sure. I was planning on putting together a little video of the interaction so you could see just what's going on. Much better than trying to explain.

[kiddailey]

FYI: Sent you a PM with a link to the video.

[Craig]

Great, thanks kiddailey. This is definitely a scroll problem with the position calculations. Can you test to make sure this returns true when pasted into the iPad location bar on a page with qTip:

JS Code

j avascript:alert($.fn.qtip.plugins.iOS);

If true, could you test to see if this fixes the scroll issue (can also paste it into the location bar, no need to refresh the page, just paste and re-test positioning):

JS Code

j avascript:$.fn.qtip.plugins.offset = function(elem, container) {  var pos = elem.offset(),  parent = container,  deep = 0,  docBody = document.body,  coffset;   function scroll(e) {  pos.left -= e.scrollLeft();  pos.top -= e.scrollTop();  }   if(parent) {  do {  if(parent[0] === docBody) { break; }  else if(parent.css('position') !== 'static') {  coffset = parent.position();  pos.left -= coffset.left;  pos.top -= coffset.top;   deep++;  }  }  while(parent = parent.offsetParent());   if(container[0] !== docBody) { scroll( container ); }  if($.fn.qtip.plugins.iOS) { scroll( $(window) ); }  }   return pos;  }

[kiddailey]

Got "true" on the first one and the second one definitely fixes it! Hooray!!

The only thing I will say is that the center/center viewport adjusting on the iPad in landscape mode causes the tips to feel "jumpy" as it did on my netbook -- because they align to the top/bottom of the trigger rather than the screen. The reasoning ties back to my last couple of posts in the ominous "adjusts too far" thread, which I'm not sure you saw.

[Craig]

Awesome! I'm taking a look into that now.

[kiddailey]

Just wanted to say that with these last few iOS tweaks, it's looking pretty soild from a functional standpoint on the iPad/iPhone. There are a few things I haven't tested yet that might have some quirks (eg. modal dialogs, specifically the background shading because I know other plugins have issues with that), but I'll let you know if I see anything else.

[kiddailey]

Update: Just tested the modal stuff and it positions and displays perfectly on iOS.

You're going to have to spill your secrets about how you not only got the dark overlay to cover the entire body height, but also positioned the qTip in the center of the viewport! Typically, modal stuff always appears at the top of the page with the overlay only covering the height of the viewport.

[Craig]

Here's the magic sauce you're looking for... straight from the horses mouth:

JS Code

// Create document overlay
overlay = elems.overlay = $('<div />', {
	id: selector.substr(1),
	css: {
		position: 'absolute',
		top: 0,
		left: 0,
		display: 'none'
	},
	mousedown: function() { return FALSE; }
})
.appendTo(document.body);
 
// Update position on window resize or scroll
$(window).bind('resize'+namespace, function() {
	overlay.css({
		height: Math.max( $(window).height(), $(document).height() ),
		width: Math.max( $(window).width(), $(document).width() )
	});
})
.trigger('resize');

[mkeeble]

Hi,

I'm sorry for revisiting this 7 month old issue, but I'm experiencing this problem with qtip2 on the iPad2 using the SVG plugin.

I have quite a complicated SVG store plan, which I'm using qtip2 to display details about each store element (path) when moused over. Everything is working brilliantly on our desktop machines (mac/win) in all browsers.

However, on the iPad/iPhone (both running iOS 4.3) The positioning is perfect if the page is not scrolled. If I tap the element to show the tooltip, it appears where I expect it. It also tracks and moves with the target correctly when the page is scrolled. However, once I've scrolled down the page a little, if I show another tooltip, the positioning is offset on the y axis by the same amount as the page has been scrolled.

I attempted to run the code suggestions above, but instead of 'true', I get '4.3' when running the first example and the second example does nothing at all.

I have made sure that I have the latest version of the code and downloaded again today to double check but the problem persists.

Is this fix supposed to be in the current code or is there something I need to do at my end to achieve the correct positioning or am I missing something else?

Thanks, in advance, for any help you can offer.

Matt

[Craig]

Can you post the results of tryping this in the address bar of your iPhone/iPad and hitting enter please?

JS Code

alert($.fn.qtip.plugins.iOS)

Also, what happens if you set $.fn.qtip.plugins.iOS to true and before creating your qTips? Usually the issue is fixed, but then the offset is off on the desktop browsers instead.

[mkeeble]

(5th September 16:21)Craig Wrote:  Can you post the results of tryping this in the address bar of your iPhone/iPad and hitting enter please?

JS Code

alert($.fn.qtip.plugins.iOS)

Also, what happens if you set $.fn.qtip.plugins.iOS to true and before creating your qTips? Usually the issue is fixed, but then the offset is off on the desktop browsers instead.

Hi Craig,

If I simply type in

JS Code

j avascript:alert($.fn.qtip.plugins.iOS);

I get the response "4.3" (the version of iOS that is running on my iPad/iPhone.

If I explicitly set the parameter to 'true' it makes no difference unfortunately. I don't know if this is relevant but I am testing on iPad 2 and iPhone 4... I don't have any earlier versions to test on at present...

[Craig]

Huh that's odd... it gives out 4.3? It should be a boolean that's output... are you sure you're using the latest code?

[mkeeble]

Absolutely - I downloaded a fresh copy yesterday as that was the first thought that crossed my mind. But it definitely produces "4.3" (ie: the version of the OS) rather than 'true' unless I explicitly set it as 'true'

[Craig]

Oh sorry my bad it should only a be a bool if it isn't iOS. So you're saying the offset bug isn't fixed in 4.3? What happens if you set it to 4.0 and then try the positioning?

[mkeeble]

I do get 'false' if I test it in my desktop browser.

Not quite sure I understand Craig. Do you mean revertt my iPad to 4.0? or manually set the value in my code?

[Craig]

Oh no just set the $.fn.plugins.iOS value to 4.0, which should trigger the repositioning fix for that version. I was led to understand that is bug as fixed in 4.2 but perhaps not...

[mkeeble]

I'll check it out and let you know

UPDATE:
I'm afraid that hasn't fixed it Craig. I've verified that the '4.0' value is now reaching the page, but the positioning is still incorrect when the page is scrolled at all (by the amount of the scroll it would seem).

Could it be anything to do with the fact that the tips have SVG paths as their targets? I don't know if that would make a difference, but I've read elsewhere on the forum that this bug was fixed and it seems strange that I'm still having it. Just a thought...

[Craig]

Hmm can you try out the latest commit please and see if that fixes it? The previous commits only applied the iOS fix to regular elements, not imagemap or SVG elements, which was probably causing the problem. I also added a clause to include 4.3 in the iOS fix, so hopefully you should just be able to call it regularly without any need to set the $.fn.qtip.plugins.iOS value.

[mkeeble]

I will have a look now Craig and let you know how I get on. Thanks

---

Craig, just looked on github and the last commit I can see is from 30 August... am I in the right place? Could you post a link?

Thanks

[Craig]

Sorry that's my bad, had some unstaged changes that were preventing my push. It should be up now.

[mkeeble]

Craig, sorry for the delay - I've checked the update now and it works great. Thanks so much!

[kaihu]

Craig,

Somehow I am still seeing the problem reported in the original post, i.e., the qTip's position is offset by certain scroll amount on iPad. The same page otherwise works fine in IE/FF/Chrome. I am using the latest qtip2 from the github dated Sep 20 based on the timestamp inside the JS/CSS files. I setup a simple example at http://jsfiddle.net/fDavN/1856/ and somehow I am not seeing the same problem there. Wonder if you could help pointing me in the right direction? Thanks.

Kaihu

[Craig]

What is your $.fn.plugins.iOS set to? (Paste jalert($.fn.plugins.iOS)) into your location bar when on the page containing the qTip script)