http://jsbin.com/nesiside/1 (code is available http://jsbin.com/nesiside/1/edit)
If you scroll down in the document and click the "Lock/Unlock" button, an overlay with text will appear. You'll notice that the scrollbar length has been changed to accommodate the overlay height, not the original page height. Click "Unlock" in the overlay, and you return to the original page, in the previous scroll position.
System works great on desktop browsers, and on my Android phone, however, on iOS there is a rendering flash flash when the overlay is triggered or removed. Ultimately, I believe it is the fault of the scrollbar changing.
I've attempted the usual tricks to resolve iOS rendering issues (webkit-backface, transform3d), with no success.
Apparently, showing the content and hiding the overlay (or vise versa) was to much for the iPad 4 to render at once, causing the flash. This is odd because I tested it on an old Kindle and my Android phone and both are handled it fine with their slow processors.
To resolve the issue, I put the the scrollTop() method (used to return the user to the previous position on the underlying page) inside a requestAnimationFrame function. The result isn't perfect (content can be screen scrolling for a fraction of as section), but it is a much better result than an entire page flash.
Related
We're trying to build a chat view in React that behaves like WhatsApp or Telegram: First, it should show 20 initial chat messages, and if users scroll up, additional messages are being loaded.
To make this happen, we remember the position of the first message on top, load more messages before it, and then scroll back to that message to keep the scroll position where it was (and thus prevent the content from jumping).
This already works perfectly on Desktop and Android browsers. But when we try it out on Safari iOS, the browser behaves pretty weird. Sometimes it jumps to the wrong position, and sometimes the whole messages disappear. They will re-appear once you scroll the page again with your finger.
Does anyone know the reason for this strange behavior and/or a solution for this? We've been searching the web for months now.
(Bonus: Any hint to a working (!) React component that allows lazy loading of content on top of a list while pertaining scroll position reliably on iOS would be highly appreciated. We tried quite a number of them, but none worked.)
I am currently developing a hybrid mobile app which makes use of -webkit-overflow-scrolling: touch; on the "content area" to provide smooth scrolling.
I have hit somewhat of a road block however when using this feature. Upon scroll (I check with an .onAnimationFrame loop) I check the .scrollTop position to see if any movement has occured so that I can let various components within the application know of this so they can perform certain actions (Use case examples may be parallax scrolling, controlling culled rendering etc.). This is all well and good when testing in a desktop browser (Ie. Chrome 41) however when debugging within iOS Safari OR iOS UIWebView the scrollTop position seems to be cached when there is a large amount of movement (Eg. a user flicking the view)
This caching means that other elements expecting to know the exact current scrollTop value will fall behind and the view becomes out of sync.
My presumption is that overflow scrolling forces rendering onto the gpu so I'm wondering if there is any way to get around this or to force invalidation of the cached scrollTop value.
DEMONSTRATION: http://jsfiddle.net/skpmkjea/ (load up in safari on an ios device and connect to debugger to see console log of scroll top positions)
Things I've tried:
Forcing an empty element in and out of the root body to try and force a full page update to re-calculate the scrollTop value
Using a container div within the scroll element and checking for the bounding box updating .getBoundingClientRect() but this seems to have the same cached values
More info (I'll add more if it would help anyone):
UIWebView build with Cordova
My main test target is iOS7
The issue exists but is much less noticeable (ie. cached value invalidation appears to occur at intervals) on android 4
This isn't a specific JS code issue, but more the way iOS deals with JS that is causing more problems on my site than most others.
On iOS only (it doesn't happen on Android) if I'm natively scrolling (up/down) and then try to activate some JS just before the scroll has finished (very quickly) then it completely ignores the JS.
I believe that Apple do this so that the UX always remains priority (don't let any crappy JS slow down the user), but in this case it's just a very simple piece of JS that I want to allow to run.
As an example, if a user is scrolling and then quickly presses a tab at the top of the screen that opens a fixed navigation panel then it won't register if the native scroll is still happening. If they press it again (the scroll has finished) then it works.
I'm also using a JS slider to scroll horizontally through images and if I try to scroll left/right just before the native up/down scroll has finished it sort of jumps and isn't good UX. I think it's prioritising the native scroll but still activating the horizontal scroll with some sort of delay.
It's not a massive problem, but not perfect. If everybody slowly navigated the site and waited for the native scroll to come to a complete stop, it would be great. But of course people won't do this.
I don't think preventing the default behaviour will do anything. I have tried to take over the native scroll before on iOS and I just don't think you can.
I think this may actually happen on many sites. I've just tried to find a good example by visiting stackoverflow.com on an iPhone and if you scroll quickly and then quickly hit a link before the scroll has finished it won't register. I don't think text links are as big a UX issue though, but a horizontal slider and big 'open menu' button at the top are much more likely to be hit quickly before the native scroll has ended (as you don't need to read something before you press it, like with text links).
I have various JS scripts on a site that would benefit from this being improved in iOS, so if I can understand a way around it, why it happens, what is going on, then I can apply individual fixes to each of those scripts.
Thanks.
The problem is not that iOS ignores javascript while scrolling (more precisely, while the scroll momentum is active). The problem is that, while that happens, iOS does not really register the position change of elements on the screen. In fact, if you have a handler attached to the scroll event, it will stop firing the moment you stop touching the screen, and then will fire just once when the scrolling stops.
Consequence? You think you're touching a link, but you aren't. The image on the screen has moved up or down, but, to the broswer, everything is on the same position, so, actually, you aren't touching anything (or are touching something different). I got very annoyed when I found this behaviour because, in my case, my page is full of images that are links to a gallery ... and if you touch them while scrolling, the gallery opens showing you not the image you touched, but another (The one that really was on that position when your fingers stopped touching the screen).
Is there a workaround? The only one that I know of is disabling the scroll momentum, but you lose scrolling performance.
On iPad I cannot scroll a web page. It works fine in Safari, Chrome and Firefox on OS X.
The page has an area in which content can be scrolled only horizontally. It consists of a container div which has width = 100% and height = (100% - 40px). I am setting the height by a JavaScipt function which is triggered by window resize events. Inside this container is another div with the width of the content (very wide, to avoid line breaks). Inside that is the content.
CSS properties of the container are:
overflow-x:scroll;
overflow-y:hidden;
white-space:nowrap;
See the page and full source code here: dcfoto.de
On iPad, scrolling is not possible. What am I doing wrong?
By the way: resizing also does not work properly on orientation change. Maybe that's connected.
Unfortunately a two-finger swipe needs to be performed, and even then it is not responsive (when compared to the default one finger swipe scroll).
There are quite many javascript solutions out there, (sencha touch and iscroll being the most promising and advanced)
I would recommend http://cubiq.org/iscroll-4 which is hands down the coolest touch-scroll script out there. It also works for android, but quite more sluggishly since the default android browser albeit webkit based doesnot support css3 3d accelerated properties as good as the mobile safari one.
If I were you I would check for the user agent of the user, and deploy that script for android and ipad/iphone users.
I've got a div that I want to position at the bottom of the mobile browser (Safari + Android) viewport. Currently my div is fixed at the bottom on all the top 5 browsers on Windows (IE, FF, Saf, Chrome, Opera), but that's "the browser window", not "the viewport".
On mobile devices (I've only tried on Samsung Galaxy Tab with Android 2.2 so far) the div appears at the bottom of the page, but if you pinch/punch to zoom in, the fixed div doesn't follow. It stays behind, outside of the viewport.
I'm specifically using the position:fixed and bottom:0 CSS properties to maintain the position, and as I said, it works fine on a non-touch browser.
Am I going to have to resort to keeping the div in the position I'd like it to be (at the bottom of the viewport) by hooking into the touchmove event and looking at (a) the zoom level, (b) the viewport position, and (c) the scroll position?
I'm using JavaScript to inject the div into the page rather than using inline CSS. The good thing is that I don't have to worry about quirks mode (as I'm only targeting Webkit browsers), so that's one positive thing.
I can't set doctype, use inline CSS or inline DIVs. Everything has to be added dynamically via JavaScript. Here's what I've done in my test so far:
var mydiv=document.createElement("div");
mydiv.style.position="fixed";
mydiv.style.bottom="0px";
mydiv.id="floater";
mydiv.style.width="400px";
mydiv.style.height="50px";
mydiv.style.backgroundColor="yellow";
if(document.body)document.body.appendChild(mydiv);
document.getElementById("floater").innerHTML="HELLO";
Your position:fixed won't work on mobile webkit browsers. Take a look at the mobile webkit fixed position problem on http://www.position-absolute.com/. They have a few ways of keeping something at the bottom.
Check out iScroll:
http://cubiq.org/iscroll-4
It seems to be one of the better options out there - definitely worth looking into.
I have used the previous version of iScroll but unfortunately there were a few things that didn't work to standard so we had to scrap the idea. However, the guys at Cubiq have just released v4 of iScroll which promises to fix a lot of the things that were issues in the previous version.
Best of luck!Dan