I'm trying to build a menu with 5 blocks that the user can spin around.
You can see a demo here: http://m.iijax.com/menu.php
Works fine on iPhone, (if a little sluggish sometimes, but that is beside the point :p ) if i draw my finger more then 90 pixels (which i set as a limit) in either direction the menu spins.
On Android (2.1, a Samsung Galaxy S) however the menu does nothing until i release my finger from the screen, I've tried adding an alert on the 2 functions that changes a bunch of classes around to spin the menu either to the right or left and they do get triggered as I draw my finger.
So my best guess is either the browser locks access to the DOM until touchEnd, or it blatantly cheats and simply shows me some kind of screenshot of the page awaiting touchEnd.
Can anyone confirm either of these theories? I've spent about an hour searching here and on google and found nothing, but maybe I haven't found the rightsearch terms.
I've tried lots of swipe and slider examples I've found however and haven't found anything that animates in real time as i draw my finger.
Would also be interesting to know if this menu works on newer Android versions.
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've been researching how to prevent Safari's feature of swiping at the edge of the screen to navigate to previous/next pages in browser history. I have an application that uses Hammer.js to pan an image, and on mobile the image takes up the whole screen. So if the user happens to start panning at the left edge of the image, for example, it forgoes that by ignoring my little javascript app and instead going to the previous page. I haven't found anything saying it is actually possible to prevent this edge swipe feature...though I did find this: https://gist.github.com/mountainstorm/9430618. However, all it seemed to accomplish for me was breaking mouse scroll functionality.
Any help would be greatly appreciated. Thanks!
I don't think it can be done since it is an OS level feature. As long as the swipes initiate inside the web page, there should not be any issue. If you have sufficient margin from the edge, then it should not be a problem.
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.
I've got a strange problem that's being reported when using a site I'm working on. There's a jQuery animation that appears to "stop" in an incomplete state. The site is www.snopsize.com and the problem occurs when you hit the big yellow carat next/back icons. Ideally, the next item should animate into view in the list.
This works on every device I have access to (a bunch of PCs running Chrome, Safari, IE, and Firefox), but I'm hearing reports that the animation just hangs halfway through and the views end up sitting stuck halfway between the next and the previous, and trying to move through the list just keeps animating to strange halfway points.
The code driving the animation is really simple:
$("#snop_container").stop(true, true).animate({left: '-=' + snop_width});
and
$("#snop_container").stop(true, true).animate({left: '+=' + snop_width});
for next and back. The snop_width is set to 775px and never changes. I'm really perplexed that this seems to work on everything I have access to but seems to fail occasionally given a certain Mac setup. I have no idea what could be happening, but any advice whatsoever would be greatly appreciated!
I am trying to debug this and can't make any headway. I've got this HTML5 JavaScript library I am building and the test page for it can contain large volumes of output as I am piping console.log and exceptions out into the DOM to quickly inspect them on mobile devices (it is the only way I know of inspecting state on an Android device for instance)
Here is the page. So long as I don't push up broken code while I work on this you should be able to produce plenty of debug output which will be pumped into the <body> thus allowing the page to scroll. Note also to toggle the visibility of the big blue debug panel you can tap the header text at the top of the page (like a button).
The issue is specific to iOS: Tapping the iOS status bar does not work in either portrait or landscape modes, and I am not sure what it is I have done with JS or otherwise that has disabled this quite handy feature.
Use of -webkit-overflow-scrolling: touch appears to be the culprit for iOS6 here. It actually looks like iOS5 is less broken w.r.t. this issue.
I think there may be a way to work around the issue by dynamically setting -webkit-overflow-scrolling: touch on the elements that need it by catching touch events on them. Or just leave it off as they still remain usable (just have no momentum).