User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20090730 SUSE/3.5.2-1.1 Firefox/3.5.2 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20090730 SUSE/3.5.2-1.1 Firefox/3.5.2 Using any GTK2 theme which does not display scrollbar buttons, some scrollbars in Firefox are not displayed. Reproducible: Always Steps to Reproduce: insert the following lines into gtkrc: GtkScrollbar::has-backward-stepper=0 GtkScrollbar::has-forward-stepper=0 GtkScrollbar::has-secondary-backward-stepper=0 GtkScrollbar::has-secondary-forward-stepper=0 1) Load a website which does not require a horizontal scrollbar, or any large picture. 2) Resize the browser window or zoom into the picture. Actual Results: No horizontal scrollbar appears. Expected Results: A horizontal scrollbar should appear. Also there is never a vertical scrollbar in the "Tools -> Add-ons" window. Scrolling with keyboard or mouse wheel works, nevertheless.
Still a problem in Firefox 3.6 ... I like to use the excellent QtCurve theme without scrollbar buttons ... but Firefox somewhat diminishes the otherwise perfect experience.
Also present in 4.0rc1. Marking as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I originally observed this with the "customize toolbars" dialog, which doesn't show a scrollbar if the theme has no steppers. Per comment 0, I checked various webpages which should show a horizontal scrollbar if the browser window becomes too narrow, and observed that the horizontal scrollbar does not appear if the theme has no steppers.
Still present in 4.0 final. Also, the scrollbar in the location bar dropdown disappears as well.
Still present in 5.0a2.
Assignee: nobody → ventnor.bugzilla
I'm currently trying to look for anything suspicious in xul:scrollbar in DOM inspector. I have a feeling this may be theme-related.
OK, so that's not correct, and may be something more sinister, specifically in nsSliderFrame. When the child thumb box of an nsSliderFrame goes through layout (in DoLayout), sometimes the height of the thumb is set to 0. Because there are no buttons to affect the intrinsic height, the height of the scrollbar overall becomes 0. My internal testcase of a XUL horizontal scrollbar doesn't reproduce this, because the height of the thumb is set correctly. So my next mission is to figure out where the code for the nsSliderFrame's child frame is located...
OK, I think I got this figured out. The slider is a flex box, and flex only seems to pay attention to the width of its children. Setting min-height CSS on the xul:slider fixed this bug. This isn't an issue with scrollbars with buttons because the buttons have a minimum height, whereas the slider doesn't (it's child thumb does, but apparently we don't look that far down).
Attachment #531252 - Flags: review?(roc)
Comment on attachment 531252 [details] [diff] [review] Patch Review of attachment 531252 [details] [diff] [review]: -----------------------------------------------------------------
Attachment #531252 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Comment on attachment 531252 [details] [diff] [review] Patch I'd like to see this in 5.0 given that this bug gives a bad experience for some themes.
Attachment #531252 - Flags: approval-mozilla-aurora?
Comment on attachment 531252 [details] [diff] [review] Patch Five is nearly beta and we're done taking "likes" and "nice to haves". We'll make people happy in Firefox 6.
Attachment #531252 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
So I spent most of the day trying to find a "better" solution. Ultimately, since this bug doesn't affect vertical scrollbars, but including them causes reftest failures, I decided to only apply the fix to horizontal scrollbars. Reftests pass.
I hope the above patch doesn't seem hacky, but it's the only thing I could think of after struggling to figure out the reftest failure.
(In reply to comment #14) > Ultimately, since this bug doesn't affect vertical scrollbars, but including > them causes reftest failures, I decided to only apply the fix to horizontal > scrollbars. It does affect vertical scrollbars. Comment 0 mentioned the missing vertical scrollbar in the Add-Ons Manager. I can confirm that vertical scrollbars are routinely missing with the elementary theme.
Comment on attachment 532141 [details] [diff] [review] Patch 2 Oh, I guess I was too hasty reading the bug comments... Back to square one I guess.
So after some more deliberation, another obvious solution belatedly hit me. I don't need to touch the length of the track at all, it's only the width that matters. Tests pass. Funny story: I tried to write a test for this, only to remember that this bug won't be triggered on the test machines...
Comment on attachment 532553 [details] [diff] [review] Patch 3 Review of attachment 532553 [details] [diff] [review]: -----------------------------------------------------------------
Attachment #532553 - Flags: review?(roc) → review+
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
I just noticed on the latest Nightly that this bug seems not to be fully gone. Instead of not showing a scrollbar, a different unstyled one is shown, rather than the correct one. Steps to reproduce: 1. Make sure you’re using the elementary GTK+ theme (eGTK). 2. Go to http://www.shadycharacters.co.uk/2011/09/irony-sarcasm-marks-part-1-of-3/ 3. Expected results: normal scrollbar. Actual results: different thinner scrollbar. Work-around: Modify page zoom. I’ve attached a screenshot of the issue with how it looks after zooming in and back out. The circumstances under which this bug appears and the work-around for it seem to be similar to when the problem was a disappearing scrollbar. Should I file a new bug for this?
Yes, please file a new bug for that, thanks David.
You need to log in before you can comment on or make changes to this bug.