I have HTML page which contains a lot of sections. Content of these sections is loaded lazily. After page load, user is scrolled to some particular section. Then content above and below the section is loaded and inserted. Obviously inserting content above changes scroll position so I need to maintain scroll position relatively to the current section.
I have implemented the simplest solution which works perfectly in Chrome, FF, Edge and even IE11 but in Safari - it has glitches.
Here is the code:
function insertElementAbove() {
var elem;
// load elem
var prevOffset = window.pageYOffset;
// insert element
container.insertBefore(elem, container.firstChild);
// measure inserter element height and adjust scroll pos
var elemHeight = elem.offsetHeight;
window.scrollTo(0, prevOffset + elemHeight);
}
I assume that the last 4 lines are run synchronously so according to the browser rendering pipeline no repaint can be done in between:
But in Safari it seems that sometimes paint and composite happens before changing scroll. Why only Safari behaves like this? Can it be because of Safari use IOSurface framework (https://apple.stackexchange.com/a/56820)? Are there any ways to solve/workaround this behavior?
Here is plunkr.
The issue is not reproducible in iframe mode so go to the "Preview in separate window" using button in the top-right corner:
Safari: Version 10.0.1 (12602.2.14.0.7)
macOS Sierra: Version 10.12.1
Related
I'm using SlickGrid.js library and it is excellent!
Only major problem right now is with Internet Explorer (confirmed in 9, 10, and 11), but the standards compliant browsers like Chrome and FF work fine.
Problem: When grid is scrolled and then hidden and then re-shown in IE the scroll position is reset to top of grid, and the viewport/data is either cut off or completely hidden (depending on scroll amount).
Here is a fiddle that demonstrates the SlickGrid.js IE bug (using the author's simple example 1):
http://jsfiddle.net/crwxoc17/1/
Anybody have a generic fix for this or patch to slick grid?
I can call grid.resizeCanvas() to sorta fix the issue, but it resets scrollbar to top and it's very annoying to do this for every single grid just to deal with Internet Explorer.
Semi-working fix, but still screws up the scrolltop:
function onShowGrid1() { grid.resizeCanvas(); }
(Reviewing JS code now, but I have not yet confirmed whether the bug is Microsoft's or SlickGrid's)
This issue applies to any element in IE with overflow set to scroll or auto and whose visibility is toggled. There's a simple example here: https://jsfiddle.net/qkhxL6r8/4/
That said, if you'd like the scrollTop position to be preserved you could extend SlickGrid or create a wrapper a class that subscribes to the onScroll event, records the scrollTop value, and sets it on the viewport element when showing or hiding the grid. I modified your example code as a proof of concept here: http://jsfiddle.net/h9cu2cmp/4/
var lastScrollTop;
var scrollTimeout;
function updateScrollTop(e, args){
clearTimeout(scrollTimeout);
scrollTimeout = setTimeout(function(){
lastScrollTop = args.scrollTop;
}, 30);
}
//...
grid.onScroll.subscribe(updateScrollTop);
$('body').on('click', '.toggle-button', function(){
$("#myGrid").toggle();
if(lastScrollTop !== undefined){
$("#myGrid").find('.slick-viewport').get(0).scrollTop = lastScrollTop;
}
});
If you're using a remote data provider you can trigger ensureData for the updated scrollTop with grid.onViewportChanged.notify()
Situation:
Suppose we are reading the content somewhere down the page that is built to be responsive. Suppose also that we resize the browser window to a smaller size and that some content above get extended down due to the thinner width, hence making the whole page longer. Then as we resize, whatever content we are looking at will get pushed down the page accordingly.
Example:
Suppose we were to look at the Helper classes section in this page. Then shrinking/expanding the window a sufficient amount moves the bit we were reading down/up the current view.
Prompt:
Is there any way we can fix this? I.e. maintain our current view of the page regardless of what happens to the contents above it when we resize the window.
Thoughts:
I am thinking that we could at least start with javascript and put an event on window resize. Then automatically scroll the page to the top-most element that was in our view on event fire. I don't know how this will affect the performance, however, especially in bigger pages.
There's also the problem of refering to the top-most element in current view. The top of our current view might be cutting off the top portion of some elements, not to mention that there's usually more than 1 element layered on top of one another at any point within the page. The notion of top-most element I've mentioned is not very well-defined :(
Also rather than a problem of responsive design in general, instead it seems to me like this is a problem with the default scrolling behaviour of web browsers? Or perhaps I am missing some circumstances where the current behaviour is desirable.
Edit 2 4
Updated fiddle (see fullscreen result) based on Rick Hitchcock's solution's solution.
With jQuery:
//onresize:
var scrollAmount;
if (topNode.getBoundingClientRect().top >= 0) {
scrollAmount = $(topNode).offset().top - topNode.getBoundingClientRect().top;
} else {
scrollAmount = $(topNode.offset().bottom - topNode.getBoundingClientRect().bottom;
}
$(window).scrollTop(scrollAmount);
The fiddle is acting a bit weird even in the same browsers, I've uploaded the same script using a free hosting here.
Still need to incorporate the IE, Opera and Safari fix for elementFromPoint.
Edit 3
Thanks for all the help, Rick Hitchcock. Welcome to stackoverflow, by the way :)
The discussion is turning into cross-browser compatibility issues so I've accepted your answer since we've pretty much got the answer to the original question. I'll still be fixing up my implementation though. The focus being cross-browser issues, topNode criteria, and topNode cut-off handling.
An edge case
While playing around with it, I noticed that when we were at the bottom of the page in a small viewport, then switch to a larger viewport (let us assume now that some more elements that were originally above the element we saw now came into view due to shorter container from wider viewport) the window cannot always lock the topNode to the top of the viewport in such a case since we've reached the scroll bottom. But then switching back to the small viewport now uses a new topNode that got into the viewport during the switch.
Although this should be expected from the behaviour being implemented, it is still a weird side-effect on scroll bottom.
I will also be looking into this in due course. Initially, I am thinking of simply adding a check for scroll bottom before we update topNode. I.e. to keep the old topNode when we've reached scroll bottom until we've scrolled up again. Not sure how this will turn out yet. I'll make sure to see how Opera handle this as well.
Here's what I've come up with:
(function(){
var topNode;
window.onscroll=function() {
var timer;
(function(){
clearTimeout(timer);
timer= setTimeout(
function() {
var testNode;
topNode= null;
for(var x = 0 ; x < document.body.offsetWidth ; x++) {
testNode= document.elementFromPoint(x,2);
if(!topNode || testNode.offsetTop>topNode.offsetTop) {
topNode = testNode;
}
}
},
100
)
}
)();
}
window.onresize=function() {
var timer;
(function(){
clearTimeout(timer);
if(topNode) {
timer= setTimeout(function(){topNode.scrollIntoView(true)},10);
}
}
)();
}
}
)();
If there were a window.onbeforeresize() function, this would be more straightforward.
Note that this doesn't take into account the scrolled position of the element's textNode. We could handle that if only the height of the window were resized. But resizing the width would generally cause reformatting.
This works in Chrome, Firefox, IE, and Safari.
Edit
How it works
The code's closures make variables private, and the timers prevent the code from running constantly during scrolling/resizing. But both tend to obfuscate the code, so here's another version, which may aid in understanding. Note that the onscroll timer is required in IE, because elementFromPoint returns null when it used in onscroll event.
var topNode;
window.onscroll=function() {
setTimeout(
function() {
var testNode;
topNode= null;
for(var x = 0 ; x < document.body.offsetWidth ; x++) {
testNode= document.elementFromPoint(x,2);
if(!topNode || testNode.offsetTop>topNode.offsetTop) {
topNode = testNode;
}
}
},
100
)
}
window.onresize=function() {
if(topNode) {
topNode.scrollIntoView(true)
}
}
topNode maintains the screen's top-most element as the window scrolls.
The function scans the screen left to right, along the 3rd row: document.elementFromPoint(x,2)*
It doesn't scan along the 1st row, because when IE does scrollIntoView, it pushes the element down a couple pixels, making the top-most screen element the previous element. (Figured this out through trial and error.)
When the window is resized, it simply positions topNode at the top of the screen.
[*Originally, onscroll scanned left to right along the 11th row (in pixels) until it found an element with just one child. The child would often be a textNode, but that wouldn't always be the case. Example:
<div><ul><li>...<li>...<li>...</ul></div>
The div has only one child – the ul. If the window were scrolled to the 50th li, scanning left to right would incorrectly return the div due to the inherent padding of lis.
The original code has been updated.
]
I have a script that monitors scrolling and takes control of the scrolling to animate the page based on certain parameters. To do this, it calls window.scrollTo(0, currentScrollTop); which perfectly interrupts the smooth scrolling in Firefox on Windows. I can then animate the page scroll to the place where I want it.
Unfortunately, this trick doesn't appear to work in browsers in MacOS which results in a broken experience as JavaScript and the browser compete to scroll the window.
Is there a cross-browser way to stop smooth scrolling with JavaScript?
Site using effect in question: http://capitalismis.com
Relevant (simplified) code:
$doc.on('scroll', function(e)
{
$doc.off('scroll');
window.scrollTo(0, $doc.scrollTop());
var aniSpeed = 1500 * Math.abs(scrollTop - selected.top) / windowHeight;
$body
.stop()
.animate({scrollTop: selected.top}, aniSpeed, 'easeOutQuad');
}
);
In short: don't try to override native scrolling. Every OS and device handles things differently and it's impossible to predict the different scenarios. There is "hard scrolling" (most Windows versions), "soft scrolling" (≈Mac OS X 10.6+) and browsers that only fire the onscroll event when the scrolling is completely done (iOS). It's a mess.
Instead of trying to modify the scrolling behavior of the body, I would modify the elements of the page accordingly. Listen to the onscroll-event, and move things around on the web page.
// Capture scroll event
$(window).scroll( function() {
// Get scroll offset from top
var scrollTop = $(window).scrollTop();
// Use it to move elements around on the page (or change backgrounds etc.)
// Here: move .element in the opposite direction of the scroll
$('.element').css({
'-vendor-transform' : 'translate3d(' + (scrollTop*(-1)) + 'px,0,0)'
});
});
I have a content slideshow:
slide container
|--> wrapper
|------> slide1, slide2, etc.
that works as simple as calculating wrapper's position X and slide's position X to determine where to slide the wrapper for the next/previous slide to show up within container's viewport. It's pretty straight forward.
For Firefox and Chrome I am using CSS3 transform and transition-duration to animate the slides. Everything works perfect. Almost.
The problem is only when I click next button very fast. I am using jQuery's
$(selector).position().left
to read the slide's position X (left) and position becomes 0 (instead of expected, say, 300px). I do have a flag isAnimating to prevent users from going too fast but that does not help either. It does prevent from scrolling content too fast but position left may still be 0 as if something else is causing it to fail to determine.
I did a brief search and discovered that if it was image being loaded, some browsers would fail to determine its position until loading is over. However, each slide has an image but inside of it. The slide's CSS seems to have all widths and margins set fine.
The question is why may this be happening based on the scenario I described and possibly what can be improved to determine position X at all times for Firefox, Chrome browsers?
I've decided that if offsetLeft is not reliable for me at all times, I could use width of an element and its index position within container to figure out position X
var newWrapperPos = undefined;
$(lotWrapper).children('div').each(function(index){
if($(this).attr("id") === "slot"+id){
var width = $(this).width();
newWrapperPos = index * width;
return false;
}
});
//now I can shift wrapper to position = newWrapperPos
Sorry I couldn't share the code - it is a bit time consuming to rip off all pieces of functionality involved. But if somebody has a better answer, let me know. For now this works fine for me.
I am working on a website for a client, and we have the following requirements:
When the browser width is greater than 960px don't show a scroll bar.
When the content is wider than the browser but the browser width is greater than 960 don't show the scroll bar
If the browser is 960px don't show the scroll bar when it is needed.
I have the following javascript that works perfectly under ie, chrome, safari and opera, but dies in FF by forcing the page to "reload" client side (it redraws all elements).
function sizeHandler(myWidth) {
if (myWidth > 960)
document.documentElement.style.overflowX = 'hidden';
else
document.documentElement.style.overflowX = 'auto';
}
Because everyone seems to question the content, here is the HTML:
<body>
<div id="flashContent">
<object...>
</object>
</div>
</body>
<script...>$(document).ready(sizeHandler(getWidth()));</script>
Ignore getWidth(), it works, but I don't feel like adding another 15 lines to this ;). The object tag is a flash object.
Try it with document.body instead of document.documentElement. Setting CSS properties on the HTML element can give unexpected quirks.