I've been searching over internet with success, I appreciate if someone can help me.
My problem is, seems that last Google Chrome version has created a bug/or not with scrolling using the mousewheel. I will try explain the issue in the better way.
Case scenario:
I have a page with a IFRAME, the IFRAME has a vertical scroll and his parent window too. In the past when I start scrolling inside IFRAME and when a reach to the end/top the scrolling continues by the parent window, however this behavior has change now when a reach to the end/top the scrolling stops...
Anyone has an idea about that?
Is this a bug?
Is this a configuration?
Can I do something with codding?
Thank you all!
New versions of different browsers do not support iframe properly. Moreover it is now focus oriented. It scrolls only the part of page on which the mouse cursor is and if you want to scroll parent page change your cursor focus.
Posts of linkedin also go like this.
Related
I am interested in hearing from anyone who has experienced this problem in the past or has any idea what the cause might be.
I am using the FullCalendar V3 library and when I click on the more events pop over the scrollbar does not work and I cannot scroll down to see all of the events.
The scroll bar does not work on Google Chrome Version 87.0.4280.141 however I have checked it on Firefox 84.0.2 and it scrolls ok on that browser.
I have not changed any of the library code and I have the impression it is some JavaScript that is the cause but would not know where to start.
Thank you in advance for any ideas.
Below is the popover in question:
This is caused due to a chrome smooth scrolling issue. Assuming you have no control over the browser side and therefor cannot disable that feature. Applying this to the scrolling container inside the popup should fix the issue.
pointer-events: auto !important
Note the selector I used was.
.fc-more-popover .fc-body.fc-widget-content .fc-event-container
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 various fixed divs in my page, like a header, navigation bar etc.
They work fine on mobile, until I click to open a select form element on an iPhone.
Its as if the header is no longer fixed and actually becomes more like position:absolute, where it scrolls with the content.
This is particularly annoying as when you open a select on iPhone, it scrolls the page slightly to make sure the select stays in view as the options slide up, which mean my fixed header moves around.
Anyone got ideas how to fix this? can use jQuery/ javascript to solve
Most of the web browsers do not support the CSS property position:fixed;. I recommend you use the http://jquerymobile.com/ for a complete mobile UI Solution.
*NB: iOS 5 and Android 4 are both reported to have position:fixed support now.
Managed to solve this with the below jquery, it just stops the content scrolling when selecting a form element. You have to have the 1ms delay for it to work for some reason. Maybe this will help someone else:
$('input, select, textarea').on('focus',function() {
var curScroll = $(window).scrollTop();
$('html, body').animate({scrollTop:curScroll},1);
});
On iOS safari, one-finger panning doesn’t generate any events until the user stops panning. An onscroll event is only generated when the page stops moving and redrawn.
I need a way to detect real time scrolling. Specifically, I want to make a sticky menu that will also work on iOS safari. On non-mobile browsers, sticky menu can be done by switching between "position relative" to "position fixed" on the element while listening to the onscroll events. This method won't work on mobile browser because onscroll events are not continuously fired. What can I do?
Answering my own question. iOS7 now support position:sticky
Demo: http://html5-demos.appspot.com/static/css/sticky.html
I've recently spent many hours trying to come up with a practical solution for the same problem. There's no right way to do this, although there are a few decent hacks (most of them mentioned already). The problem is that JavaScript is paused while the user is scrolling. It makes sense when you consider the implications, but it makes it damn hard to implement fixed positioned element.
The best thing that I've been able to find is this wonderful post by the folks at Google. You can check out http://gmail.com in mobile safari to see it in action.
https://developers.google.com/mobile/articles/webapp_fixed_ui
Hope this helps.
I had a similar issue and bound handlers to touchstart/touchmove/touchend using jquery to detect the single finger scrolling and it worked perfectly. In my case I needed to move another element the same amount as the attempted move of another element and it updated nicely as the scroll was attempted so it ought to be suitable for your requirement.
If all you want is a sticky menu, you can save yourself some headaches by using an existing library. I've had success with iScroll:
http://cubiq.org/iscroll
At the very least, you can take a look at how this works and base your solution around that.
Happy hacking!
Old topic for sure, but I can see alot of visits here. If all you want, is a sticky menu, you can use fixed positioning. No need for iScroll there.