Closed Bug 330863 Opened 15 years ago Closed 15 years ago

vertical scroll bar appears on LHS instead of RHS

Categories

(Core :: Layout, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: eyalroz, Assigned: dbaron)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [patch])

Attachments

(1 file)

In the last few days, sometimes the vertical scrollbar appears on the LHS of the viewport instead of the RHS like the gods had intended it to. Must be some sort of BiDi thing.
Related to bug 192767?
Assignee: guifeatures → nobody
Component: XP Apps: GUI Features → Layout
Product: Mozilla Application Suite → Core
QA Contact: layout
Could be. I'm too lazy to check though.
So, yeah, I know I changed the behavior.  I mentioned it on bug 192767 and bug 221396.  The old behavior was:
 * scrollbar side on the canvas is based on the default direction
 * scrollbar side on things with 'overflow:auto' or 'overflow:scroll' is based on 'direction'
which is glaringly inconsistent.  I made it uniformly based on direction: BODY for HTML documents, and the root elsewhere.  I could revert to some other behavior.

Frankly, what I think we really need is usability testing for what's better for bidi users; I'm tempted to implement a preference (with 4 options, to also satisfy bug 265276: end-edge in current direction, end-edge in default direction, left, and right) to make that easier.
Summary: vertical scroll bar appears on LHS instead of LHS → vertical scroll bar appears on LHS instead of RHS
(Note that an advantage of having it vary based on 'direction' is that which way you can horizontally scroll is based on 'direction', so it provides an indication of that.)

What does WinIE do?
> which is glaringly inconsistent.  I made it uniformly based on direction: BODY
> for HTML documents, and the root elsewhere.  I could revert to some other
> behavior.

You should. The thing is, I don't want the direction of, say, the email message display scrollbar to change just because I've moved from an LTR to an RTL message. And if I change the message direction then I fuck up the alignment. I want RHS vertical scrollbars always (unless my entire Windows interface is RTL, which it isn't; but some have it that way, and they would probably like LHS scrollbars always).

Maybe you could post a poll somewhere, I dunno.
I know I have a strong opinion on this. I'm just not sure what it is.

Anyway, this affects Mac as well, so All/All.
OS: Windows XP → All
Hardware: PC → All
Attached patch patchSplinter Review
This adds a pref and makes its default value the sensible behavior that seems closest to what I could determine old behavior was from reading the code.  (By closest, I mean the same for the root scrollbar when document.dir was not set in the DOM, which is the 99% case.)  I'm not sure if the "bidi.direction" pref is really meaningful, though.
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Attachment #216176 - Flags: superreview?(roc)
Attachment #216176 - Flags: review?(smontagu)
Priority: -- → P2
Whiteboard: [patch]
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 216176 [details] [diff] [review]
patch

+enum nsPresContext_CachedBoolPrefType 

Can't we make these enums actual members of nsPresContext, so we can do nsPresContext::CachedBoolPrefType instead of this _ pseudo-namespace?
Attachment #216176 - Flags: superreview?(roc) → superreview+
That would require changing all the callers...
Attachment #216176 - Flags: review?(smontagu) → review+
Checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In reply to comment #7)
> I'm not sure if the "bidi.direction" pref
> is really meaningful, though.

It's not. I have had it in the back of my mind for years as something that should be removed, thanks for the reminder.
Hrm.  So are there some localizations (or something) in which we want scrollbars on the left by default?  How should we determine that?
As far as I know, localizations that want an RTL UI achieve it by setting 
 window { direction: rtl; }
(among other things) in intl.css. Setting bidi.direction makes typical LTR pages with no explicit direction misrender slightly.

Sorry, I don't seem to have thought this through properly when reviewing.
Did localizations with RTL UI have scrollbars on the left in the past?  If so, what code caused them to do so?  The only code I found depended on bidi.direction, so that's what I used.
(In reply to comment #14)
> Did localizations with RTL UI have scrollbars on the left in the past? 

My memory is that they did, but I am writing this comment in Hebrew Firefox 1.5, and to my surprise the scrollbar is on the right. cc-ing Tsahi, who may remember better than me.

> If so,
> what code caused them to do so?  The only code I found depended on
> bidi.direction, so that's what I used.

I would be fine with using bidi.direction for this purpose alone, and not using it to change the default direction of content, but maybe there is something else we can use. e.g. locale.dir.
(In reply to comment #15)
> (In reply to comment #14)
> > Did localizations with RTL UI have scrollbars on the left in the past? 
> 
> My memory is that they did, but I am writing this comment in Hebrew Firefox
> 1.5, and to my surprise the scrollbar is on the right. cc-ing Tsahi, who may
> remember better than me.
> 
as much as i remember (i started using mozilla with version 0.9.4) the main scroll bar was always at the right with RTL UI, regardless of the page direction.

i prefer it that way, because i don't want to send the mouse to the scroll bar, just to find out it's on the other side of the screen because the current page has a different direction. i second comment 5 on this.
(In reply to comment #7)
> Created an attachment (id=216176) [edit]
> patch
> 
> This adds a pref and makes its default value the sensible behavior that seems
> closest to what I could determine old behavior was from reading the code.  

I'm not happy with the scrollbar on RTL multiline <select>s being on the right (by default). It makes them horribly ugly, IMO. I think the old behaviour, where the main scrollbar was always on the right (at least when the chrome was LTR), and scrollbars on inner elements went according to the element's direction, is what most people would expect.
Uri, please open another bug about the default. As for me, I really don't care whether it's the previous behavior or the current one.
(In reply to comment #18)
> Uri, please open another bug about the default. As for me, I really don't care
> whether it's the previous behavior or the current one.
> 

This is not about the default. Currently, none of the available options is the same as the previous behavior (which was the best, IMO). This is why I'm bringing it up here.
So the old behavior may have been good for selects (and textareas?), but I don't see why it should differ between DIVs with overflow:auto and IFRAMEs, which the old behavior did differ between.
(In reply to comment #20)
> So the old behavior may have been good for selects (and textareas?), but I
> don't see why it should differ between DIVs with overflow:auto and IFRAMEs,
> which the old behavior did differ between.
> 

Because, in my mind, as a user, the "main" scrollbar is associated with the chrome/application (perhaps even the OS), whereas anything inside the content area is associated with the content.

That said, DIVs and IFRAMEs don't bother me that much (I can see them going either way). My problem is with selects (and, indeed, textareas), which, IMO, should always respect the content direction.
Won't be fixed in mozilla1.8/firefox2.0?
Blocks: Persian
(In reply to comment #22)
> Won't be fixed in mozilla1.8/firefox2.0?
> 

This bug is a result of the fix for bug 192767, which was fixed on the trunk only. Hence, this bug is trunk-only and there's nothing to fix on the branch.
Depends on: 454420
Depends on: 547572
You need to log in before you can comment on or make changes to this bug.