My Problem:
In my project, there is an animated container (named .uebersicht) who brings in some divs with a scrollable list. The animation flips (thanks david walsh) between two different lists in my app. Because both of them should be scrollable I have to flip and kick away the flipped container.
I have simplified my markup and CSS and made a fiddle - but the fiddle is working correct :D (maybe a good trace...) So I put it on a hosting service.
site (scrolling not working): http://fiddle.bplaced.net/52426221/
fiddel (same code, works as expected): https://jsfiddle.net/58omteyL/5/
Nevertheless, for a better understanding I visualize my problem:
(if you wonder about the different containers, they are important for the rest of the app)
My approach works well on touch and mouse interaction but the Mac trackpad (like the one in a MacBook) and maybe (could not test this) the magic pad and magic mouse on Mac are just able to scroll the container every 2nd/3rd/4th time.
It seems that Safari 12.0 under MacOS 10.13.6 tries to scroll the wrong container (window-element).
Reproduce the bug:
check out the fiddle with a MacBook/MagicPad/MagicMouse
set
your system scrolling direction to not natural
point in the yellow container and scroll down
if this works (sometimes) move and click around (inside or outside the container) and try again
It seems that there is an area in the container where scrolling never works.
Why this is a SO Question:
You could argue that this is a Safari bug and nothing for SO. But when I'm using the animations from w3css (unfortunately there is no flip) scrolling works as expected.
Hints from the Comments here
When the div is scrolled to the top and you scroll up, the focus goes to the parent and you have to lift the fingers before you are able to scroll down
My trackpad setting is not natural (swipe down = scroll down) changing these setting to natural (swipe up = scroll down, this is standard) make my example work
When scrolling is blocked you can't even scroll with js using scrollTo etc. No scrolling event is fired
The question stays the same because I can not ensure that every user has the setting to natural and not not natural like me.
I have got the bug on: MacBook Pro (15-inch, 2016)
Safari : Version 12.0 (14606.1.36.1.9)
I have added overflow: hidden to HTML, BODY and seems working.
It might be related to locking the body while scrolling but not sure.
I can test it again if you update the code by adding
html,body {
overflow:hidden
}
It's very hard to reproduce and trace properly the issue, but what it seems to work on my Mac is to add overflow:hidden; also on the other two wrappers id="item1" and class="content". In that way the only thing that remains to scroll is the div you want to scroll. I think it could be worth to give it a try.
MacBook Pro (Retina, 15-inch, Early 2013) - OS 10.14.1 -
Safari version Version 12.0.1. - trackpad natural and not not natural
Hope this help.
Finally after a few good comments here I found a solution but it is more likely a workaround (thanks for your input).
I played around with some eventListeners, capturing and bubbling. It seems that the scrolling goes down to the scroll element (capture) but is not bubbling up again. Listen to the scroll event and scroll via JS in the right direction until DOM is unblocked was getting to complicated. But if I modify the style (position/size) of the scrolling element .styleWrap .scrollable the blocking was gone !
After that it turns out that it prevents Safari from any blocking when I modify this element after the animation was finished.
So my workaround is to make a style change and revert that after the CSS animation has been finished - and voilà :
function slide(slideName){
// scroll to top
scroll(0,0);
// show the Slide
var slideElement = document.getElementById(slideName);
slideElement.classList.add('show');
}
setTimeout(function(){
slide('item1');
// make a change to be able to revert this change
var scrollDiv = document.querySelector(".scrollable");
scrollDiv.style.top = "1px";
// change some style (reset the prev. change)
setTimeout(function(){
document.querySelector(".scrollable").style.top = "";
}, 1300 + 10); // CSS animation time + 10ms
}, 100);
Maybe this is the reason why the w3css animation does not lead into blocking...
You can test it here (I add more px to the topto make it more visible here): http://fiddle.bplaced.net/52426221g/
I'm not 100% satisfied with this solution because:
it is a CSS problem solved with JS
you need to know the animation timings (which can change with design)
Therefore I would like to change the accepted answer if there is a CSS solution
Related
My use case is need to build large table using SDL. and I’m looking for smooth scroll like browser does. Anyone have idea ? how to implement smooth scrolling in SDL ?. I tried with SDL_MouseWheel event . but it doesn’t look smooth.
If the target devices have an "analogue-y" input method, like a touchscreen or trackpad, you will find the smoothest subjective scrolling experience by using that. Perhaps SDL_TouchFingerEvent or SDL_MultiGestureEvent will get you what you need.
If all you have to work with is a traditional notched scroll wheel, you'll need to interpolate, as #keltar suggests.
The absolute easiest way to accomplish that is linear over time, something like
/* on mouse wheel event received */
if (event.type == SDL_MOUSEWHEEL)
{
targetScrollPosition += event.wheel.y * MY_SCROLL_SENSITIVITY;
}
/* each frame, animate scroll */
if (visibleScrollPosition < targetScrollPosition)
{
visibleScrollPosition += MY_SCROLL_SPEED;
}
else if (visibleScrollPosition > targetScrollPosition)
{
visibleScrollPosition -= MY_SCROLL_SPEED;
}
However you'll find this is not much smoother and quite unfriendly to rapid scrolling, so you'll want to look into cubic or other methods.
Here is some background reading with code examples. http://paulbourke.net/miscellaneous/interpolation/
Bear in mind that the user can scroll further--in either direction--during the animation so it needs to follow the desired position at all times. There is nothing more frustrating than scrolling down, then scrolling up, and then watching the viewport slowly do both instead of just going straight to where I wanted to be. In fact, I personally don't like smooth scrolling at all, and usually turn it off in favor of immediate feedback; so, if this table will have users other than yourself, before putting in a ton of effort be sure to account for their personal taste.
In a web page I have an input field and a div that is fixed to the bottom of the window (with these CSS properties: position:fixed; and bottom:0;
I made a Codepen to show what I'm talking about: https://codepen.io/anon/pen/xpQWbb/
Chrome on Android keeps the div visible even when the soft keyboard is open:
However, Safari on iOS seems to draw the soft keyboard over the fixed element:
(I should mention I'm testing on the iOS simulator on my Macbook, because I don't have a working iPhone)
Is there a way to make iOS Safari keep the element visible even when the soft keyboard is open, like how Chrome does it?
I recently ran in to this problem when creating a chat input that should stay fixed at the bottom of the page. Naturally the iOS keyboard displayed on top of the chat input. Knowing the exact keyboard height seems more or less impossible. I embarked on a quest to find a solid value to base my calculations on so i can manually position the chat input container above the keyboard. I wanted to find the actual "innerHeight" value, in other words the currently visible area of the webpage. Due to how the iOS keyboard works, the only way to get that value with the keyboard open seems to be to scroll to the very bottom of the page, and then take a sample of "window.innerHeight".
So, i set up an event listener on my input field on 'click' (since on 'focus' caused a lot of issues for me). This opens the keyboard, which takes a while, so after i set a timeout for 1000ms to make sure (hopefully) that my keyboard is fully open. After 1000ms i quickly scroll to the bottom of the page with javascript, save the value of "window.innerHeight" in this state, and scroll back to where i was. This gives me the actual height of the visible area on the screen.
It seems like the browser window is placed behind the keyboard until you scroll to the very bottom, in which case the whole window 'scrolls up' and the bottom is placed at the top of the keyboard view.
Once i have this value i use currently scrolled value (window.scrollY) plus the value i saved minus the height of my absolute positioned element to determine where to place it. I opted to also hide the input while scrolling since it's flicking around quite a bit. Another downside to this is that you get a quick flick of the page when it does the measurement at the bottom.
Another thing i couldn't solve was the variable height of the address bar. I just made the input a bit higher than i needed so it would have some "padding" at the bottom.
var correctInnerHeight = window.innerHeight;
var isFocused = false;
var docHeight = $(document).height();
var input = $('.myInput');
input.click(function(e){
isFocused = true;
input.css('position', 'absolute');
// Wait for the keyboard to open
setTimeout(function(){
docHeight = $(document).height();
var lastScrollPos = $(document).scrollTop();
// Scroll to the bottom
window.scroll(0, $(document).height());
// Give it a millisecond to get there
setTimeout(function(){
// Save the innerHeight in this state
correctInnerHeight = window.innerHeight;
console.log(correctInnerHeight);
// Now scroll back to where you were, or wish to be.
window.scroll(0, lastScrollPos);
fixInputPosition();
// Make sure the input is focused
input.focus();
}, 1);
}, 1000);
});
input.on('blur', function(){
input.css('position', 'fixed');
input.css('top', 'auto');
input.css('bottom', '');
isFocused = false;
});
$(window).scroll(function(){
fixInputPosition();
});
function fixInputPosition(){
if(isFocused){
var offsetTop = ($(window).scrollTop() + correctInnerHeight) - input.height();
offsetTop = Math.min(docHeight, offsetTop);
input.css('top', offsetTop);
input.css('bottom', 'auto');
}
};
body, html{
margin: 0;
}
html{
width: 100%;
height: 2000px;
}
.myInput{
position: fixed;
height: 30px;
bottom: 0;
width: 100%;
border: 1px solid black;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<input type='text' class='myInput'>
Check out this thread, it talks about a work around that may be more feasible in terms of code. In brief it talks about using the height of the keyboard to move the content into view. All be it a bit hacky it may be difficult to pin down the exact height of the keyboard across devices.
Unfortunately, due to the nature of the IOs Safari keyboard it's not part of the browser viewport so cannot be referenced as you would do typical elements.
#Bhimbim's answer may a good shot too.
Regards,
-B
i experienced this before. What i did back then was :
Make a listener when keyboard is hit.
When keyboard is hit resize you webview's height with screen height - keyboard height.
To do this trick you need to make sure that you html is responsive.
I can show more code in the IOS side, if you're interested i can edit my answer and show you my IOS code. Thank you.
Hi again, sorry, i was mistaken, i thought you were creating apps with webview inside. If you still wanna do this by listening the keyboard i still have work around for you. It may not the perfect way, but i believe this will work if you want to try. Here my suggestion :
You still can have listener from webpage when the keyboard is up. You can put a listener on your textfield by jquery onkeyup or onfocus.
Then you will know when the input is hit and the keyboard will show.
Then you can create a condition in your java script to manipulate your screen.
Hope this give you an insight friend.
#Beaniie thank you !.
Hi Andreyu !. Yes correct, we can not know the keyboard height, not like my case with WebView, I can know the keyboard height through IOS code. I have another work around, not so smart, but might work. You can get the screen size and compare to array of IOS device screen size. Then you might narrowed down the keyboard height by surveying through IOS devices. Good luck friend.
Try using position:absolute and height:100% for the whole page.
When the system displays the keyboard,it plTaces it on top of the app content.
One way is to manage both the keyboard and objects is to embed them inside a UIScrollView object or one of its subclasses, like UITableView. Note that UITableViewController automatically resizes and repositions its table view when there is inline editing of text fields.
When the keyboard is displayed, all you have to do is reset the content area of the scroll view and scroll the desired text object into position. Thus, in response to a UIKeyboardDidShowNotification, your handler method would do the following:
1.Get the size of the keyboard.
2.Adjust the bottom content inset of your scroll view by the keyboard height.
3.Scroll the target text field into view.
Check the Apple developer's guideline to learn more:https://developer.apple.com/library/content/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html
So even the Polymer website has this issue. This is an SPA-world problem.
Repro: Go to http://www.polymer-project.org/docs/elements/core-elements.html, click on e.g. core-ajax on the left and scroll down to the middle, then goto core-xhr. Note the scroll position.
What are some best practices considering that I a) want to avoid behavior like the above, but also b) want to preserve the scroll position for when I use the back arrow to goto a page I've already been? It'd be nice if core-pages had support built in.
This might work as a workaround. You can use the fire event in polymer, once something fire the event you listen to the call and force the page to scroll to top. At least this solved my problem with core-animated-pages transition: slide-from-right.
Polymer
this.fire('scroll-top')
Index.html
document.addEventListener('scroll-top', function(){
// Access the main core-header-panel
var scaffold = document.querySelector('core-scaffold');
var scrollArea = scaffold.shadowRoot.querySelector('core-header-panel');
scrollArea.scroller.scrollTop = 0; // Scroll to top
}
)
update 01/01/2018
Polymer now has a nice element for this:
iron-scroll-threshold
I have a SVG chart using d3js. We can add some points to this chart and move it. When I have a big page and so when we need to scroll it, it works with the mouse. But I have an input screen with multi-touch and in more I develop my app for mobile.
The input with the chart and the scroll aren't working together with an input touch. For example if I want to move my point it's the page which scroll and not my point wich move. It's not exactly the same bugs on firefox, IE and my Windows RT app.
You can see a little example here to test if you have an input touch, I guess tablet and smartphone will have the same behaviour than my PC with a touch screen.
I have the following css to simulate a bigger app:
body {
overflow:visible;
width: 2000px;
height: 2000px;
}
There is a way to do this?
I hope you understood my problem :)
I tested this on my phone and tried to research how to force a browser to stop scrolling with little success. The good news is your app allows a mobile user to place a new point really nicely.
To get the project done quick, you might need to create a set of controls that grabs an id of each existing point and allow the mobile user to move the desired point using buttons. The UI for such a set of controls could be minimal and intuitive if done well. You could set the UI to display:none and only show when the screen width/height is iPad size or less.
I finnaly found a solution with the pointer-events property in css
var C1 = document.getElementById("C1"),
evtIn = window.navigator.msPointerEnabled ? "MSPointerDown" : "touchstart",
evtOut = window.navigator.msPointerEnabled ? "MSPointerUp" : "touchend";
C1.addEventListener(evtIn, function () {
d3.select("#C1").style("pointer-events", "all");
d3.select("body").style("overflow", "hidden");
}, false);
C1.addEventListener(evtOut, function () {
d3.select("#C1").style("pointer-events", "none");
d3.select("body").style("overflow", "auto");
}, false);
On touch start I just allow pointer events in my chart et disable overflow and in the other way for the touch end.
My page didn't require a horizontal scroll bar initially, but now one appears mysteriously that is beyond any of the elements that are covered on inspect on Chrome and firebug. No elements pass that blue line so I'm not sure how to fix this.
I know I can hide the scrollbar with overflow-y:hidden, but that's not the point. It shouldn't be there at all.
EDIT Here's the jsfiddle: http://jsfiddle.net/S8RUp/
A bit messy, but I think it gets the point across.
The jsFiddle link has too many overflowing contents to be useful. What you can do to ease debugging is to use a bit of code like this to show you only elements that are over a threshold width:
// using jQuery - you can use other library or include it temporarily for debugging purposes
$('*').each(function() {
var w = parseInt($(this).width(), 10);
// you can put something larger than 700, depending on your situation
if (w > 700) {
console.log(w, this);
}
});
It will have a few false positives (the html node for example), but you'll probably find the culprit easily enough.