iOS 5 Safari Bugs: Trio of Test Cases

published:: 2011.12.04
topics:: mobile

I've run into two bugs and a third bit of tricky behavior with Mobile Safari on iOS 5. I thought I'd share what I found in order to hopefully save somebody from pulling out their hair.

1. Bug With CSS Translated Form Fields

In this bug, giving keyboard focus (such as via JavaScript) to a form input that is translated off screen with CSS transforms causes the page content to shift position and the text input caret to render in the wrong place.

Check out my test case.

2. Inconvenient Behavior with Fixed Positioned Header Bars and Form Fields

Many of you may begin using iOS 5's new CSS position: fixed; support to add fixed nav or header bars to the top of the screen. If you have any form fields in your content that are given fixed positioning (such as a search field in your header bar), you must anticipate that your fixed positioned content will come unglued when those form fields are given keyboard focus.

See my example, including a suggested design fix.

3. Fixed Position Content May Become Un-Clickable or Invisible

This is a particularly pernicious bug. If you add content to your mobile web site / app via AJAX, or reveal hidden content to the user, and this new content scrolls off screen -- if a user reloads your site while scrolled to the bottom of this content, it may make your fixed positioned content (such as a top nav bar) either disappear or become temporarily un-clickable upon reload.

Read my test case for more information, and for a bug fix.

That's it for now. I hope this is helpful to you.

6 Comments…

Comments

Brian Blakely launched this comment T plus 13 years.

It is easy to tell when an element has position: fixed set in iOS, because said element vibrates uncontrollably when you scroll the page!

position: fixed needs to be fixed, and before Apple does so, the feature should only be used for the most non-critical treatments. For header-content-footer layouts, I suggest using flexbox and -webkit-overflow-scrolling: touch; (with iScroll as a shim).

Brian,

I have not seen the behavior you describe with the wobbling. I made this site with a fixed header, and you can scroll without any visual problems: http://newdealdesign.com/blog/mixing-it-up

But yeah... fixed does need to be fixed. Sadly, some of the bugs that affect fixed are just as present with -webkit-overflow-scrolling: touch; so that's not a perfect solution either.

The fixed position bug is worse than you think. See my post for further details on it. Basically the 'clickable area' of an element ends up scrolling with the page, while the 'visual area' stays fixed where it should. Once you perform an actual finger scroll the 'clickable area' moves back into the proper place.

You can see what I mean by checking out the bug example I posted as my URL on here and in the stack overflow post.

As well you can test it on your own bug page by loading the page, click the button in the header, then finger scroll approximately 50px, reload the page, now click the button, it doesn't work - however, click 50px below the button and you'll see that the button is indeed still clickable except the 'clickable area' has moved down to where you scroll the page to and does not move back into the proper place until a real finger scroll is done...

please let me know if you find a workaround as it's really affecting the functionality of a site I'm doing..

http://stackoverflow.com/questions/8752220/mobile-safari-bug-on-fixed-positioned-button-after-scrolltop-programmatically-ch

http://www.tsdexter.com/MobileSafariFixedPosBug.html

Cliff Harris launched this comment T plus 12 years.

I have experienced case #3 in an IPhone app that puts text on the screen with HTML and adds an index menu with CSS.

I figured out that my position fixed menu was "scrolling out from under" the displayed menu. What I saw was that after a scroll, a touch in one menu item was actually touching a different menu item because the menu had scrolled with the body of text, even though the visible menu hadn't moved. I also found that a tiny scroll will restore the menu to working correctly.

Now I'm trying to figure out how to work around this problem so my iPhone app works correctly. No success yet. I am thinking that maybe I can use JavaScript to scroll after a touch event, but haven't investigated this yet.

My test case is here (a browser will add a scroll bar that will not appear on an iDevice):

http://www.misterpeachy.com/index_test.html

vimil launched this comment T plus 12 years.

Fixed positioning also does not work properly if you pinch zoom the page. The fixed position div changes its location on the screen if the page is zoomed

Zachstronaut.com Home