610682 - Position of the reload button in the location bar in RTL firefox should be at the same side in all platforms

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Simon Montagu :smontagu]

Currently the reload button in the location bar appears on the left side in Windows and Linux, but on the right side in OS X.

I admit that I'm not sure which position makes more sense, but we should at least be consistent.

Arguments for having it on the right (as in the LTR version):

The location bar itself is not reversed in RTL builds, because URLs are always left-to-right (even with IDN). The other controls in the location bar (bookmark, and candidate list drop down) are not reversed either.

Arguments for having it on the left:

The reload button is not part of the location bar as such, and the logical place for it is between the location bar and the search bar.

In any case, the "Go to this address" arrow that appears when typing in the location bar should be flipped to point to the left, i.e. "forwards"

Steps to reproduce in a non-localized build:
Set intl.uidirection.en to "rtl" in about:config
Restart Firefox (not sure if this step is still necessary)

Comment 1

[(no longer active)]

I personally think that we should put the reload/stop button at the right side of the location bar.  The way that we're styling the location bar for Firefox 4, I get the feeling that we intend the entire thing to be a single entity, so it makes little sense for part of the location bar to be reversed, while the rest is not.

But I'm open to suggestions.

Comment 2

[(no longer active)]

Oh, and whatever we're going to do, we need to address this before we ship Firefox 4.

Comment 3

[Anas Husseini [:linostar]]

I also think that the reload/stop button should be on the right. It looks very silly on the left margin of the location bar, without mentioning that I personally prefer seeing the refresh button near the back & forward buttons (yes, I know I'm old-fashioned!).

However, if the refresh button is moved to the right, I guess the arrow direction of the go button will be problematic. If it points to the right it may appear pointing backward to rtl users (as Simon mentioned); and if it points to the left, it will be pointing to the url itself (that is it will be backward in respect to the url direction). Should it point to an invisible 3rd direction? :-)

Comment 4

[Tomer Cohen :tomer]

Following is a mockup of how I suggest it should be shown (I hope you have a good Unicode font installed in order to see all the glyphs below) - 

LTR:   ⬅ ➡ ⌂ [⛾ http://bugzilla.mozilla.org/      ★ ∇ ⟳]
RTL:   [⛾ http://bugzilla.mozilla.org/      ★ ∇ ⟳] ⌂ ⬅ ➡

As for the Go button Anas mentioned, we currently not flipping it, so it should appear pointing to the right both on LTR and RTL. 


A quick look in this bug show that everyone vote for putting it on the right side of the location bar, as done with LTR. ☺

Comment 5

[(no longer active)]

(In reply to comment #3)
> I also think that the reload/stop button should be on the right. It looks very
> silly on the left margin of the location bar, without mentioning that I
> personally prefer seeing the refresh button near the back & forward buttons
> (yes, I know I'm old-fashioned!).
> 
> However, if the refresh button is moved to the right, I guess the arrow
> direction of the go button will be problematic. If it points to the right it
> may appear pointing backward to rtl users (as Simon mentioned); and if it
> points to the left, it will be pointing to the url itself (that is it will be
> backward in respect to the url direction). Should it point to an invisible 3rd
> direction? :-)

Why is there a problem with it pointing to right?

Comment 6

[Dão Gottwald [:dao]]

(In reply to comment #3)
> I also think that the reload/stop button should be on the right. It looks very
> silly on the left margin of the location bar, without mentioning that I
> personally prefer seeing the refresh button near the back & forward buttons

Yet you just mentioned it. ;-) And it's not a legit point -- not more than for LTR anyway.

Comment 7

[Simon Montagu :smontagu]

(In reply to comment #5)

> Why is there a problem with it pointing to right?

Pointing to the right looks like "go back" instead of "go", especially when it's close to the back and forward buttons.

Comment 8

[(no longer active)]

(In reply to comment #7)
> (In reply to comment #5)
> 
> > Why is there a problem with it pointing to right?
> 
> Pointing to the right looks like "go back" instead of "go", especially when
> it's close to the back and forward buttons.

Hmm, yeah, I can see how users can get that impression.

But I think the button pointing to the left could be at least similarly awkward, since it will point towards the URL itself.  I don't know if this problem has a clear solution...  :(

Comment 9

[Elad Alfassa]

(In reply to comment #7)
> (In reply to comment #5)
> 
> > Why is there a problem with it pointing to right?
> 
> Pointing to the right looks like "go back" instead of "go", especially when
> it's close to the back and forward buttons.

When you read the URL, it looks like "go", because your brain is already in it's "LTR Mode", as you read the URL from left to right.

Comment 10

[(no longer active)]

(In reply to comment #9)
> (In reply to comment #7)
> > (In reply to comment #5)
> > 
> > > Why is there a problem with it pointing to right?
> > 
> > Pointing to the right looks like "go back" instead of "go", especially when
> > it's close to the back and forward buttons.
> 
> When you read the URL, it looks like "go", because your brain is already in
> it's "LTR Mode", as you read the URL from left to right.

That's kind of my intuition as well...

Comment 11

[Rob Campbell [:rc] (:robcee)]

ccing some rtl hackers for feedback.

Comment 12

[(no longer active)]

So, here's what this boils down to.  It seems like everybody in this bug agrees that the reload button should appear at the right side on all of the platforms.  The only person who has not expressed his final opinion on this is Simon as far as I can tell.

Therefore, unless Simon objects, I propose that the fix to this bug should include putting the reload button at the right side of the location bar for Linux.

The direction of the Go button is harder to decide, for sure, but I think is out of scope for this bug.  I think we should worry about that in a separate bug.

Comment 13

[Simon Montagu :smontagu]

My mind is still perfectly balanced between the two options ;-)
I have no objection to going with the majority opinion and putting the button on the right on all platforms.

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #12)
> The direction of the Go button is harder to decide, for sure, but I think is
> out of scope for this bug.

When stop/reload/go are one widget, which they are right now, this is really one and the same question to answer.

Comment 15

[Simon Montagu :smontagu]

(In reply to comment #14)
> When stop/reload/go are one widget, which they are right now, this is really
> one and the same question to answer.

The *position* is one and the same question, but the direction of the arrow on the Go button is another question -- see comments 3 through 10. I lean towards following the precedent of video/audio playback controls and leaving it unflipped.

Comment 16

[Dão Gottwald [:dao]]

What I'm saying is that if a particular position makes the direction of the Go button problematic, then maybe it should be a different position after all.

Comment 17

[(no longer active)]

I don't think that anybody is suggesting that.  I think we can proceed with what I suggested in comment 12.

Comment 18

[Dão Gottwald [:dao]]

(In reply to comment #17)
> I don't think that anybody is suggesting that.

"That" is moving the thing to the right, isn't it? Otherwise I don't know what you're referring to.
Moving it to the right seems to lead to the problem mentioned in comment 3.

Also, you seem to be wrongly assuming that Linux is the odd one out here. AFAIK we currently do the same on Linux and Windows and I *think* it's more or less consistent with what we do in 3.6 as far as the Go button is concerned.

Comment 19

[(no longer active)]

(In reply to comment #18)
> (In reply to comment #17)
> > I don't think that anybody is suggesting that.
> 
> "That" is moving the thing to the right, isn't it?

I meant "moving the go/reload button to the left side".

> Otherwise I don't know what
> you're referring to.
> Moving it to the right seems to lead to the problem mentioned in comment 3.

There is no perfect solution here.  On the positioning of the button, I think everybody here agrees that it should be placed on the right side, given that the location bar itself is LTR, and those buttons are a part of the location bar.

On the direction of the Go button, between the option of making it point to the URL itself, or point to right which might be the conceptual "back" direction in user's mind seems to be the lesser of two evil.

Now, I should mention that this unfortunate situation we're in is kind of caused by the fact that the RTL mode was not considered as carefully as the LTR mode when designing the new UI mockups, I think...  :(

> Also, you seem to be wrongly assuming that Linux is the odd one out here. AFAIK
> we currently do the same on Linux and Windows and I *think* it's more or less
> consistent with what we do in 3.6 as far as the Go button is concerned.

It doesn't matter if Windows is having the same problem as Linux (I don't run Windows myself, so I assumed that the reload button is on the right side on Windows from the comments here).

What needs to be done is that the go/reload/stop button should be moved to the right end of the location bar in RTL mode in all platforms where this is currently not the case.

Comment 20

[Dão Gottwald [:dao]]

(In reply to comment #19)
> > > I don't think that anybody is suggesting that.
> > 
> > "That" is moving the thing to the right, isn't it?
> 
> I meant "moving the go/reload button to the left side".

It was suggested as one option in comment 0 and I don't see many useful arguments against it in this bug. You expressed your gut feeling, which I respect, but it's just that, a gut feeling. Comment 3 is mostly bogus as it seems to seek parity with the stop/reload position in 3.6, which the new theme explicitly changed, etc.. I'd like to see a more merit-based decision rather than making this a poll among three or four RTL guys (which is certainly not the way we design the LTR UI, even though I sometimes wish it were more democracy-based!).

> On the positioning of the button, I think
> everybody here agrees that it should be placed on the right side, given that
> the location bar itself is LTR, and those buttons are a part of the location
> bar.

Comment 0 reads: "The reload button is not part of the location bar as such, and the logical place for it is between the location bar and the search bar."

Comment 21

[Asaf Romano (gone)]

Dao: It certainly has been the way the RTL changes has been made so far, and you should respect whatever decision is made here.

I haven't expressed my opinion here as I didn't have much time to play with this myself.

Comment 22

[Dão Gottwald [:dao]]

(In reply to comment #21)
> Dao: It certainly has been the way the RTL changes has been made so far, and
> you should respect whatever decision is made here.

Maybe it has been this way because nobody else cared. I do care, since Firefox in a RTL setup is still Firefox, and I have to say that the arguments delivered here so far are not convincing.

Comment 23

[Simon Montagu :smontagu]

The argument for cross-platform consistency should be convincing, at least!

Comment 24

[Alex Limi (:limi) — Firefox UX Team]

I'm a little bit lost here, and since I'm personally not an RTL user, I can't really comment on "what feels right", but maybe these guidelines can help reach a conclusion:

* The stop/go/reload button is one unit, and shouldn't be split apart in its default configuration

* It should be located where the typing/URL ends (which is probably part of the problem here, since you enter URLs in LTR mode, I believe?)

* It should be in the same location as the current "Go" button in 3.6

When testing FF in RTL mode, there are a lot of things that don't make a lot of sense to me, e.g:

* The search engine selector is on the right side, but favicon is on the left side. I would have expected this to be the same.

* Typing in the search engine field is right-aligned, but URL entry is left-aligned. I would have expected URL entry to be right-aligned too.

If URL entry was right-aligned, and the favicon was on the right side, this would have been easier to make a call on. But I can't really find a pattern that makes sense for my LTR brain. :)

What does IE do in these cases? Microsoft is usually pretty good at doing research on these things before implementing them, and platform consistency should be a strong guideline. I tried finding some screenshots, but was unsuccessful.

Comment 25

[Dão Gottwald [:dao]]

By the way, it occurred to me that letting the theme disregard the order defined in the toolbar's defaultset/currentset would cause the buttons to change positions when customizing toolbars.

Comment 26

[(no longer active)]

(In reply to comment #24)
> I'm a little bit lost here, and since I'm personally not an RTL user, I can't
> really comment on "what feels right", but maybe these guidelines can help reach
> a conclusion:
> 
> * The stop/go/reload button is one unit, and shouldn't be split apart in its
> default configuration

OK.

> * It should be located where the typing/URL ends (which is probably part of the
> problem here, since you enter URLs in LTR mode, I believe?)

The URLs used on the web have a left to right nature (i.e., the logical start point is on the left side, being the protocol specifier).  This is why we have kept the location bar left to right and left aligned.

> * It should be in the same location as the current "Go" button in 3.6

I'm not sure why this is a requirement, but FWIW we keep the Go button on the right side in 3.6.

> When testing FF in RTL mode, there are a lot of things that don't make a lot of
> sense to me, e.g:
> 
> * The search engine selector is on the right side, but favicon is on the left
> side. I would have expected this to be the same.

Which platform is this?  

> * Typing in the search engine field is right-aligned, but URL entry is
> left-aligned. I would have expected URL entry to be right-aligned too.

See above.  The nature of what the user types into the search bar is not known beforehand, so we assume a right to left direction.

> If URL entry was right-aligned, and the favicon was on the right side, this
> would have been easier to make a call on. But I can't really find a pattern
> that makes sense for my LTR brain. :)

Does the above provide better background information for you to make a call?

> What does IE do in these cases? Microsoft is usually pretty good at doing
> research on these things before implementing them, and platform consistency
> should be a strong guideline. I tried finding some screenshots, but was
> unsuccessful.

This should be checked by someone who has access to a right to left version of Windows.  Simon, do you have a Hebrew Windows around?

Comment 27

[Simon Montagu :smontagu]

Attachment: Screenshot of Hebrew IE8 on Windows XP

This is the only version of IE that I have, so that I'm not sure how it compares to the LTR version. What I do notice is that the URL bar is flipped to right-to-left geometry, and the text field is right-aligned, but has left-to-right directionality.

Comment 28

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #26)
> > When testing FF in RTL mode, there are a lot of things that don't make a lot of
> > sense to me, e.g:
> > 
> > * The search engine selector is on the right side, but favicon is on the left
> > side. I would have expected this to be the same.
> 
> Which platform is this?  

Mac OS X.

> Does the above provide better background information for you to make a call?

Yes, and:

(In reply to comment #27)
> Created attachment 501934 [details]
> Screenshot of Hebrew IE8 on Windows XP
> 
> This is the only version of IE that I have, so that I'm not sure how it
> compares to the LTR version. What I do notice is that the URL bar is flipped to
> right-to-left geometry, and the text field is right-aligned, but has
> left-to-right directionality.

…this was going to be my next suggestion. Am I missing something? (ie. do we have elements that behave differently than IE?)

Comment 29

[Simon Montagu :smontagu]

(In reply to comment #28)
> > What I do notice is that the URL bar is flipped to
> > right-to-left geometry, and the text field is right-aligned, but has
> > left-to-right directionality.
> 
> …this was going to be my next suggestion. 

I hacked up a CSS patch to approximate this behaviour in Firefox and have been dogfooding it for the last few days. I think it makes much more visual sense than our current UI.

Chrome also does something similar -- see the screenshots in http://www.chromium.org/developers/design-documents/ui-mirroring-infrastructure (though I can't actually reproduce this behaviour in my copy of Chrome on OS X).

> Am I missing something? (ie. do we
> have elements that behave differently than IE?)

Not that I'm aware of, though I don't use IE much and my Windows box is currently out of action so I can't easily test it.

Comment 30

[(no longer active)]

(In reply to comment #28)
> (ie. do we have elements that behave differently than IE?)

What do you mean, exactly?

Simon, do you think the right-aligned location bar makes more sense, especially with things like link preview, etc?  Can you provide a screenshot of your experimental CSS patch?

Comment 31

[Simon Montagu :smontagu]

Link preview is certainly what looks worst in the right-aligned location bar (though it could be improved from what my patch currently does). At the moment the current address text moves to the right when it gets cropped. I assume we don't want to change to left cropping instead of right cropping, and have the link preview overwrite the domain?

Comment 32

[Simon Montagu :smontagu]

Attachment: Make URL bar LTR but right aligned

I don't have this applied so I can't provide screenshots right now, but here is the patch in all its unpolished glory.

Comment 33

[Elad Alfassa]

I don't think right aligning the URL bar is a good solution. An LTR text should be left aligned.
I think that the best idea is to move the reload/stop/go button to the right side of the URL bar, and leave the rest unchanged.

Comment 34

[(no longer active)]

(In reply to comment #31)
> Link preview is certainly what looks worst in the right-aligned location bar
> (though it could be improved from what my patch currently does). At the moment
> the current address text moves to the right when it gets cropped. I assume we
> don't want to change to left cropping instead of right cropping, and have the
> link preview overwrite the domain?

No, I don't think that we want that, but I also don't think that right aligning the URL and also right cropping it go well together.

(I would want to say that right-aligning URLs in the location bar is a very bad idea, even though IE does it, but I don't have hard evidence -- not that I think it's possible to have one here -- so it is only my gut feeling...)

Comment 35

[Simon Montagu :smontagu]

Attachment: IE8 and patched FF side by side on Win7

Comment 36

[Simon Montagu :smontagu]

Attachment: IE and patched FF side by side on Win7

Comment 37

[Simon Montagu :smontagu]

Attachment: Firefox RTL urlbar with link preview

Comment 38

[Asaf Romano (gone)]

For what it's worth (as I'm here just for the final patch...), I think we shouldn't special case the location bar in RTL builds any more. Making it LTR made sense back when it had nothing but LTR content. That's not the case now: we have: (a) "pure" rtl contents (page titles and ui strings) (b) sub-ui widgets. Parity with IE is also important.

Another option is to LTR the input field contents, but set right text alignment.

Comment 39

[(no longer active)]

(In reply to comment #38)
> Another option is to LTR the input field contents, but set right text
> alignment.

Whatever we do, we should keep the input field's direction LTR, to avoid getting URLs show up like "/http://www.google.com" there.

Looking at Simon's screenshots, they don't look too bad.  Here are a bunch of things to note though:

1. A UX person should vet on these.  The things which specifically worry me are:
 * the direction of the Go button.
 * the direction and placement of the ">" marker in link previews.
2. We should make sure that the site identity and bookmark popups open with the correct direction.
3. The input field should be LTR.
4. We should also make sure that the emptytext of the input field shows up correctly as well.

Comment 40

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #39)
> (In reply to comment #38)
> > Another option is to LTR the input field contents, but set right text
> > alignment.
> 
> Whatever we do, we should keep the input field's direction LTR, to avoid
> getting URLs show up like "/http://www.google.com" there.

Why would that happen? Do we parse the contents of URLs as separate words?

> Looking at Simon's screenshots, they don't look too bad.  Here are a bunch of
> things to note though:
> 
> 1. A UX person should vet on these.  The things which specifically worry me
> are:
>  * the direction of the Go button.
>  * the direction and placement of the ">" marker in link previews.

These should be flipped if the general sense of movement/progress/direction is right-to-left in RTL locales, which the current treatment of the back/forward button leads me to believe.

Comment 41

[(no longer active)]

(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #38)
> > > Another option is to LTR the input field contents, but set right text
> > > alignment.
> > 
> > Whatever we do, we should keep the input field's direction LTR, to avoid
> > getting URLs show up like "/http://www.google.com" there.
> 
> Why would that happen? Do we parse the contents of URLs as separate words?

That is how the string "http://www.google.com/" is rendered with a base direction of right-to-left according to the Unicode Bidi Algorithm.

> > Looking at Simon's screenshots, they don't look too bad.  Here are a bunch of
> > things to note though:
> > 
> > 1. A UX person should vet on these.  The things which specifically worry me
> > are:
> >  * the direction of the Go button.
> >  * the direction and placement of the ">" marker in link previews.
> 
> These should be flipped if the general sense of movement/progress/direction is
> right-to-left in RTL locales, which the current treatment of the back/forward
> button leads me to believe.

It is.  But we also have a counter example in Firefox: video controls.  We do not change the direction of the play button, or the direction of the progress bar in RTL versions of Firefox.

Comment 42

[Asaf Romano (gone)]

Attachment: v1

This implements my proposed solution addressing the last few comments.  I've tested pinstripe on mac and as-much-as-i-could winstripe, on mac. I cannot test gnomestripe.

There are still few problems and open issues:
1. Should we flip the reload icon? (decision, one liner change)
2. Should we flip page titles in autocomplete? (decision, one liner change)
3. How to get the ellipsis into their place in autocomplete. It seems that the current DOM structure there prevents that. That's a minor issue, I think.
4. The " > " icon in the location bar that precedes the hover linked url, it seems we cannot flip it easily (i.e. using scaleX transform), as it uses background-image technique.  Ideas are very welcome.

I think that's it.

Comment 43

[Simon Montagu :smontagu]

(In reply to comment #42)
 1. Should we flip the reload icon? (decision, one liner change)

I think not. Generally we don't flip clockwise and counterclockwise rotation in RTL interface, and the arrow in the reload icon matches the direction of the rotating "reloading" widget that appears when a tab is loading.

> 2. Should we flip page titles in autocomplete? (decision, one liner change)

I think for now we should keep the autocomplete LTR direction and RTL alignment. When bug 548206 is fixed, we should give it auto-direction.

> 3. How to get the ellipsis into their place in autocomplete. It seems that the
> current DOM structure there prevents that. That's a minor issue, I think.

I don't understand what this refers to.

> 4. The " > " icon in the location bar that precedes the hover linked url, it
> seems we cannot flip it easily (i.e. using scaleX transform), as it uses
> background-image technique.  Ideas are very welcome.

Can't we just do it the hard way with two images?

Comment 44

[Simon Montagu :smontagu]

(In reply to comment #33)
> I don't think right aligning the URL bar is a good solution. An LTR text should
> be left aligned.

Not necessarily - URLs and LTR page titles in the History dropdown are already right aligned (and vice versa in LTR UI). If you look through the ads in a Hebrew newspaper, you'll see many examples of right-aligned URLs

Comment 45

[Anas Husseini [:linostar]]

(In reply to comment #44)
> Not necessarily - URLs and LTR page titles in the History dropdown are already
> right aligned (and vice versa in LTR UI). If you look through the ads in a
> Hebrew newspaper, you'll see many examples of right-aligned URLs

I fancy that if a URL ends with a slash, that slash may appear on the right side if the box is in RTL direction, e.g. http://www.mozilla.org/ may appear /http://www.mozilla.org

Comment 46

[Asaf Romano (gone)]

Simon: any chance you could flip those images for me? I don't have the necessary tools atm.  These are:
http://mxr.mozilla.org/mozilla-central/find?text=&string=urlbar-over-link-arrow.png

Comment 47

[Anas Husseini [:linostar]]

Attachment: winstripe urlbar-over-link-arrow flipped

Comment 48

[Anas Husseini [:linostar]]

Attachment: gnomestripe urlbar-over-link-arrow flipped

Comment 49

[Anas Husseini [:linostar]]

Attachment: pinstripe urlbar-over-link-arrow-rtl flipped

Comment 50

[Asaf Romano (gone)]

Many many thanks!

Comment 51

[(no longer active)]

Comment on attachment 505344 [details] [diff] [review]
v1

This looks good to me.  Mano, if you could integrate the flipped images, I will actually go ahead and test this on all of the three platforms, and will provide you with a much more extensive feedback (and screenshots!).

Comment 52

[Asaf Romano (gone)]

On that... (I can only provide OS X screenshots).

Comment 53

[Asaf Romano (gone)]

Attachment: mac-go-button-and-autocomplete

Comment 54

[Asaf Romano (gone)]

Attachment: over link (mac)

Comment 55

[Asaf Romano (gone)]

Attachment: the autocomplete bug we cannot fix without breaking addon compatibilty, afaict

"How to get the ellipsis into their place in autocomplete. It seems that the
current DOM structure there prevents that. That's a minor issue, I think."

So, here is a screenshot. I think we can fix that post Fx4.

Comment 56

[Asaf Romano (gone)]

Attachment: the autocomplete bug we cannot fix without breaking addon compatibilty, afaict

Comment 57

[Asaf Romano (gone)]

Attachment: v2

Comment 58

[Asaf Romano (gone)]

I'll post some linux screenshots in a bit.

Comment 59

[Asaf Romano (gone)]

Attachment: v2.1

Comment 60

[Asaf Romano (gone)]

Attachment: Linux screenshot

Comment 61

[Asaf Romano (gone)]

Attachment: over link (linux)

Comment 62

[Dão Gottwald [:dao]]

Comment on attachment 505869 [details] [diff] [review]
v2.1

>--- a/toolkit/content/xul.css	Tue Jan 18 00:11:08 2011 -0800
>+++ b/toolkit/content/xul.css	Fri Jan 21 21:14:09 2011 +0200

>+html|input.uri-element:-moz-locale-dir(rtl) {
>   direction: ltr !important;
> }

>+html|input.uri-element-right-align:-moz-locale-dir(rtl) {
>+  direction: ltr !important;
>+  text-align: right !important;
>+}

I think you're potentially affecting web content here, but maybe :-moz-locale-dir(rtl) won't match there?

Comment 63

[Dão Gottwald [:dao]]

Comment on attachment 505850 [details]
over link (mac)

The reload button's border is on the wrong side.

Comment 64

[Asaf Romano (gone)]

Attachment: v2.2

Comment 65

[Asaf Romano (gone)]

(In reply to comment #62)
> Comment on attachment 505869 [details] [diff] [review]
> v2.1
> 
> >--- a/toolkit/content/xul.css	Tue Jan 18 00:11:08 2011 -0800
> >+++ b/toolkit/content/xul.css	Fri Jan 21 21:14:09 2011 +0200
> 
> >+html|input.uri-element:-moz-locale-dir(rtl) {
> >   direction: ltr !important;
> > }
> 
> >+html|input.uri-element-right-align:-moz-locale-dir(rtl) {
> >+  direction: ltr !important;
> >+  text-align: right !important;
> >+}
> 
> I think you're potentially affecting web content here, but maybe
> :-moz-locale-dir(rtl) won't match there?

Indeed it won't, plus we don't load xul.css there IIRC.

Comment 66

[Asaf Romano (gone)]

See bug 588996 for -moz-locale-dir not applied to html content.

Comment 67

[Dão Gottwald [:dao]]

(In reply to comment #65)
> we don't load xul.css there IIRC.

bug 482585 suggests that we do

Comment 68

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

Yeah, we do. data:text/html,<span class="accesskey">foobar</span> surprised me!

We should probably stop now that we don't support remote XUL...

Comment 69

[Asaf Romano (gone)]

Would xul|*:-moz-locale-dir > html|input.uri... work?

Comment 70

[Asaf Romano (gone)]

Attachment: v2.3

I'm not sure if we should flip the shadows (and what about border-radius?). Eshan?

Comment 71

[Asaf Romano (gone)]

Attachment: v2.4

Comment 72

[Asaf Romano (gone)]

Log before you fall asleep:

v2.4 moved the rules from xul.css to browser.css per gavin's request.
Virtual-version 2.4.0.1 fixes the rules in browser.css to select -moz-locale-dir(rtl).  In IRC syntax that would be:

<Mano>	.ac-url-text:-moz-locale-dir(rtl),
<Mano>	.ac-title:-moz-locale-dir(rtl) > description {

Comment 73

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

Attachment: v2.4, corrected

This includes the images, and makes a tweak as discussed on IRC (add :-moz-locale-dir(rtl) to the .ac selectors in browser.css).

Comment 74

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

Comment on attachment 506024 [details] [diff] [review]
v2.4, corrected

Margaret noticed one thing in testing, on Windows, in RTL:
- the link hover text causes the URL to jump a few pixels to the right (when neither the preview nor the URL are truncated)

Comment 75

[Dão Gottwald [:dao]]

Comment on attachment 506024 [details] [diff] [review]
v2.4, corrected

Patch needs to be merged to apply after http://hg.mozilla.org/mozilla-central/rev/0718ec141474

>--- a/browser/themes/gnomestripe/browser/browser.css
>+++ b/browser/themes/gnomestripe/browser/browser.css

> #urlbar > toolbarbutton {
>   -moz-appearance: none;
>   list-style-image: url("chrome://browser/skin/reload-stop-go.png");
>   margin: -2px;
>   -moz-margin-start: 0;
>   padding: 0 3px;
>   background-origin: border-box;
>   border: none;
>-  border-left: 1px solid rgba(0,0,0,.35);
>+  -moz-border-start: 1px solid rgba(0,0,0,.35);
>   border-top-right-radius: 2px;
>   border-bottom-right-radius: 2px;
> }

Need to change the border radius sides for rtl. Affects winstripe/pinstripe too.

>+#urlbar-go-button:-moz-locale-dir(rtl) .toolbarbutton-icon {
>+  -moz-transform: scaleX(-1);
>+}

Child combinator should be used:
#urlbar-go-button:-moz-locale-dir(rtl) > .toolbarbutton-icon

Affects winstripe/pinstripe too.

>--- a/browser/themes/pinstripe/browser/browser.css
>+++ b/browser/themes/pinstripe/browser/browser.css

> #urlbar-reload-button {
>   -moz-image-region: rect(0px, 14px, 14px, 0px);
> }
>-
>+  

Unintended whitespace change.

Comment 76

[(no longer active)]

(In reply to comment #65)
> > I think you're potentially affecting web content here, but maybe
> > :-moz-locale-dir(rtl) won't match there?
> 
> Indeed it won't, plus we don't load xul.css there IIRC.

:-moz-locale-dir only works in XUL documents (and it should work on both XUL and HTML elements in such documents).

Comment 77

[(no longer active)]

(In reply to comment #70)
> Created attachment 505924 [details] [diff] [review]
> v2.3
> 
> I'm not sure if we should flip the shadows (and what about border-radius?).
> Eshan?

The shadows have the x coordinate set to 0 as far as I can see, so there is no point in flipping them.

Why do you think that we should not flip the border radii though?

Comment 78

[(no longer active)]

(In reply to comment #55)
> Created attachment 505851 [details]
> the autocomplete bug we cannot fix without breaking addon compatibilty, afaict
> 
> "How to get the ellipsis into their place in autocomplete. It seems that the
> current DOM structure there prevents that. That's a minor issue, I think."

Can you please specify what's in the DOM structure which prevents this from getting fixed in Firefox 4?

Comment 79

[Alex Limi (:limi) — Firefox UX Team]

Is there any way we can get this landed soon, since it currently blocks bug 625956?

Comment 80

[(no longer active)]

(In reply to comment #79)
> Is there any way we can get this landed soon, since it currently blocks bug
> 625956?

This needs a new patch which addresses the review comments, and some of my comments in the bug too, maybe.  But I think this is mainly the direction that we're going to take here, so I'll comment on bug 625956 about this.

Comment 81

[Asaf Romano (gone)]

Attachment: v3

Comment 82

[Dão Gottwald [:dao]]

Comment on attachment 507093 [details] [diff] [review]
v3

> .urlbar-over-link-box {
>   position: relative;
>+  color: GrayText;
>+  min-height: 22px;
>+}
>+
>+.urlbar-over-link-box:-moz-locale-dir(ltr) {
>+  background: url(chrome://browser/skin/urlbar-over-link-arrow.png) no-repeat left center;
>+  padding: 0 5px 0 18px;
>   right: 0;
>-  color: GrayText;
>-  padding: 0 5px 0 18px;
>-  min-height: 22px;
>-  background: url(chrome://browser/skin/urlbar-over-link-arrow.png) no-repeat left center;
>+}
>+
>+.urlbar-over-link-box:-moz-locale-dir(rtl) {
>+  background: url(chrome://browser/skin/urlbar-over-link-arrow-rtl.png) no-repeat right center;
>+  padding: 0 18px 0 5px;
>+  left: 0;
> }

You could use -moz-padding-start/end instead of the -moz-locale-dir specific paddings.

> #go-button {
>-  padding: 3px 2px 2px 2px;
>+  padding-top: 3px;
>+  padding-bottom: 2px;
>+  -moz-padding-start: 2px;
>+  -moz-padding-end: 2px;

No need to make this change.

> #urlbar > toolbarbutton {
>   -moz-appearance: none;
>   list-style-image: url("chrome://browser/skin/reload-stop-go.png");
>   margin: -2px;
>   -moz-margin-start: 0;
>   padding: 0 3px;
>   background-origin: border-box;
>   border: none;
>+}
>+
>+#urlbar:-moz-locale-dir(ltr) > toolbarbutton {
>   border-left: 1px solid rgba(0,0,0,.35);
>   border-top-right-radius: 2px;
>   border-bottom-right-radius: 2px;
> }
> 
>+#urlbar:-moz-locale-dir(rtl) > toolbarbutton {
>+  border-right: 1px solid rgba(0,0,0,.35);
>+  border-top-left-radius: 2px;
>+  border-bottom-left-radius: 2px;
>+}

This should use -moz-border-start instead of border-left and border-right.

Comment 83

[Asaf Romano (gone)]

Dao, I'm not a layout expert, so that's less than two cents:

As far as I understand it, using the -moz-locale-dir selector is generally better than using the -moz-*-start mess (bug 548206 suggests that they're breaking computed style, for example).

Comment 84

[Asaf Romano (gone)]

(In reply to comment #78)
> (In reply to comment #55)
> > Created attachment 505851 [details]
> > the autocomplete bug we cannot fix without breaking addon compatibilty, afaict
> > 
> > "How to get the ellipsis into their place in autocomplete. It seems that the
> > current DOM structure there prevents that. That's a minor issue, I think."
> 
> Can you please specify what's in the DOM structure which prevents this from
> getting fixed in Firefox 4?

There's no box to reverse, basically. http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml?force=1#1181

If the final release wasn't as close, I would definitely change the structure. If the issue wasn't as minor, I would even do it now.

Comment 85

[Dão Gottwald [:dao]]

(In reply to comment #83)
> Dao, I'm not a layout expert, so that's less than two cents:
> 
> As far as I understand it, using the -moz-locale-dir selector is generally
> better than using the -moz-*-start mess (bug 548206 suggests that they're
> breaking computed style, for example).

:-moz-locale-dir is more cumbersome (I suspect that's why you don't use it throughout the patch) and I don't think we're going to replace our uses of -moz-*-start/end. -moz-*-start just translates to *-left or *-right in the computed style.

Comment 86

[Asaf Romano (gone)]

Fine (well, in a bit).

Comment 87

[(no longer active)]

(In reply to comment #84)
> (In reply to comment #78)
> > (In reply to comment #55)
> > > Created attachment 505851 [details]
> > > the autocomplete bug we cannot fix without breaking addon compatibilty, afaict
> > > 
> > > "How to get the ellipsis into their place in autocomplete. It seems that the
> > > current DOM structure there prevents that. That's a minor issue, I think."
> > 
> > Can you please specify what's in the DOM structure which prevents this from
> > getting fixed in Firefox 4?
> 
> There's no box to reverse, basically.
> http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml?force=1#1181
> 
> If the final release wasn't as close, I would definitely change the structure.
> If the issue wasn't as minor, I would even do it now.

Hmm, is it more complicated than to just move the DOM node for the ellipsis text here, while we're setting it up? <http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml#1200>

Comment 88

[Asaf Romano (gone)]

You're still changing the expected, just later than expected...

Comment 89

[(no longer active)]

(In reply to comment #88)
> You're still changing the expected, just later than expected...

OK.  Can you please file a bug so that we remember to fix this post Firefox 4?

Comment 90

[Asaf Romano (gone)]

Of course!

Comment 91

[Asaf Romano (gone)]

http://hg.mozilla.org/mozilla-central/rev/e98b94aa64fa

Comment 92

[Johnathan Nightingale [:johnath]]

(Restoring hardblocker status whiteboard)

Comment 93

[em28em28]

I've been lost here....
I'll point that because of this bug I had to downgrade from 4.0b11pre to 4.0b10 it is impossible to see urlbar like this.

I don't know if it is related to this bug, but there are two more annying regarding RTL :
- progress bar (on urlbar and on tabs) pointing RTL instead of LTR.
- extension that place thing on right sidebar (AIOS, Firefox Showcase) misses the important part, coz it gone far to the right.
 
May I suggest to leave it to the users to decide if they want fully UI RTL or some things should be left as before - At least let the user change it in about:config.

Comment 94

[Dão Gottwald [:dao]]

> - progress bar (on urlbar and on tabs) pointing RTL instead of LTR.

You're using the Status-4-Evar extension? If so, please report this to its author.

> - extension that place thing on right sidebar (AIOS, Firefox Showcase) misses
> the important part, coz it gone far to the right.

Ditto for these extensions.

Comment 95

[Aleksei Perepelkin [:chaos]]

With RTL-langpack ctrl+shift+x switches only after second key press then it works normally until next restart.

Comment 96

[Aleksei Perepelkin [:chaos]]

Sorry for my previous comment, wrong bug tab.

Comment 97

[Aleksei Perepelkin [:chaos]]

Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre

Comment 98

[RealName]

This is just awful, if it's not broken, don't fix it.
The way it was in beta10 was 100 times better, and if you're not gonna restore it to normal, at lesat PLEASE add an option to choose which way to align it.

Comment 99

[RealName]

From what I've concluded this wasn't fixed in b12.
Ah, I really hope this will be changed, I keep hearing too many complaints about that issue.

Comment 100

[Amir Aharoni]

I see no reason to force to be RTL a text field which is nearly always written in Latin characters right-to-left. It's possible that one day Middle Eastern URLs will be all right-to-left, but in the meantime they aren't. When i write an URL in Latin i want to see the text running from left to right. Even if it's RTL in Chrome and IE, it's still not a good reason to copy that unfortunate design decision to Firefox.

It's particularly frustrating that the Home and End keys put the cursor at the wrong end of the line. I know that a lot of people never use the Home and End keys, but some people do.

Comment 101

[Dima]

I also think that the URLs have to be on the left side.
Now, when the status bar is at the bottom of your browser, I don't see any reason to keep in on the right side.

Comment 102

[em28em28]

If it's not broken DON'T fix it !
There's an extension that fix your UI bugs -Status-4-evar.
The developer can't hold the speed u makes new bugs.
Relax, have a drink or two - u can rollback to b10 and everyone will be happy.

Comment 103

[RealName]

@Amir, for me the End key puts the cursor in the end of the sentence, and the home key puts it in the beginning of it.
(I do realize that for some keyboard layouts the Home button is in the left, and the End is in the right, so this can get kind of confusing, but it's still correct.. End - end, Home - beginning).

Anyway back on topic, as Amir said, this is one of these situations where copying IE/Chrome is a disaster.

Comment 104

[RealName]

any1 news? It's been 2 betas and 1 RC already..

Comment 105

[u279076]

(In reply to comment #104)
> any1 news? It's been 2 betas and 1 RC already..

This bug has been marked FIXED for some time. What you are asking for is basically to revert this bug. It's unlikely that will happen (especially for Firefox 4). Additionally, since this bug is verified fixed, it probably won't get a lot of attention.

I suggest you file a new bug as an enhancement to request this change -- that way you can state your reasons in a new bug and not have it diluted by anything on this bug. 

Thanks

Comment 106

[Tomer Cohen :tomer]

(In reply to comment #105)
> I suggest you file a new bug as an enhancement to request this change -- that
> way you can state your reasons in a new bug and not have it diluted by anything
> on this bug. 
⇒ bug 641238