[Solved] Weird Opera positioning

[pulsecode]

I searched the forum here before posting this, and i found an old post mentioning odd Opera positioning, but that was marked as [solved].
So i figured it might be a good idea to bring this up!

The tool tips appear at seemingly random positions in Opera.
Check your homepage for example. The tip at the top jumps about to all kinds of positions as you roll over the menu items. Same applies to the tip at the bottom right.

Personally, i don't use Opera! But i do use it for testing sites in development, which is how i stumbled across this little quirk. (i also have to add a vertical positioning fix for the tool tip tail on IE else there is a separation... but thats another story).

[kiddailey]

Which version of Opera are you using, pulsecode? Everything appears to be okay for me on both Craig's site and my own in Opera 10.63.

[pulsecode]

Hi kiddailey, i'm using the latest version of Opera, so 11.01, build 1190

[Craig]

Seems to be working fine for me here too, using the same build.

[pulsecode]

Hm, weird!
I've cleared my cache and reinstalled Opera to double check but.... it still does weird things for me.
Here: http://www.absolutewebhostingservices.co...pshots.jpg

[Abrasive]

(23rd February 19:32)pulsecode Wrote:  Hm, weird!
I've cleared my cache and reinstalled Opera to double check but.... it still does weird things for me.
Here: http://www.absolutewebhostingservices.co...pshots.jpg

Mine does this as well. I'm using Opera 11 build 1156.

However it only has the problem in full screen. If I shrink the window some the tooltips appear in the correct locations.

[kiddailey]

And I'll confirm and revise what I said in my first post. It's definitely a full-screen issue. When I go full-screen in 10.63, it does in fact get all screwy just like the image pulsecode posted. Non-fullscreen works correctly.

---

Edit: Actually, it's not specifically full-screen. It'd be more correct to say "large-window."

I manually adjusted my window size slowly, testing the tips between each upscale. The tips started position incorrectly just before I got to the full size of the screen (1920x1200)... probably within 200 pixels or so.

Incidentally, I tested a bunch of different resolutions lower than 1920x1200 and none of them exhibited this problem with a full-screen window. It seems to be a certain window size threshold that is causing the issue.

[pulsecode]

Yep, thats spot on kiddailey!
I was trying that exact thing and was coming to post my findings, but you beat me to it haha!

I find the threshold for me is 1768 pixels wide for the view port (excluding scroll bar).
It is from that size and greater that the tool tip wanders off.

[Craig]

Perhaps the latest commit fixed this for you guys?

[pulsecode]

Hi Craig (awesome script by the way!)
I tried the latest commit on my own site, and unfortunately it didn't fix it for me.

[kiddailey]

Strange.

@Craig: Only the tooltips in the main menu of the qTip2 site seem to exhibit the problem for me still. All of the demos work properly, even with popped-out of the page and viewed full screen.

What is really frustrating is that when I bring up the element inspector in Opera to examine the calculated CSS on the incorrectly positioned main nav tooltips, the tooltip suddenly jumps into the proper position! What the heck!?

On my own dev site, I have no positioning problems with Opera 10.63 even in full screen mode.

This really seems like a bug in Opera.

@pulsecode: lol! I was entertaining the idea of determining the exact pixel measurement, but didn't get to it. Glad you figured that detail out.

[pulsecode]

Haha, thanks kiddailey
I kind of like doing stuff like that. I may have issues... but anyway...!

Yeah, i agree it does seem like a perculiar bug in Opera itself.
I've tested in every browser i usually test in (IE 6 to 9RC, Firefox, Chrome, Safari, Opera) and even on a few different phone browsers and i can only reproduce the error in Opera, when the window is that size or greater.

[kiddailey]

@pulsecode - I'm curious as to what the commonality between Craig's main menu tips and your site are. There must be something about how the DOM is structured or the qTip init that is causing it. Like I said -- I can't recreate it on my site at all.

Would you be willing to post your qTip initialization?

[pulsecode]

Thats a fair point actually kiddailey.
You mentioned that you get no such errors on your dev site so, it must be something invoked by certain conditions.
Its late so i'm feeling a bit dim... what exactly would you like me to post?
I can link to a html page of the site i'm building if thats any help? Or... just let me know what to upload and it shall be done

EDIT: I CAN link anything you want! I managed to type i cant link first! Sorry! Its late... thats my excuse

[kiddailey]

A link would be helpful, but even just the javascript where you assign the qTips might reveal the commonality.

[pulsecode]

No problem!
Ok so here is a page from the site: http://www.absolutecreations.co.uk/sc-v5...sults.html
And the javascript file is here http://www.absolutecreations.co.uk/sc-v5/js/tips.js (just saving you a view source!)

[kiddailey]

Okay ... After looking at your code and Craig's site, I've whittled it down to the cause, which is the following combination: Setting position.my to ANY value and having a title that is more than a few characters long. As an additional bonus, if the tip overflows (I believe the container element), it will cause the positioning to be different than if it does not.

I've created a demonstration, which is linked to the nightlies and jQuery Google CDN so we can test easily:

http://www.kiddailey.org/files/other/ope...n_bug.html

This is, I believe, as simple a demo as you can get. There are three unordered lists containing a single link with a title tag in each. The first group positions the qTip to the left and the second to the right so that you can see what happens when they overflow the window. The last group does not have a position.my, but does have a position.at setting.

When viewed in Opera in a window smaller than roughly 1768 pixels wide, everything works fine. However, if you view in a larger window, the following happens:

• All links with shorter title tags (1, 3, 5, 7, 9 and 11) display properly
• Links 2 and 4 "wrap backwards around and up a line" to fit the tooltip within the window, causing them to be positioned wrong
• Links 6 and 8 simply "shift up a line" and point at the wrong element as the tooltip doesn't extend out of the window to the left
• Links 9, 10, 11 and 12 all display properly due to the lack of a position.my setting

Whew!

At this point I'm not really sure whether this is a qTip or Opera issue, but at least we now know what the cause is and hopefully it'll help Craig figure it out

[pulsecode]

Really very impressive investigative work there!
You have made it extremely reproducible too. My hat is off to you kiddailey

I tried setting my tips widths in the css file to a constant (no min or max) and they all position correctly, so the length of the tip contents definately affects it.

[kiddailey]

Thanks. One other note that on a discovery I made after that which might be related.

If you make the browser window small enough that the horizontal scroll bar comes into play and the tips are near the edge, the tip widths shrink to fit within the window, causing the title tag text to wrap and also sometimes causing their position to shift (depending on the length). This doesn't happen on the nav for Craig's site, I think because he's using the position.target setting, but it does on yours.

This is happens in every browser that I've tested in: Opera, Chrome, Firefox and Safari.

Hard-coding the width might resolve this issue.

[pulsecode]

Ah, good catch!
I'm not too worried if the tips go a bit odd if the window is made significantly smaller than the site width.
Its a toss up between a bit of oddness if people make the window super thin or hard coding the width of every tip (20 variations for the property facility icons, 14 for sharing links, 3 map links and so on... mainly because i want the padding around the contents to be uniform) But thank you for bringing that to my attention

[Craig]

This looks to actually a be feature of the CSS specification relating to the max-width... but I'm not keen on the idea of hard-coding width except where necessary (this is done in IE7 and below already). But it would fix the issue I suppose. Seems odd it would cause problems on huge screens though and only in Opera, though I understand it also causes problems in other browsers on much smaller screens.

Not really sure what to suggest with this...

[kiddailey]

"It's not a bug, it's a feature!"

After some more research and testing, I'm going to have to disagree with you on this one and say that it's definitely a bug Good news is that I have a duct-tape fix that works 100% of the time and along with the info below, will probably help you resolve this one!

Here's the test I started with (html attached below):

1. Created a single anchor link and two span's containing the same text, with ui-tooltip-content having no padding, margins or border and the same line-height and font-size as the body
2. Using javascript, displayed the width of both spans before qTip init: both 112px
3. Initialized a tooltip on the anchor using only the first span for the content and pre-rendering
4. Using setTimeout, displayed the width of the spans again and see -- first span: 50px, second span: 112px (the setTimeout is required, because the size doesn't immediately become wrong)

This lead me to believe that the error is in qTip's width calculation. So I thought that maybe forcing a recalculation might fix the issue:

1. In the setTimeout, add an API reposition call
2. Display the width of the spans again and see -- first span: 112px, second span: 112px (AHA!)
3. Hover over tip and see it positioned correctly after API.Reposition call (AHA AHA!)
4. Mouse out and mouse back in and see it is displaying incorrectly again (Blah)

So as you can see, the minute that the span is used by qTip for the tooltip content, the width calculation suddenly becomes incorrect for both the ui-tooltip-content and the original element. Curiously, the tip is still displayed at 112 pixels wide in the browser, even though the span and ui-tooltip-content claim to be 50px wide. Also, if you turn pre-rendering off, both spans will remain 112px wide until the tooltip is rendered, at which point, it will think it's 50px.

If we force a recalculation by using the reposition command of the API, the tip will have the correct width calculations again the next time it is shown, but then will revert to being incorrect for all subsequent showings.

So apparently, after a reposition the calculations are correct, but something happening after that (perhaps in the show, hide or render events) is causing a miscalculation.

You've probably already guessed my duct-tape fix: constantly call the API reposition in the show event:

JS Code

$('.selector').qtip({
	...
	events: {
		show: function() { $(this).qtip('reposition'); }
	}
 
});

@pulsecode - I wouldn't recommend implementing this into your site, but if you wanted to just put it in temporarily to confirm that it indeed resolves the issue for you, that'd be appreciated.

[Craig]

This is actually quite strange because the reposition method is actually called after the show effect is finished anywho... say whaaaaaat?! I'll have to look into this, but thanks yet again for the info kiddailey, helpful as always!

[kiddailey]

Yeah, I wasn't sure of the lifecycle, which is why I mentioned the hide and render methods as possible culprits as well. If reposition is called as the last action of show, then it's probably not an issue there.

I'll see if I can pinpoint the location a little better.

---

Without modifying the qTip library itself to output stuff (my next step), here's some basic output from event binding:

• Before init:112
• After init:112
• Event:render:50
• Before reposition:50
• Event:move:50
• After reposition:112
• Event:show:112
• Event:move:0
• Event:hide:112
• Event:show:50
• Event:move:0
• Event:hide:112
• Event:show:50
• Event:move:0
• Event:hide:112

Safari output for comparison:

• Before init:112
• After init:112
• Event:render:112
• Before reposition:112
• Event:move:112
• After reposition:112
• Event:show:112
• Event:move:0
• Event:hide:112
• Event:show:112
• Event:move:0
• Event:hide:112
• Event:show:112
• Event:move:0
• Event:hide:112

[pulsecode]

Wow! You are quite the testing legend kiddailey!

Yep, i can confirm that does indeed fix it for me too! Of course i won't use it in the final site, but I've applied it and uploaded it to the test folder for now
http://www.absolutecreations.co.uk/sc-v5...sults.html

I applied the fix to the green icon tooltips but not to the ones in the sharing bar in the footer, for comparison.