Closed
Bug 265276
Opened 20 years ago
Closed 18 years ago
firefox should allow scrollbars on the left-hand-side of windows (independent of lang)
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: bugs, Assigned: dbaron)
References
(Blocks 1 open bug)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 I am left-handed and use a graphics tablet as an input device due to problems with my right hand. It is much more comfortable for me to have scrollbars on the LHS of windows as that means my hand does not need to move very far to scroll a window. I do not believe it is currently possible to arrange this with firefox (or perhaps mozilla in general). Looking at the documentation for userChrome.css and userContent.css, the 'work around' for LHS sidebars is to use the position: css tag. I must state that I think there should be an alternative way of positioning scroll bars which is not linked to the text-direction via the position: attribute, as in my case, I read LTR like most westerners. Applying the following css snippet alternately in userChrome.css and then userContent.css results in all scrollbars and content being positioned on the left (in accordance with RTL reading) with the EXCEPTION of the main window scrollbar - my intended target! * { position: rtl; } This may be related to using 'native scrollbars' for the main window, although I do not know the technicalities of this or how it can be avoided. Reproducible: Always Steps to Reproduce: 1. Start Firefox Actual Results: Scrollbar is evident on the RHS independent of position: settings in userChrome.css or userContent.css Expected Results: Ideally there would be some way to put the scrollbars for the UI on the RHS independent of the text reading direction and/or language settings.
Comment 1•20 years ago
|
||
> * { position: rtl; }
I think you mean
* { direction: rtl; }
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•20 years ago
|
Component: Disability Access → Layout: View Rendering
Product: Firefox → Core
Version: unspecified → 1.0 Branch
Comment 2•20 years ago
|
||
This seems like a CSS bug.
Assignee: aaronleventhal → roc
QA Contact: bugzilla → ian
this wouldn't be hard to add but it's a very little-used feature IMHO and I don't know of any other software that allows it. So it's not going to be high on the priority list. Maybe if someone comes up with a patch...
Comment 4•20 years ago
|
||
Seems like extension fodder to me.
Reporter | ||
Comment 5•20 years ago
|
||
"this wouldn't be hard to add but it's a very little-used feature IMHO and I don't know of any other software that allows it." Hi - Surely mozilla can lead the way from time to time? ;) There are a few Linux apps that let you set them, notably terminal emulators (konsole, gnome-terminal, rxvt, etc.) but in general yes, not many apps provide this functionality. I've seen people using tablet PCs complain that when your (left) hand actually obscures the window due to reaching across the display, it can be more of an issue. "So it's not going to be high on the priority list. Maybe if someone comes up with a patch..." Maybe this is a good project for someone wanting to learn their way around the mozilla code? Not sure if this relates to 'native' scrollbars, but this may make its way into GTK: http://bugzilla.gnome.org/show_bug.cgi?id=157025 "Seems like extension fodder to me." Hi Ian, how could I go about confirming whether or not this is possible as an extension? I'm not an extension writer but from my preliminary digging I don't think it is. The scrollbar positioning must be independent of the language reading direction. Also there is the issue of native vs. non-native scrollbars.
> Hi - Surely mozilla can lead the way from time to time? ;) Sure, but we have to have priorities. > Maybe this is a good project for someone wanting to learn their way around the > mozilla code? Sure. This is a fairly easy change. Just read through nsGfxScrollFrame to see where it flips the scrollbar position when RTL is enabled, and add a pref check there.
Comment 7•19 years ago
|
||
Bug 273289 perhaps makes a decent arguement to implement this, i.e. for tablet PC users.
Comment 8•19 years ago
|
||
*** Bug 273289 has been marked as a duplicate of this bug. ***
Comment 9•19 years ago
|
||
(In reply to comment #3) > this wouldn't be hard to add but it's a very little-used feature IMHO and I > don't know of any other software that allows it. So it's not going to be high on > the priority list. Maybe if someone comes up with a patch... Some newer Microsoft products do have this option, especially OneNote, which is designed with TabletPC users in mind. As noted below, left-handed TabletPC users have a very hard time scrolling using right handed scrollbars. If it's not that hard to patch the Mozilla codebase to allow a left-handed scrollbars pref, it would be nice if this was officially added sometime soon.
Updated•19 years ago
|
Version: 1.0 Branch → Trunk
Assignee | ||
Updated•18 years ago
|
Assignee: roc → dbaron
Component: Layout: View Rendering → Layout
Target Milestone: --- → mozilla1.9alpha
Assignee | ||
Comment 10•18 years ago
|
||
Fixed by checkin of bug 330863. +// pref for which side vertical scrollbars should be on +// 0 = end-side in UI direction +// 1 = end-side in document/content direction +// 2 = right +// 3 = left +pref("layout.scrollbar.side", 0);
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 11•18 years ago
|
||
*** Bug 356838 has been marked as a duplicate of this bug. ***
Comment 13•16 years ago
|
||
As far as I get this, I think the default value for layout.scrollbar.side should be 1 - people that prefer the non-default behaviour can always change the property anyways (if dir=rtl is set, the vertical scrollbar should be drawn on the left-hand side of the scrollable element, no matter what direction the UI is setting - document direction should override the UI direction by default). Is there any reason why the default value of 0 should be kept? I don't mean to discriminate anybody, I'd just like to understand this. :) Thanks, Martin
You need to log in
before you can comment on or make changes to this bug.
Description
•