Chrome does not redraw <div> after it is hidden

Question

I have some divs that show up on hover, and then are hidden. However, in Chrome (19.0.1084.56 m, Windows XP) when you unhover, Chrome doesn't redraw them as gone until you do something like scroll or resize the window.

http://jsfiddle.net/y7NdR/3/

I am aware that certain modifications to my CSS will fix the problem, e.g. removing the position or z-index and overflow properties, but I really don't want to do that--the JSfiddle is paired down from a full site where I need them.

Can anyone shed any light on exactly why this redraw problem is happening in Chrome? Does anyone have any tips to fix it without messing with the CSS that I need?

Wartburg

It isn't really a menu, but it is dropdown-style. – Wartburg

Just looks like the divs could be list items and use a similar drop down markup/style as for a menu. e.g. htmldog.com/articles/suckerfish/dropdowns. This also won't work in early versions of IE as the :hover selector will only work on anchors. This seems like something jQuery would be helpful using show() or hide() on hover. Not sure if you want to go that route though. – Envious

I can repro in the latest Chrome Canary. – Dichlorodifluoromethane

Thankfully I only need to support down to IE8, and technically don't need to support Chrome at all, but I'd prefer to make the site work in all modern browsers. The content of the dropdown is not necessarily a list, but if it was I'd mark it up like this. jQuery seems a little heavy for this, since its currently working in all browsers but Chrome using just 4 CSS rules, but I may consider re-working it from the ground up if the redraw issue can't be isolated. – Wartburg

Another Chrome bug related to this (in that the same fix works)... Horizonal artifact lines left on screen aften collapsing an overlay element. – Willwilla

Just for anyone else coming across this, the bug is still present in chrome 34 on the mac. Seems to work in every other browser (including other webkit engines i.e. safari). Thirtydot's fix does resolve the issue though. – Hypomania

Answer 1

Clearly, this is a WebKit bug.

I found that adding -webkit-transform: scale3d(1,1,1); fixes it:

http://jsfiddle.net/thirtydot/y7NdR/5/

I'm not sure if there are any downsides to this fix. I guess this works because inside WebKit, different code is used to render 3D transforms.

Dichlorodifluoromethane

Works perfectly, just the sort of trick I was hoping existed. Thanks! – Wartburg

@Wartburg - you should consider filing a bug (for the greater good). – Heartfelt

@JosephSilber: I actually found a similar bug before: bugs.webkit.org/show_bug.cgi?id=60047. Not sure why I didn't post it here. Brain fail. – Dichlorodifluoromethane

Great answer! After a day of banging my head on against the wall, this did the trick. Thank-you – Perloff

Funny how this works and not -webkit-transform: translate3d(0,0,0);. What is the world commming to, when Chrome is the new IE, that need hacks in order to work properly :( – Monomolecular

For me in OSX this fix messes with the scroll bars on the page. It makes them go beneath child components. z-index didn't help. – Polytonality

Answer 2

I struggled with this for a very long time, and while adding -webkit-transform: scale3d(1,1,1); did fix my issue, I wanted to find out WHY. So, I dug deeper into my code to try and narrow down my issue. I found that i was using a fade in animation, and inside this, I included in the same class:

-webkit-backface-visibility:hidden;
backface-visibility:hidden;

Remove these two lines alone, fixed my issue without the scale transform hack.

Seeing as backface visibility is to do with transforms, and should have no effect on 2D transforms, I removed it and it fixed my issues entirely.

There have been many bugs noted with backface visibility with chrome, so I posted this for any future people trying to find out a fix without too much work.

Cancellation