iPad and iframe scrolling problem

  • Posted by Stacey on 18 May 2011
    |
    0 Comments
    |

So Steve has decided in his infinite wisdom that we don't need to scroll iframes on his iPad. At one point in time, he deemed it acceptable to allow iframes to scroll with two fingers, but apparently we are no longer deserving of that luxury.

 

That leaves web developers in a tough spot. We had an app that implemented fancybox for the add/edit forms. Our 'normal' implementation of fanycbox is in iframe mode, which meant that they were not scrollable on an iPad. Changing the fancybox to inline mode solved the iPad scrolling problem, however it broke all the refresh javascript we had set up. But with a combination of inline fancybox and php level redirection, we got it all set up.

 

The case was as follows:

  • Our add/edit forms opened in a fancybox in iframe mode. Some were so long they needed to be scrolled on an iPad.
  • The submit was handled by ajax, and the responsetext gives us back the id of the newly added/recently edited item.
  • Then we refresh the parent window and jump to the newly added/recently edited item.
  • We're looking to get this fixed with minimal effort and specifically for the iPad (so preferably keeping fancybox), so we don't fix things for the iPad but introduce bug for other platforms

 

Our solution

I opted for an inline fancybox to solve the iframe-won't-scroll-on-an-iPad-problem.

// let's first get a javascript var set up to check if we're rockin' the iPad
var isiPad = navigator.userAgent.match(/iPad/i) != null; if(isiPad){ // then if we're confronted with an iPad, we need to set fancybox as inline
       
        $("a.fancybox").fancybox({
            'type' : 'inline',
            'width' : 900,
            'height' : 700
        });
       
} else { // otherwise default to the standard iframe functionality
//so everything still works in every other browser

       
        $("a.fancybox").fancybox({
            'type' : 'iframe',
            'width' : 900,
            'height' : 700
        });
   
}

But I couldn't get the redirect script (something along the lines of parent.window.location) to get going in Safari. I didn't spend time on this issue to figure out why the javascript wouldn't work, but switched gears to getting the iPad redirect to happen in de php code rather than the javascript.

// here we also need to check if we're dealing with an iPad or not
$this->isiPad = (bool) strpos($_SERVER['HTTP_USER_AGENT'],'iPad');
...
// then at the end of the add/edit function we determine what we need to do: if( $this->isiPad == true ){ // if it's an iPad than redirect the main window
//and jump to the recently added/edited anchor

            $url = (isset($_REQUEST['_REDIRECT_BACK_URL'])) ?
 $_REQUEST['_REDIRECT_BACK_URL'] : $_SERVER['HTTP_REFERER'];
            Director::redirect($url."#".$className.$this->currentRecord->ID);
} else { // otherwise just return the edited/added item id to the ajax function
            return $className.$this->currentRecord->ID;
}

And voila! The iSrcoll 4 javascript solution was a candidate as well, which would also have been a minimally invasive fix, but it didn't play well with fancybox. Since there is not much out there about this issue, if there are any other tips and tricks out there to make iframes scroll without a complete rebuild for the iPad, we'd love to hear about it!


Post your comment

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments