iOS: qTip position is incorrect, offset by scroll and viewport adjustment

[kiddailey]

Originally posted in the forums, but it got bumped off the first page and doesn't appear to have been addressed, so moving here.

Edit: Since this was reported, I've discovered other related issues that occur in iOS 3.2 (iPad) and iOS 4.2.1. See below.

This issue appears to be limited only to the iPhone and does not seem to occur on the iPad, but it is similar to the issue reported previously for the iPad:

When initially viewed on the iPhone, qTips triggers "above the fold" (ie. before scrolling) position correctly. However, when the page is scrolled, all tooltips become offset by the scroll amount. Scrolling back to the top fixes the position for triggers that are visible above the bottom of the window.

Also, as the viewport is changed on the iPhone (for example, by zooming into a portion of the page), all qTips shift themselves into incorrect positioning. Zooming back out to the full original viewport shifts them back into proper position.

Scrolling AND adjusting the viewport causes the tips to shift up by the scroll amount and also to the left/right/up/down based on the viewport zoom.

Are the fixes you put in place for the iPad limited specifically for the iPad, Craig? It seems like the fixes applied for the iPad bug would resolve this issue for the iPhone.

[Craga89]

Can you possibly post the user agent string for the iPhone you're using? I'll need to update the UA RegExp to match iOS 3.2 for iPhones too!

[Craga89]

Hoping this is now fixed in the latest commits. Let me know!

[kiddailey]

Sorry Craig - I missed the email notifying me of your reply. The iPhone in question has the UA: "Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7D11 Safari/528.16"

And a quick test seems to indicate that it is indeed fixed! Awesome.

[kiddailey]

Just a note that this appears to have been broken again for the iPhone only.

[kiddailey]

Your regular expression for matching was udpated on the 16th to "[0-9_]{3}" for the version number, but my user agent above doesn't match that. "[0-9_]{2}[0-9]" would. Wonder if it's that simple?

[Craga89]

I adjusted the regex to [0-9]{2,3}, did that help?

[kiddailey]

I misspoke earlier about the regex ... (Github ate my and your underscores in the regex, so I think I was just confused :) The original one did match, though it would have yielded 3_ instead of 3_1 like it does now with your revision, so having that may be helpful anyway.

In any case it seems like it would be setting the iOS variable properly, but it still is exhibiting the behavior of being offset by the scroll and the viewport on the iPhone. I'm waiting for my iPad to charge so I can test to verify that this still only affects the iPhone.

[kiddailey]

Nope, confirmed just now that this particular issue of offset/viewport scrolling only effects the iPhone.

[Craga89]

Hmmm well looking at the regex it matches your iPhone as 3.1, which will (or at least should) cause the scroll of the document to be removed.... this is odd..

[kiddailey]

I decided on a hunch to test on my wife's iPhone, which is running iOS 4.2.1, and it works properly! Emptied my iOS 3 phone's cache, history, cookies and still no luck.

It appears that this could be an issue with iOS 3.x. Ugh. Strange thing is that when you posted the fix originally, it was working on my iOS 3 phone (I distinctly remember testing it because I spent some time on my phone checking it out afterwards). I've not upgraded or change the phone since.

[kiddailey]

Since I was in testing mode, I thought I'd revert my qTip to the older builds just to find out where the regression occurred and to make sure I wasn't going crazy :)

I Updated to the March 8th build that I originally tested: "Date: Tue Mar 8 21:20:42 2011 +0000" and sure enough, it positions correctly on all my iOS devices. So I started on the path to find the regression and updated to the very next revision: "Date: Tue Mar 8 22:04:23 2011 +0000." This update broke the positioning on my iOS 3.1.2 iPhone, but not the iOS 3.2 and 4.2.1 devices! The only difference between the builds was the iOS regular expression.

In the build where it works on all devices, the regular expression only matches 3.2 and 4.0:

/CPU.*OS (3_2|4_0)|(CPU like).*AppleWebKit.*Mobile/i

In later builds the regular expression matches all two-digit+ versions, although the full expression only signifies versions less than 4.1 as iOS:

/CPU.+OS ([0-9_]{3}).*AppleWebkit.*Mobile/i

If I simply take the latest April 4th build and set iOS to "false" rather than parse the user agent, here's what I get:

• iOS 3.1.2 (iPhone) Works
• iOS 3.2 (iPad) Broken
• iOS 4.2.1 (iPhone) Works

Obivously, 3.2 (actually 3.1.3, see below) is where the exception begins and (probably) ends with 4.2. Unfortunately, I can't test more finely grained for you, but I can at least offer my best guesses based on the revision history about what the iOS var must evaluate to for it to position correctly:

version	Notes	iOS var
1.0 - 3.1	Not sure about v1-2, but 3.0 versions probably perform like 3.1.2 outlined above	? (false)
3.1.2	Works as outlined above	FALSE
3.1.3	Updated to Webkit 528.18, and is likely to be the point at which it changed, rather than 3.2 since it seems to have the same webkit version	TRUE
3.2 - 3.2.2	iPad only, same webkit as 3.1.3, and probably work similiarly as outlined	TRUE
4.0 - 4.1	All share same webkit version 532.9, but it's newer than 3.2.2, so not sure how it behaves	? (true)
4.2 - 4.2.6	Share a newer webkit version 533.17.9, function as outlined above	FALSE
4.3+	?	? (false)

Hope all that at least gives you some help.

[Craga89]

Hmm perhaps it would be worth including 3.1 in the fix also?

[kiddailey]

Probably. Seems to reason that the 3.1 minors should all be relatively similar.

[kiddailey]

Now that we can re-open issues, I figured I'd open this one since it's an ongoing issue. Unfortunately, the Github upgrade also made a mess of my version table above :(

[Craga89]

Hmm I reverted the regex back to the old (3_2|4_0) test. Hopefully this will fix the issue in the majority of cases?

[kiddailey]

I think that this is mostly resolved :) but there are a few big lingering issues, including the one with modal tips on all versions of iOS I briefly mentioned on issue #103. I'm going to do a brief video to illustrate these for you, but specifically they are:

• All iOS versions: Zooming and shifting the viewport and then displaying fixed modal tooltips causes them to be adjusted incorrectly. I haven't figured out what the logic is in the adjustment, but it seems like iOS is taking the scrollLeft & scrollTop and multiplying them by the current zoom factor or something.
• All iOS versions: If there is no horizontal scrollbar present at full size (ie. we're just zooming in and panning around), when we zoom in and adjust the viewport to the right side of the screen, adjusting a fixed modal dialog's left to scrollLeft can cause the dialog to be displayed partially off-screen. This also ties into the next issue ...
• All iOS versions: If a viewport adjusted (via shift) method tip is on screen, we can cause it to shift completely out of the bounds of the website by letting it collide with the viewport on the left and gradually scrolling to the right. This will continue forever and also makes it impossible in some cases to interact with the right-most side of the tooltip.

The last two of those might be resolved by simply removing the scrollLeft adjustment we added for the fixed modal dialogs in issue #103, but I'm not sure what that would mean for containing elements that have horizontal scrollbars. I also haven't yet tested a 'shift vertical' adjusted tip, but I suspect it might do the same thing (though we can't get rid of that scrollTop adjustment as it affects other tips in iOS) :/

[kiddailey]

See the video descriptions for information on what you're seeing in both these videos.

Illustrating the first two bullets:

http://www.youtube.com/watch?v=lXhq6BVJljk

And this one illustrates the last bullet:

http://www.youtube.com/watch?v=Iy-d5eAqPFM

As I mentioned, this is happening on all versions of the iOS I am testing with (3.1.2/iPhone, 3.2/iPad, 4.2.1/iPhone).

[Craga89]

The first issue seems like a side-effect of the ipads pinch and zoom implementation... not sure if we can do much to mitigate that? As far as I know there isn't a way to test for the zoom level...

The second one looks like it might actually be a cross-browser issue with the shift method... will look into this!

[kiddailey]

The shift behavior illustrated up there doesn't happen in any desktop browser... only in iOS, so I'm not so sure. I think it also relates to the scrollLeft problem that I mentioned before.

I tried removing the left adjustment for iOS that we added in issue #103 (left: !fixed || PLUGINS.iOS ? viewport ...), but it didn't seem to have any effect, so there must be something more subtle going on here.

[Craga89]

Hmm wondering if the new adjustment system has fixed this now?

[kiddailey]

Nope, sorry :( Still seems essentially the same. Though if I zoom out, it does reposition itself correctly.

It's definitely the zoom level that is affecting it as I postulated before and stems from the two viewports (layout and visual) that are present on mobile devices. When zoomed all the way out, both layout and visual viewports are the same. But as you zoom, the visual viewport changes, which is where the extra offsetting must be coming into play.

QuirksMode.org has a ton of additional information that might be of help if you haven't already seen it. The page mentions a method for figuring the zoom level but also says it's unnecessary and gives specifics:

http://www.quirksmode.org/mobile/viewports2.html

[Craga89]

I wonder if this is now fixed with the related changes to the adjust.shift method? The infinite scroll bug definitely seems like it should be!

[kiddailey]

Nope. The bug remains. The issue is that qTip thinks that the viewport is changing size (getting larger) when you are zooming in. In other words, when you zoom, the qTips reposition themselves as if the page has gotten wider and taller. And as the quirksmode article hints, it is probably due to confusion between the viewports:

Both viewports are measured in CSS pixels, obviously. But while the visual viewport dimensions change with zooming (if you zoom in, less CSS pixels fit on the screen), the layout viewport dimensions remain the same. (If they didn’t your page would constantly reflow as percentual widths are recalculated.) ...

It goes on to describe how the measurements for each are derived on mobile devices:

We now have two viewports that we want to measure. Therefore it’s very lucky that the Browser Wars gave us two property pairs.
document.documentElement.clientWidth and -Height contain the layout viewport’s dimensions.

As to the visual viewport, it is measured by window.innerWidth/Height. Obviously the measurements change when the user zooms out or in, since more or fewer CSS pixels fit into the screen.

It also notes the scrolling offset:

What you also need to know is the current position of the visual viewport relative to the layout viewport. This is the scrolling offset, and, just as on desktop, it’s stored in window.pageX/YOffset.

[Craga89]

Hmmm this could get complicated since there's just not enough support for the window.innerHeight/Width :/ I just hada quick test of these properties on my Android device and it exhibits the same behaviour, but doesn't support the inner properties... bummer.

I wonder... what happens if you change the $(window).height()/width() calls to use window.innerHeight/Width instead in core.js?

else if(target[0] === document || target[0] === window) {
    targetWidth = target.width();
    targetHeight = target.height();

[kiddailey]

Changing it to the following:

else if(target[0] === document || target[0] === window) {
    targetWidth = PLUGINS.iOS ? window.innerWidth : target.width();
    targetHeight = PLUGINS.iOS ? window.innerHeight : target.height();

Fixes the issue for modal dialogs on iOS and it seems to work great!

Doesn't appear to have any effect on the growing window width issue though. I'm guessing I'd have something else to change for that...

Edit:

The compatibility chart on quirksmode seems to indicate that at least webkit on android does support window.innerwidth/height. Unless i'm misunderstanding or something:

http://www.quirksmode.org/m/w3c_cssom.html

Test page:

http://www.quirksmode.org/dom/tests/windowview.html#innerWidth%20and%20innerHeight

Edit again:

Found this interesting tidbit that mentions that if you set the viewport for Android, it fixes an issue with Android's innerWidth/Height measurements:

http://notes.kylebarrow.com/a-workaround-for-androids-broken-viewport

[Craga89]

I'm going to set this as closed now, since there isn't anything else I can do to fix the remaining scroll-port issues in Android, as adding meta tags etc should be done by the user.