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.
Related
I am trying to implement a chat application, more precisely a scroll behavior for chat application. I think it's best described with a gif.
https://i.imgur.com/NnpMeOx.gif
As you can see, I want to support a few key features:
Scrolling is reversed so on page load, the messages start on the bottom along with the scrollbar
Chat is scrolled to the bottom when user types in a message. (this is easy, no need to pay attention to this part)
If new messages appears (pushed by websocket in real life) it shouldn't disrupt the existing scroll position, unless it's already at the bottom. Then it should scroll to reveal the message automatically.
So far I've implemented 2 solutions:
a) Display flex and flex-direction column-reverse on the scrollable element. This works beautifully out of a box, but only on chrome :( IE (and Edge) as well as firefox just ignores this totally. NOT A GOOD SOLUTION
b) I flipped the container with transform: scaleY(-1) then I reversed the messages and fliped every one of those with the same transform. The main obvious problem here is the scroll (mouse wheel and arrows) is reversed. I sort of fixed it, didn't manage smooth scroll (sucks) but yet again, Edge (and probably IE) just shows scrollbar as disabled. NOT A GOOD SOLUTION
I am really hoping to find somebody who can point me in the right direction because so far, my efforts while logically ok totally failed browser compatibility.
The code is on https://github.com/PeterKottas/react-bell-chat, it's react but tbh, that doesn't matter much as this seems more like a general web dev exercise.
P.S.: I can't use jQuery, hope that's fair. So either css or plain javascript. Like I've said, this doesn't have much to do with react
Well I got no replies and managed to fix it myself so I'll accept this in case it helps somebody in the future.
3rd and final solution:
I kept the direction of scrolling and didn't do any reversing at all. Instead I hooked into onScroll and wheel event, created a few callbacks and managed to mimic the behavior perfectly. You can find more details in the code on https://github.com/PeterKottas/react-bell-chat.
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.
Ever since FF 52 was introduced, I am having the same lagging issues when executing on scroll events, especially when using the mouse wheel - the same thing occurs on IE Edge as well, but it was considered a minority, now with the addition of FF some kind of a solution has to be found.
I have created a fiddle online that replicates the problem - the issue is visible on FF and IE edge, while it works smoothly across webkit browsers.
Here is the simple scroll function I am using:
$('.scrollable').on('scroll', function() {
scrollY = $(this).scrollTop();
$(this).find('td:first-child span').attr('style', 'transform:translateY(' + -scrollY + 'px)');
})
https://jsfiddle.net/nfmLa7mn/3/
If you scroll with the mouse wheel the issue is more visible. It's a small lag but it's there. In more complex layouts the issue is more pronounced.
Am I the only one bothered by this? I haven't seen any other similar topics online. Is there any way I am not aware of that can fire scroll events in a better way? Or is there any other way around this issue?
Maybe this is due to the fact that Firefox handles scroll asynchronously.
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Scroll-linked_effects
Often scrolling effects are implemented by listening for the scroll event and then updating elements on the page in some way (usually the CSS position or transform property.) [...]
These effects work well in browsers where the scrolling is done synchronously on the browser's main thread. However, most browsers now support some sort of asynchronous scrolling in order to provide a consistent 60 frames per second experience to the user. In the asynchronous scrolling model, the visual scroll position is updated in the compositor thread and is visible to the user before the scroll event is updated in the DOM and fired on the main thread. This means that the effects implemented will lag a little bit behind what the user sees the scroll position to be. This can cause the effect to be laggy, janky, or jittery — in short, something we want to avoid.
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I've created a website with a parallax street scene. See here for an archived version.
It works just fine on all major desktop browsers, and Safari Mobile. It works fine in Mobile Firefox and Chrome for Android Beta also. However the default Android browser has issues with the scroll event. Let me be clear. Scrolling is not the issue. The div scrolls as required. The scroll event doesn't fire. This issue I experience on Honeycomb as well as ICS.
I'm not concerned about other mobile browsers because for mobile screen sizes one usually does not see the parallax scene; mediaqueries and conditional JavaScript loading take care of that. Responsive design and all that jazz.
Basically, I've written a parallise() jQuery plugin that positions each image based on its position and 'depth'. This function is bound to the scroll event.
On Android Browser, this event only fires at the start of the next touch, instead of continuously.
OK, so I thought that perhaps if I bound the function to touchstart, touchmove, and touchend events I would solve my issue. No cigar. Other touch events are also bugged. Applying the suggested workaround causes the events to fire, but as I have to e.preventDefault(), scrolling (the whole point of the exercise) is disabled.
What if I just poll the position of the stage div relative to the window div? Turns out that the position information is only updated at the start of the next touch.
I am at the end of my tether. Any help would be much appreciated.
Even if the touch events worked correctly on the bugged versions of Android, and you were then effectively able to track the native scroll position during a drag, this would be prone to error. For example, it wouldn't account for the momentum animation which happens after the touching has finished.
iOS and Android make sacrifices to improve the performance of scrolling. On both platforms, it's not possible to get the accurate scroll position until the scroll has completed. The scroll event (on the <body>) doesn't fire until the momentum animation is finished. So while your original question is about scroll events on an overflowing <div>, fixing this might not be totally helpful for you anyway.
If you want an animation to update in time with the scroll, then you need to perform the scroll programatically rather than using the browser's native scroll. The best library to do this is iScroll. You can achieve parallax effects very easily as seen in this demo.
If you need more complex effects (the walking character, in your example), you can opt for the "probe" version of iScroll which allows pixel-perfect polling of scroll position in return for reduced performance.
However, there are many downsides to using iScroll:
You may need to change your markup and styling
It is unnecessary overhead for desktop browsers, but due to markup changes may be difficult to use only as a fallback
The scrolling will not feel perfect - on iOS, with its usually excellent scrolling performance - the slight difference in momentum calculation can feel jarring. On Android, the scrolling can become more laggy than usual.
Swipe shim that doesn't need preventdefault on touchstart: https://github.com/TNT-RoX/android-swipe-shim