views:

860

answers:

4

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?

A: 

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!

Jason Kester
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)
Fabdrol
A: 

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.

D_N
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)
Fabdrol
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.
D_N
Check out the updated code example I gave. The code's probably clearer than I am. :)
D_N
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
Fabdrol
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.
D_N
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.)
D_N
+3  A: 

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.

erskingardner
Totally agree with you. Shadow should never cause scrollbars to appear. This is not the case with WebKit, it's only a Moz issue.
Elie
+2  A: 

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.

Josiah Sprague