Sunday, April 1, 2012

Mobile Safari bugs so far

I just bought my first iOS device (the new iPad) and I've been busy squashing bugs in my latest project. And by bugs in my project I mean, of course, bugs in Safari. Here are some of the more annoying ones and how I fixed them.

Changing CSS visibility breaks things

Several of the problems I had seem to have been caused by various problems with Safari's handling of visibility. For example, a number of elements in the app use the following CSS transition to fade in and out: [codesyntax lang="css" title="Transitioning Opacity"]
.hideable { 	opacity: 0; 	visibility: hidden; 	transition: visibility 0.5s linear 0.5s, opacity 0.5s ease; 	-moz-transition: visibility 0.5s linear 0.5s, opacity 0.5s ease; 	-webkit-transition: visibility 0.5s linear 0.5s, opacity 0.5s ease; 	-o-transition: visibility 0.5s linear 0.5s, opacity 0.5s ease; }  .visible { 	opacity: 1; 	visibility: visible; 	transition-delay:0s; 	-moz-transition-delay:0s; 	-webkit-transition-delay:0s; 	-o-transition-delay:0s; }
[/codesyntax] I use visibility for two reasons: (1) elements can be sized according to their contents before being shown, (2) visibility can be transitioned. The second reason is important, because otherwise it would require additional Javascript to delay the hiding of the element until after the opacity transition runs. This works in Desktop Safari, Chrome, Firefox, the Android Browser, and Mobile Chrome. In Mobile Safari, however, the element does not get shown until you click on another link. I originally solved this by disabling the visibility transition in iOS, but I ran into another problem. Merely toggling visibility breaks Mobile Safari's new native "overflow: auto/scroll" functionality. I'll talk about this problem in more detail later. For now, the solution is to disable the transition and use display instead of visibility in Mobile Safari: [codesyntax lang="css" title="Mobile Safari Fix"]
body.iOS .hideable { 	display: none; 	opacity: 1; 	-webkit-transition: none; 	visibility: visible; }  body.iOS .visible { 	display: block; }
[/codesyntax]

Overflow scroll breaks on visibility toggle

iOS5 finally introduced scrolling within an element. Previously, this had to be achieved with Javascript (e.g. iScroll). Frankly, I was pretty happy with my Javascript solution, but some variation of the position fixed bug mentioned below was breaking it. The touchable portion of the inner DIV scrolled with the document, rather than remaining fixed.; if the document was scrolled partway down, the fixed element no longer scrolled. iOS's solution is fairly simple, just add the following to your CSS: "-webkit-overflow-scrolling: touch;" I imagine it's done this way because they're afraid of breaking apps that relied on overflow-scroll just not working. It works pretty well, though it does not use the custom scrollbars. It also does not work if the scrolling DIV is contained in an element that was previously visibility-hidden. This time, it has nothing to do with transitions. The only fix I can find is to use display instead of visibility.

 Javascript scrolling breaks touch events on position-fixed objects

This was a weird one. I put buttons on the right edge of the screen to allow a user to page up and down the document. They were position-fixed (supported in iOS 5!) and they worked. Once. You couldn't click them a second time. If you clicked one, all the other position-fixed buttons stopped working. If you then scrolled normally, everything started working again. Interestingly, if I just scrolled down 100px, the button would stop working, but if I then touched a spot 100px above the button, it would register. It's as if Safari has a map of elements for the purpose of registering touch events that stays fixed to the page (ie: position absolute), while the visible representation of the elements stays fixed to the screen. Thus, when the page scrolls, the map goes with it. For whatever reason, Javascript doesn't trigger a recalculation of where the elements are. I disabled the buttons in iOS. Apple is aware of this, so a fix may be coming.

Originally posted by William Barnes (Billy Barnes)

No comments:

Post a Comment