Firefox & CSS3: using overflow: hidden and box-shadow

Asked 26/2, 2010 at 18:52 Answered 16/2, 2012 at 8:18

I'm not sure whether this bug applies to Firefox only or also to WebKit-based browsers, but it's really, really annoying.

I've got a template/framework for my CMS interface, using box-shadow on a few elements with a width of 100%. Since this causes shadow on the right side of the element, a scroll bar appears. To hide the ugly scrollbar, I set "overflow: hidden" on the body element and on the wrapper div.

This causes some strange behaviour. Though there aren't any scrollbars, the page still scrolls to the right when I scroll using my touchpad (horizontal scroll). I've tried a hell of a lot and googled my ass off, but I can't seem to find a solution for this..

Anyone know a problem solver? or is this just an example of conflicting implementation of css3 box-shadow?

Ernestinaernestine answered 26/2, 2010 at 18:52 Comment(1)

Gah, I did not mean to upvote Otto's broken link. – Roundabout 1/3, 2011 at 9:18

I just had this issue with a design I was working on. Basically, Firefox creates a scrollable area for any shadow that extends past the right edge of the page. For whatever reason, Firefox doesn't create scrollable area if the shadow extends to the left. So my simple solution is to move the shadow completely to the left.

Problematic Code:

-moz-box-shadow: 5px 5px 5px #000;

Simple solution:

-moz-box-shadow: -5px 5px 5px #000;

I tried setting the x-offset to 0px, but since the blur is 5, there was still a scrollable area about 2-3px wide.

Merwin answered 11/8, 2010 at 19:2 Comment(1)

+1, this definitely works for eliminating the scrollbar. Unfortunately, with a blur of 20px, you have to move the shadow far enough that the gap on the right is pretty noticeable, but hey, it's better than no shadow at all, I guess. – Expiatory 9/12, 2010 at 16:17

Since I'm dealing with the same annoying issue, I'll go ahead and chime in here to say that this is definitely a shitty feature (if indeed it should be referred to as a feature). To have a box shadow cause a scroll bar is useless, though I'd be happy to eat my words if someone could give me a really good reason that it should be like that.

I think the answer here is just rendering the page a little different and letting firefox users miss out on the box shadow. Easy enough if you just don't declare -moz-box-shadow.

Constantan answered 15/6, 2010 at 13:38 Comment(1)

Totally agree with you. Shadow should never cause scrollbars to appear. This is not the case with WebKit, it's only a Moz issue. – Chronister 25/6, 2010 at 23:44

Skip to second paragraph for actual solution.

Depending on your needs my issue and solution I found for myself might satisfy your needs. I found that my issue was quite similar, no scrollbar when body { overflow: hidden; }, reason being, I believe, that the html and body elements' sizes are actually dictated by the size of the browser window's viewable area.

solution: If you only issue is the overflow off the x-axis, you can do body{ overflow-x: hidden; }, then using javascript or media queries you can easily change the properties applied to the body element and change it back to whatever you please.

example:

body { overflow-x: hidden; }

@media screen and (min-width: 1200px) {
    body { overflow-x: visible; }
}

hope this helps.

Superb answered 16/2, 2012 at 8:18 Comment(0)

First, be careful when pointing to somebody else's thing as the cause of your problems. Think to yourself which is more likely, that the issue is with the piece of code used by 200k users and 20k developers on a daily basis, or that it's in the thing used by you, for 4 hours now.

That said, your next step should be to reduce this down to a simple test page that contains just enough HTML to demonstrate the behavior. In your case, that would be a page like this:

<html>
  <body style="overflow:hidden;">
    <div style="box-shadow:whatever;">
      This should cause scrollbars to show
    </div>
  </body>
</html>

One of two things will happen:

Either the problem won't appear, in which case you get to slowly add back the other things on your real-life page until you find out what was actually causing the issue.

Or the problem will still be there, in which case you can report back to us here. You will also then be able to file a bug report with the Mozilla folks.

Good luck!

Humic answered 26/2, 2010 at 19:12 Comment(1)

I tried that, but the behaviour didn't change. I must note that there are no scrollbars, it just scrolls - a bit like on the iphone.. (when you have a list and scroll up, you can scroll up further then the height of the list) – Ernestinaernestine 28/2, 2010 at 12:50

While it might be frustrating to hear, that's not a bug, it really is a feature. If there's a scrollbar/scrollable area, and the area is activated and an arrow or other input device is firing, the area will scroll.

To counteract this you could try to fight each possible user input (touchpad scrolling, arrow keys, highlight-and-drag) with javascript, but the best answer for you is to rethink how you're using CSS here. Try using width:auto instead of width:100%, for instance.

To demonstrate (update):

CSS:

#parent { width:50px; height:20px;overflow:hidden; }
#overflow { width:50px;height:50px;overflow:auto; }

HTML:

<div id="parent">
    <div id="overflow">blahaahhahahahahahahahahahahaaaaaaaaaaahahahahahaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhahhaahahaha</div>
</div>

Jack the height on #parent up to 50px and you see the scrollbar still--soo it's just covered up; the content isn't hidden irretrievably. Set overflow:hidden on #overflow, and no scroll bars.

Dragonet answered 28/2, 2010 at 9:51 Comment(6)

Do you mean to say that the browser takes 'scroll-input' (any way to scroll) even when overflow is set to hidden? meaning that (sounds logical, if I think about it now) everything 'off the page' is not visible but still usable? (although you could question the usability) – Ernestinaernestine 28/2, 2010 at 12:51

Yes, essentially, though I should stop answering when I'm this tired. I understood you to be saying that you're covering up a scrollbar that exists in one div with overflow:hidden on a parent. If that's the case, then yes--if overflow:hidden is on the element with excess content, though, it does not scroll, it just crops it. – Dragonet 28/2, 2010 at 13:4

Check out the updated code example I gave. The code's probably clearer than I am. :) – Dragonet 28/2, 2010 at 13:16

Thing is, the element it self also has overflow:hidden set, so it shouldn't scroll, should it? Although I'm happy that the scrollbars arend't there, the fact that users (with horizontal scrolling input devices) still can actually scroll the page, is 'bad' for the user experience on my CMS – Ernestinaernestine 4/3, 2010 at 14:58

Yes, it is bad for users, but this is why it's happening. So the takeaway is that it's not a bug, it's working according to the rules, and if you want to make it so the page doesn't scroll horizontally, you'll have to reduce the element's width to compensate for the box shadow. – Dragonet 4/3, 2010 at 22:38

Also, scrollbars do indicate that something is being stretched. If you want to get rid of the scrolling, you'll have to find that something and set it to overflow:hidden--but then you might chop off what you need to show, which is what I think started this whole thing, right? So my suggestion is to adjust width and margins according to the box shadow. (I didn't mean to suggest covering up the scrollbars was a fix--it's just a diagnosis.) – Dragonet 4/3, 2010 at 22:41

I don't know your site's layout, but on mine I only ever want vertical scrolling, and not horizontal. That serves as part the basis as to why the box-shadow causing horizontal scrolling is undesirable for me, since my site's CSS in now way is build for layouts sprawling horizontally beyond the viewport.

I was able to fix it in Firefox 3.6 (that's all I tested) and tested it cross-browser to Google Chrome 8.0.552.327 and IE 8 with the following CSS rule on my body element:

body{
  overflow-x: hidden;
}

Gablet answered 4/2, 2011 at 17:57 Comment(0)

You can use the spread radius (the 4th length) to make the shadow's size smaller than the element's size and then a large y offset to let it show beneath the element. Something like box-shadow: 0 10px 10px -5px black; (of course I don't know what values you need since you didn't provide a fiddle, you need to play around with them in the dev tools). Keep in mind that the spread radius causes the shadow to expand/contract from all sides. So, for example, a spread radius of -1px will actually make the shadow 2px narrower.

Doradorado answered 9/2, 2011 at 19:2 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags