John Deighan
unread,Nov 1, 2011, 4:42:47 PM11/1/11Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
  to isc...@googlegroups.com
I believe that the main problem with getting iScroll to work for iframes is that the events (touchstart, touchmove, touchend) are generated in the page contained in the iframe, and although those events "bubble up" through the DOM, they don't bubble up past the iframe boundary. I've seen this before and I believe it is intended behavior. I have a solution that may not be considered good enough, but it might lead to an even better solution. My solution is to embed JavaScript in the embedded page (i.e. the page displayed inside the iframe) that causes the wrapper element - the one in the enclosing page which itself contains the iframe, to scroll the iframe. So, I've attached 2 files - test1.htm and test2.htm. The first, test1.htm, contains the content to be displayed in the iframe. The second, test2.htm, is the one you want to display in your browser, and contains an upper fixed positioned div, and a lower fixed positioned div which contains an iframe. Note the following: 1) I'm almost positive that both files have to be served from the same server, or at least the same domain, 2) test1.htm needs to know the id of the element that will contain the iframe in test2.htm ('second' in this case), 3) the scrolling is a bit jerky and there is no movement after you remove your finger from the screen ('inertia', I think it's called). I'm kinda hoping that the ideas in these files can be incorporated into iScroll 4 to make scrolling more intuitive. Also, the example code is code that I found somewhere in the web, but I can't remember where or I'd give the author credit. I think that since the 2 pages come from the same server, it may be possible to install the event handlers from test2.htm, even though they have to be attached to elements in test1.htm - I just haven't had the chance to try that yet. That would remove the objection that if you have a single page with an iframe, that may display up to 100 pages inside the iframe, 100 pages need this new code added (In our case, the 100 pages are built using the same code that will be able to add the needed code automatically). Also, that would mean that only test2.htm, the enclosing page, would need to know the id attribute of the wrapper element.