330863 - vertical scroll bar appears on LHS instead of RHS

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Eyal Rozenberg]

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.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Related to bug 192767?

Comment 2

[Eyal Rozenberg]

Could be. I'm too lazy to check though.

Comment 3

[David Baron :dbaron:]

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.

Comment 4

[David Baron :dbaron:]

(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?

Comment 5

[Eyal Rozenberg]

> 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.

Comment 6

[Uri Bernstein (Google)]

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.

Comment 7

[David Baron :dbaron:]

Attachment: 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.  (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.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 9

[David Baron :dbaron:]

That would require changing all the callers...

Comment 10

[David Baron :dbaron:]

Checked in to trunk.

Comment 11

[Simon Montagu :smontagu]

(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.

Comment 12

[David Baron :dbaron:]

Hrm.  So are there some localizations (or something) in which we want scrollbars on the left by default?  How should we determine that?

Comment 13

[Simon Montagu :smontagu]

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.

Comment 14

[David Baron :dbaron:]

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.

Comment 15

[Simon Montagu :smontagu]

(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.

Comment 16

[Tsahi Asher]

(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.

Comment 17

[Uri Bernstein (Google)]

(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.

Comment 18

[Eyal Rozenberg]

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.

Comment 19

[Uri Bernstein (Google)]

(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.

Comment 20

[David Baron :dbaron:]

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.

Comment 21

[Uri Bernstein (Google)]

(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.

Comment 22

[Behnam Esfahbod [:zwnj]]

Won't be fixed in mozilla1.8/firefox2.0?

Comment 23

[Uri Bernstein (Google)]

(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.