Chrome rendering issue with fixed element and overflow hidden - html

I have a fixed horizontal menu that works well on firefox but it's presenting a problem in SOME instances of chrome. When the user scrolls down a white block covers the menu.
You can see the problem here: http://brandca.co/cterranum/
We've inspected the elements but it doesn't appear to be anything in the code and looks more like a rendering issue.
We've noticed that when we erase the element's overflow:hidden the problem fixes but we need this property to toggle the menu.
We haven't been able to pinpoint exactly when it happens since it looks it only happens in some computers and even then, a computer in wich the site rendered correctly had the problem happened oduring a presentation on the projection screen.

The fixed element was somehow screwing webkit's rendering, so I turn the element to position: absolute and on the scroll event I update the top value so it looks like its fixed. It's not pretty but it works.

Element has "position: absolute;" and inside it there is .inner-header which has "position: fixed;".
Try moving ".inner-header" outside of ".header".

Related

In Safari, hovering over SVG elements causes a scrolled element to reset its scroll position?

I have a website that is exhibiting bizarre behavior that I don’t understand. I’m unable to tell if I’ve run into a bug or what I might be doing wrong.
The page has two elements, nav and main that each have overflow-y: scroll set. This is so they can be scrolled independently of one another. If I scroll the main element, and then hover over the pagination buttons at the bottom, the main element will jump back to the top (lose its scroll position). It also happens if I hover over the Octocat/GitHub symbol in the navigation on the right.
The common thread here is that the pagination buttons and the GitHub symbol on the right both have svg elements. If I get rid of the svg element the bug doesn’t happen. Also if I remove overflow-y: scroll from the main element the bug does not occur.
I’ve also noticed that the issue might be somehow related to having height: 100% set on the <html> tag. When it’s removed the issue no longer occurs, but unfortunately it can’t be removed otherwise the full width/height layout doesn’t work correctly.
Can anyone tell me why this is happening, if it’s a bug in Safari, and/or how to fix it? Thanks!
You can fix this by adding the following to body where your grid rules are defined. Sadly, I have no idea why this solves the issue.
body {
…
grid-auto-rows: 1fr;
}
After spending hours and hours on this, the only way I could figure out how to fix it was to switch from CSS grid to flexbox. 🤷🏼‍♂️
This is the diff that fixed it, if you’re curious.
This is a bug related to safari version 12.1, which is fixed in Safari Technological Preview.
https://bugs.webkit.org/show_bug.cgi?id=197189
However as a workaround in the mean time.
Can you try
overflow-x:hidden, overflow-y: scroll,
height between 50 to 95vh for the specific container depending on your surrounding elements. This is going to have minimal safari jump on hover and probably empty space at the bottom.
Even after Safari bug is fixed, seems that the bug still occurs on some other scenario. I successfully reproduced a similar behavior on Fluent UI dropdown: https://github.com/microsoft/fluentui/issues/23668
The workaround in my case was to change dropdown item height from "auto" to "100%".

scrolling is choppy in chrome when background image is fixed

I'm trying to create a parallax website. But then I have an issue with fixed positioning.
I have several sections , each with a background-attachment:fixed.
A position:fixed menu bar on the top with an hidden element in it on top of all sections.
A google map 100% with in one of the sections.
Now, the problem is when I scroll the page with animation in google chrome, the scrolling does not go smooth and it flashes several times while scrolling.
I do the scrolling with greensock scrollTo plugin , but that is not the problem as I also tested it with jquery .animate() method. Same result.
I did a research , and found out that chrome has a bug or problem with Fixed positioning ( and sometimes when you put hidden element in it )
Some pages suggested to use these two with the fixed elements :
-webkit-backface-visibility:hidden;
-webkit-transform: translateZ(0);
I added this to the fixed menu and some of the choppy behavior of it reduced , but still not smooth.
If I add this to the sections with background-attachment:fixed elements, the scrolling animation goes smooth but does not act as fixed anymore.
Somebodies says that chrome has problem with large images, some says it has issue with fixed position and somebodies had a solution that did not work for me :D
I uploaded the page :
http://www.FarzanMohajerani.com/test/parallax
just click anywhere on the page to scroll.
I also created a jsFiddle with the exact same code. But I don't know why it doesn't have the problem in jsFiddle :
http://jsfiddle.net/Farzanmc/cRqxT/5/
It would be great if anyone could direct me to the right solution or remind me if I'm doing anything wrong.
Thanks
This solved the issue for me:
-webkit-transform: translate3d(0,0,0);
Adding this rule turns the element into a layer in Chrome, which avoids repainting. In my unique situation the error was caused by browser re-painting.
I', having the same problem with Chrome at the moment and I narrowed down the cause to the following combination:
1) background: fixed;
2) transform: (any transform, even just putting scale(1), would instantly break it).
As long as an element that contains fixed background image doesn't have any "transform" on it, it works fine. But as soon as you even add "transform: scale(1);" which doesn't actually make any real transformation, it completely breaks the fixed background image. You can start scrolling, but it disappears. If it was outside of the screen, it will never appear at all, no matter how far you scroll.
So essentially, the problem is that Chrome at the moment can't handle fixed background images in transformed elements. No matter which level of descendent or ancestor we are talking about.
The thing is, this is pretty much an essential stuff that and I'm really hoping that it gets fixed as soon as possible, because it's extremely limiting. You can't disregard Chrome as if it's IE6.
And you can't apply "position: fixed;" on an "img" element, because it will be fixed to the first "transformed" ancestor, not to the real screen, since that's apparently how it's supposed to be treated, according to W3C. Although, some new value would be welcomed, some that can break all the way to the very window, and fixit to those coordinates.
I ran i to a same problem and fixed it this way:
I had to deal with fixed header on a website and anytime i would scroll with a mouse wheel the header would get choppy.... I had a display:none element in a header and as soon as i removed the element, header became fixed and steady, now it displays well no matter how fast i scroll.

Elements won't stand still in IE7

Okay so while testing a site in various browsers everything worked flawlessly except for internet explorer 7. My problem is pretty weird one: my menu elements won't stand still. What I mean by that is that when I scroll the screen down my menu elements travel with me but only the link parts of them (all background stuff remains at the top) and when I scroll back up the menu elements are nowhere to be seen. Is this a known bug in IE7?
I have some suspicions that the problem might lie in position attribute in css as I use position:relative and left/right:50% to center my menu elements.
Found an answer myself. Here it is for those who someday struggle with the same thing.
The culprit was as suspected position. For some reason the relative positioned elements were treated as fixed or somehow seperated from the page layout so it "hovered" over everything while scrolling. To remedy this is one should set the position of the container/wrapper of the page to relative. So here it is in code:
#container{position: relative}
Huge thanks for all comments for prodding me in the right direction.

Anchor link cutting off the page based on height of absolute positioned element

When clicking on an anchor link, it cuts off a portion of the page. Near as I can tell it occurs in all browsers.
http://jsfiddle.net/PJDWs/
If you go to that fiddle and click on the link at the top, you will notice that you are unable to scroll up to the top of the page. Effectively part of the page has been removed.
There are a couple things that cause it, but I don't know why they do. If you remove overflow: hidden from the .bodyContent then it does not exhibit this behavior. Also, you will notice that the distance of the cut off is exactly equal to the value of top: XXpx on .stuff. Thus setting top: 0px will fix the problem as well.
The issue is that for the specific design I'm working on, neither of these are options as the element needs to be positioned off the top and the parent needs overflow hidden. But more importantly, why is this occurring, and especially why does it occur across all browsers... it almost seems like it's by design.
If you remove the height:100%; and replace it with bottom:0; it will work because the height, with top and bottom set, is then defined by the enclosing container - it's an interesting bug but this workaround will get the job done.

IE6 displaying components in a hidden div (when they should be hidden!)

Does anyone know if IE6 ever misrenders pages with hidden divs? We currently have several divs which we display in the same space on the page, only showing one at a time and hiding all others.
The problem is that the hidden divs components (specifically option menus) sometimes show through. If the page is scrolled, removing the components from view, and then scrolled back down, the should-be-hidden components then disappear.
How do we fix this?
One hack you could use is to move your div outside the screen:
MyDiv.style.left = "-1000px";
And then put it back on its original position when you want to show it.
How are they hidden? using display:none; or visibility:hidden; ? are they absolutely positioned by any chance? IE6 has a z-Index problem and there are several hacks to deal with it.