Open
Bug 656833
Opened 14 years ago
Updated 3 years ago
Not all scrollbars respect "layout.scrollbar.side" pref
Categories
(Core :: Layout, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: callow.mark, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
The scrollbars on some internal browser pages do not respect layout.scrollbar.side. In particular about:config and the Add-Ons manager display scrollbars on the right even when layout.scrollbar.side is set to 3 (left). However about:support correctly displays the scrollbar on the left.
A similar problem exists in Thunderbird according to bug 536342
Reproducible: Always
Steps to Reproduce:
1. Type about:config in the address bar.
2. Set layout.scrollbar.side to 3; restart browser if you like
3. Type about:config in the address bar or open the Add-Ons manager
Actual Results:
The scrollbar is displayed on the right.
Expected Results:
A scrollbar displayed on the left.
Blocks: 536342
Component: Document Navigation → General
QA Contact: docshell → general
Summary: Not all scrollbars respect layout.scrollbar.side → Not all scrollbars respect "layout.scrollbar.side" pref
![]() |
||
Updated•14 years ago
|
Component: General → Layout
QA Contact: general → layout
Version: unspecified → Trunk
Scrollbars also on wrong side of forms, e.g.
*documents and directory lists at docs.google.com, and
*edit boxes like
**Wikipedia page edit boxes, and
**HTML editing at sites.google.com (normal WYSIWYG editing's correct tho).
I use these every day, while I rarely use about:config and about:addons.
Firefox 5.0 on Ubuntu 11.04.
![]() |
||
Comment 2•14 years ago
|
||
This pref explicitly affects only root scrollbars. Random non-root scrollable areas (like what you see in about:config or the addons manager or the list in comment 1 are not affected). That's how it's supposed to work...
Reporter | ||
Comment 3•14 years ago
|
||
That is an artificial distinction obvious only to and of interest only to implementers. The preference says "scrollbar.side". It does not say "onlysomescrollbars.side".
If you are going to make things like about:config and the Add Ons manager look like web pages, they ought to behave like web pages.
The whole notion of putting scroll bars on the right for languages written left to right is so broken that it has spawned an industry of workarounds such as scroll-wheels. I want *all* my scrollbars on the left.
![]() |
||
Comment 4•14 years ago
|
||
> That is an artificial distinction obvious only to and of interest only to implementers.
No, not at all. The pref used to affect all scrollbars, until bug 556363. The old behavior was in fact causing serious problems for actual users.
> It does not say "onlysomescrollbars.side".
Renaming the pref is easy if that's what you're after.
> they ought to behave like web pages.
They do. A web page with a scrollable area that's not the whole page (note the non-scrolling filter field in about:config and the left sidebar and top banner that are outside the scrollable area in aboutaddons) would likewise have that scrollable area ignoring this pref.
It sounds like people just have mutually contradictory requirements for the behavior here; maybe we just need pref values here that would apply to all scrollbars, or a separate pref for it...
Comment 5•14 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #4)
> It sounds like people just have mutually contradictory requirements for the
> behavior here; maybe we just need pref values here that would apply to all
> scrollbars, or a separate pref for it...
Hmm, yeah, that would make me sad (yet another pref value) but there's no way to satisfy everyone here. :(
Reporter | ||
Comment 6•14 years ago
|
||
Bug 556363 is about the resizer. The position of the resizer should NOT be connected with the position of the scrollbar. A preference for choosing where the scrollbar goes should NOT affect the position of the resize control. That should be a separate preference. The bug here is overloading the scrollbar preference for two purposes.
Please change scrollbar.side back to positioning all scrollbars and add a new preference for the resizer.
For LTR languages, the scrollbar should be on the left and the resize control on the lower right. For RTL languages the scrollbar should be on the right and the resize control on the lower left. (It would be even more preferable to be able to resize from any corner.)
These scrollbar positions are what are required for minimum motion of the pointing device. Consider for example this very bugzilla page. It provides a text field left-justified and less than half the width of the browser window that is filling my wide screen. With a right-hand scrollbar, absent workarounds, I have to move the pointer all the way to the right hand side of my screen. Most of the time when I am entering text, the pointer is near the left side!!
The fact that standard scrollbars are opposite from this is, I believe, because some right-handers found it awkward operating a left-hand-side scrollbar with their right hands. When RTL language support was first added to computers, it must have seemed like a good idea to someone to just swap everything, even though the scrollbar was already perfectly situated.
Comment 7•14 years ago
|
||
All of the applications that I know put the resizer and the scrollbars on the same side...
Reporter | ||
Comment 8•14 years ago
|
||
That is because they follow the lunacy of putting the scrollbar as far away from the text as possible. It makes no logical sense.
Comment 9•14 years ago
|
||
(In reply to Mark Callow from comment #8)
> That is because they follow the lunacy of putting the scrollbar as far away
> from the text as possible. It makes no logical sense.
True as that may be, this is the default behavior on all of the operating systems that we support: Windows, Linux, Mac, and Android.
Reporter | ||
Comment 10•14 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #9)
> True as that may be, this is the default behavior on all of the operating
> systems that we support: Windows, Linux, Mac, and Android.
That is still no reason to tie setting of the resize control and the scrollbar together in one preference.
Having layout.scrollbar.side affect only some scrollbars plays havoc with the most powerful memory we have, muscle memory. The preference needs to affect all scrollbars and a separate preference is needed for the resize control.
Comment 11•14 years ago
|
||
(In reply to Mark Callow from comment #10)
> (In reply to Ehsan Akhgari [:ehsan] from comment #9)
> > True as that may be, this is the default behavior on all of the operating
> > systems that we support: Windows, Linux, Mac, and Android.
> That is still no reason to tie setting of the resize control and the
> scrollbar together in one preference.
That is also the platform convention on all of those platforms, sans Android which doesn't have the notion of resizer widgets.
Reporter | ||
Comment 12•14 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #11)
> That is also the platform convention on all of those platforms, sans Android
> which doesn't have the notion of resizer widgets.
Can't be. Windows does not have a preference for setting the position of the scrollbars so how can it be shared with a preference for setting the position of the resize. Oh! You mean having the resizer and scrollbar on the same side?
I am not asking for the platform conventions to be changed only for some rational thinking about the preferences provided for those who wish to diverge from the conventions.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•