We Keep Coding

Weird scroll behavior in latest Blink-included browsers (like Chrome, Opera)

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.

Relative positioned div jitters while scrolling in Safari

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.

D3 Chord Example Hover Issue in IE11

I'm working through some examples of how to construct chord diagrams in D3 from a tutorial I found at http://www.delimited.io/blog/2013/12/8/chord-diagrams-in-d3
I'm looking at the first example, about hair colour preference. When you hover over a group around the edge of the circle, it shows only the chords related to that group, and when you move the mouse outside the circle again, all the other chords reappear.
This seems to be achieved by dynamically appending the css class "fade" to all the chords that are supposed to be hidden, and then the following piece of CSS handles hiding them all on hover.
#circle:hover path.fade {
display: none;
}
This works fine in Chrome, but when I try the same page in IE11, once you have hovered over one group, the remaining chords are never redrawn when you move the mouse outside the circle.
I fired up the debugger in IE11, and it seems that simply modifying one of the properties on the DOM whilst in the debugger resolves the issue - but I'm having trouble figuring out how I can achieve this in code.
I've created a fiddle here with all the details https://jsfiddle.net/49dym52r/
Thanks for any assistance.

I am able to reproduce the issue when viewing the delimited.io resource in Internet Explorer 11 on Windows 10. I am not, however, able to reproduce the issue in Microsoft Edge, which likely means the fix came in as part of additional web platform work done on EdgeHTML after the fork from Trident.
It's unlikely that we will be doing any feature-work on Internet Explorer, so your best option is going to be persuading Internet Explorer 11 into behaving more appropriately. This can sometimes be tricky, but after a couple of minutes in Telerik's Fiddler, I was able to resolve the problem in Internet Explorer 11 on my build of Windows 10 with the following addition:
div:hover { background: auto } // Or svg:hover, per the comments below
I added this to the top of the aforementioned delimited.io resource, and it appears to have resolved the issue for me. It's a bit heavy-handed, so you may want to adjust its scope if you find it causes you any issues.

Rendering bug in Google Chrome at certain window widths

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.

Three.JS - Scrolling issues in firefox

I am not sure if anyone else is having this problem or not with three.js. I have a simple demo of a cube that will spin with a varying rotational velocity (arrow keys, mouse, or touch input). Everything seems to work fantastic in the Chrome browser. At work I hopped on the iMac, the textures seem to be splicing and not mapped to my geometry correctly in Safari.
I moved over to the Firefox browser on the mac and everything works, and the frame rate is decent. It just seems that for some reason when the cube gets rotated at certain angles the renderer jumps and the onscreen hud moves up and you can't see the title at the top and the stats widget moves up from the bottom of the screen. It also seems that my cube's y position jumps up at the same time. I seem to have the same problem in android on some of the mobile browsers. I was wondering if anyone has had similar issues in Firefox (on Mac?) or in mobile browsers with the rendering suddenly jumping, moving the onscreen hud, etc
EDIT: I have figured out the problem. I still do not have an ideal solution. I created a copy of my demo and tried commenting out my keyboard handling code and to my surprise the issue still existed. Apparently firefox is scrolling the window slightly up and down and the keyboard handler included in the THREEx library does not disable the default behavior of the up and down arrow keys in Firefox. In chrome there is no room to scroll my window and I simply make my renderer the size of the window. I do not see why firefox is scrolling.

I experiment the same problems on Firefox in Mac on your example.
The jumps on the rendering are due the garbage collector (poorly implemented on Firefox). You are allocating memory on each "animate" function.
Instead of creating new Vector3/Matrix4 for your rotation, use global variables, so you just create those objects once.
Besides, instead of using KeyboardState, and executing those 'State' functions on each animate call, you should use a KeyboardListener, which will execute your code just when something changes (and not all the time).
You should take a look to this example: http://mrdoob.github.com/three.js/examples/canvas_geometry_cube.html

The problem was that for some reason in Firefox (not Chrome) there is room to scroll even though the renderer is set to the window size, so Firefox was scrolling when using the arrow keys. To fix this, I edited two functions in THREEx.KeyboardState.js adding a preventDefault() to prevent the arrow keys from scrolling.
Here are the needed edits:
this._onKeyDown = function(event){
event.preventDefault();
self._onKeyChange(event, true);
};
this._onKeyUp = function(event){
event.preventDefault();
self._onKeyChange(event, false);
};