I have a horizontally scrolling div with sections inside. I'm using Ariel Flesler's scrollTo plugin to scroll from one section to another.
Please see: http://jsfiddle.net/carienf/qZeEe/
The fiddle works perfectly in IE 9, Safari 5.1, Opera 11.5 and Chrome 14 (all the latest versions). I can click on a link to scroll to the corresponding section and scroll or mousewheel around in it.
Problem:
In Firefox 7 (and earlier), when I have scrolled to Section 2 or Section 3 and then scroll down using the scrollbar, my position is reset to the first section. This also happens when I resize the browser window. If I scroll using the mousewheel, Firefox behaves (in other words, I stay in the current section).
My question is pretty much an exact repeat of this question: Problem mixing overflow-x, FireFox, and Javascript
Only, the accepted answer (which is to allow the horizontal scrollbar to be visible) doesn't work for my specific case. Also, the guy who posted the question has removed his example. I really need that scrollbar to stay hidden and I really don't like the idea of hiding it behind a div.
Is there a way (other than setting overflow to "auto") to stop Firefox from resetting my scroll position? Or some other way to hide the scrollbar?
UPDATE: Updated Firefox to 8.0 (still a beta version) and then the behaviour is consistent with the other browsers.
I can see a couple of options.
clip off the scroll bar. Takes some measuring and you have to position absolutely.
Add a 2nd div outside that does the vertical scrolling. That breaks your code as it currently stands, but it does resolve the scrolling problem. jsfiddle.net/s2YFM
I just ran into the same exact issue. When my "modal window" pops up, I set html.noscroll { overflow: hidden }, which unfortunately causes the window to scroll-to-top.
Here's the only solution I could make work:
function RemoveScrollbar(html) {
var scrollTop = html.scrollTop;
html.addClass('noscroll');
html.scrollTop = scrollTop;
}
This is MooTools code, but super simple to convert to jQuery or other frameworks.
Related
Recently I've been working on building a tree-view component library for Angular, as ngx-tree.
Problem
Soon after I figured out how to implement a virtual-scroll feature for this library for performance with large data set, and got it to run properly in Firefox, I am trapped by a weird scrolling behavior in Blink-included browsers(like Chromium, Chrome, Opera).
Demo link
Here is the demo plunkr -- https://embed.plnkr.co/xMpmK5EBC46tDKpYFpw8 see Update #1 below
Situation
In Firefox, Edge and IE 11, my library with virtual scroll feature works in expectation with smooth scrolling.
However, in Chrome and Opera, when I scroll to some positions inside the tree-view, the position of the scrollbar(which is the scrollTop property of scroll area) jump up and down, causes a flickering tree-view and break down the virtual-scroll feature.
browser detail version
Chrome - 59.0.3071.115
Firefox - 54.0
Edge - 40.15063.0.0
other browsers
In China, there are some shelled browsers derived from Chromium project(like 360se, QQ browser, Sogou browser, UC browser) with older version of V8 and blink. And they don't have that weird scroll behavior.
Some Assumption
Is it caused by some optimization on the scroll implementation(like smooth scrolling) by the Chromium team?
Hope to get some guides!!! (≧﹏ ≦)
Update #1
Demo link update with event log: https://embed.plnkr.co/GpQBZsguhZZOQWWbZnqI/
One must test the scrolling before opening devtool to see the logs
I have to explain a little more how the virtual-scrolling works and what's causing the flickering.
First, see the design of Virtual Scrolling.
A key point of virtual scrolling is， we create a fake scroll area the same size as that area without virtual scrolling instrumented. So in an optimal situation, the scrollbar position of the scroll area ought not to change until some expected events trigger its changes. For scroll event, we update the view for every animation frame.
Within a height-fixed scrolling area, we assume a truth that the scrollTop property will not change with a large percentage, if we simulate the those unrendered elements' height properly(there could be a bit of deviation for the calculation accuracy) within an animation frame.
However, based on my observed results, the blink-series browsers seems to perform a different strategy to update the scrollTop of the scrollable element. Its timing to update the scrollTop is different than none-blink-series browsers. That all I've figured out so far.
Sample gifs
Here I made some gifs to show the output of Chrome, Firefox, and Edge.
Chrome
Firefox
Edge
You're pulling the library from the virtual-scroll-demo-branch branch:
'ngx-tree': 'https://rawgit.com/e-cloud/ngx-tree/virtual-scroll-demo-branch/src/lib',
That branch is 105 commits behind master. It incorrectly sets margin-top on one of the inner elements. This is fixed in newer versions.
Edit: The developer actually referenced this Stack Overflow question in their commit message.
In the following fiddle, there is significant jitter while scrolling. The jitter is noticed only in Safari on Mac, while Chrome and Firefox scrolls the page smoothly.
https://jsfiddle.net/saptarshi17/akxuLL9x/
The jitter is a result of applying parallax effect on the first paragraph. The parallax is implemented by dynamically calculating the top css property triggered by scroll events. I am noticing this on Mac OSX El Capitan, not sure about Windows.
So far, I tried:
Added a mousewheel event-listener in addition to scroll as per this accepted answer on SO.
Tried wrapping the css("top", ...) function call within requestAnimationFrame()
Changed div from relative to absolute to avoid costly reflows.
Added preserve3d property to "hardware accelerate" position calculation as per some comments somewhere on SO.
Since 2 and 3 haven't helped, I assume the core issue has much to do with Safari's scroll implementation and less about frame-rate optimizations. There is a delay Safari's predictive rendering and the subsequent handler call which offsets the position. This results in 2 renders causing the jitter. While I understand Safari's intention behind the first render which works in most cases, this seems to be wrong in cases when the developer wants to override positioning. Maybe there is a way to tell Safari to disable the predictive rendering.
Page scrolling using the keyboard (PgUp/PgDown, Space) sometimes gets difficult if there are elements with fixed positions at the top of the page, e.g. navigation bars: content that was not visible at the bottom of the viewport might be hidden by the fixed elements after scrolling.
How to address this problem? Do browsers calculate, how far they should scroll? I observed different behaviors for different browsers and also for the same browsers on different pages (for example, Firefox leaves about 80px of old content on http://www.sueddeutsche.de/, but far less on http://www.taz.de. Chromium leaves much more content.).
Is this a problem at all, i.e. does anybody beside me use the keyboard to scroll a web page? Do you know any statistics?
To illustrate the problem, I created a Fiddle:
https://jsfiddle.net/x7hj8c4m/
Try to scroll the content using Space on Firefox. The fixed element will cover text that was not yet visible before scrolling. If you add left: 0, it works.
Very interesting observation.
Firstly, pressing space is equivalent to pressing PgDn. And when PgDn is pressed, the page should scroll vertically by roughly "one page's worth of px". As shown by the OP's fiddle, Firefox in particular calculates this value differently, depending on whether it detects a fixed header.
From my own tests on IE, Chrome, Firefox, I deduced that:
Without a position: fixed element, Chrome and IE scroll down by ~87.5% of the document height; Firefox scrolls down by document height - scrollbar height - ~20px.
With a position: fixed; width: 100% element at the top-left of the screen, Firefox intelligently understands that the element perceptually reduces the document height, and so applies: document height - scrollbar height - fixed element height - ~20px. The condition appears to be quite specific: the element must be fixed exactly at the top-left of the document's box model with full width in order for it to work. The other browsers (Chrome, IE) don't perform such compensation, and performs the standard 87.5% scroll.
I don't know if this is relevant, but it might have something to do with support for position: sticky.
Scrolling by keyboard is a pretty basic behaviour that probably doesn't interact too much (if at all) with the DOM, so expecting it to account for fixed elements is probably too much. There seem to be browser-specific predefined increments (I have no idea if or how they can be customized), but note that the increments are usually smaller (presumably small enough) when you use the up/down arrow keys.
I'm looking to recreate the vertical scrolling from this page: http://www.apple.com/iphone-5s/
Is there a library that will implement this (with jquery is ok). Particularly, I want to override the mouse wheel and keyboard so that scrolling down will smoothly jump to the next section and scrolling up will smoothly jump to the previous section.
OnePageScroll may be what you're looking for: http://www.onextrapixel.com/2013/09/18/onepagescroll-js-creating-an-apples-iphone-5s-website/
You can also look at fullPage.js, simple but quite powerful. You can even link it with a menu and use landscape scrolling too. Also, it works in IE8 and IE9 not like onePageScroll which only works with IE 10 and modern browsers.
Demo
Website
You can use something like http://github.com/stephband/jparallax.
also try http://ianlunn.co.uk/plugins/jquery-parallax/
I have a container on a page, which has has a huge overflow-x. On a iPad, the user can simple swipe-scroll left, just like they would do vertically when scrolling down the page.
On a PC, scrollbars are visible so the user can scroll left and right.
However, on the Android, no scroll bars appear and I can't swipe left like I can on the iPad.
Is some special CSS and JS needed here? Does anyone know why this happens?
The overflow property is not working properly in Android devices before Android 3.0. But it is solved from the Android 3.0 or later.
I also had this issue while I was developing an application.
This issue was solved by using a button and animating the element's margin-top property so that it is changed to negative value, therefore creating a scroll effect.