350611 - RTL Address-bar

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Behnam Esfahbod [:zwnj]]

Current solution in intl.css causes the drop-down button goes on the right side, which is not like the LTR case.

Mano suggested to use:

#urlbar > hbox > .textbox-input-box, #urlbar > hbox > .autocomplete-result-popupset { direction: ltr !important; }

[the .autocomplete... one doesn't work]

The popupset should be set RTL, as the scrollbar of popupset should be on the left side, just under the drop-down button.  But it makes another problem, which is the suggested URL (first column) will goes on the left, but that's better to be on the right (between the scrollbar and title column) to be just under the typed URL.

I'm going to attach the screenshot with Mano's suggestion

Comment 1

[Behnam Esfahbod [:zwnj]]

Attachment: Address-bar [fa-IR], with Mano's suggestion for #urlbar

Note that the order of two columns of popupset should remain LTR.

Comment 2

[Reuven Gonen]

did this get broken in version 2.0?

in the Hebrew version of 1.5.0.6 it seems to be completly ok.
you can see a screenshot at:

http://www.mozilla.org.il/images/classic-1.5-toolbar.png

Comment 3

[Behnam Esfahbod [:zwnj]]

NewTheme's look of "Go" button deeply depends on the drop-down button, which is currently on the right side.  It's much better to move it to the left side.

Comment 4

[Asaf Romano (gone)]

I'm going to fix this in Winstripe, #urlbar { direction: ltr; } and similar autocomplete rules should be removed from RTLish intl.css files.

Comment 5

[Asaf Romano (gone)]

Attachment: patch

A side-effect of this patch is a LTR autocomplete in the searchbar. I'm not going to fix that here because:
 * We've shipped Fx1.x HE with the same issue.
 * This probably hides some RTL tress bug (see bug 140759 in particular).
 * To fix this, we need to separate the autocomplete popups, this is not doable for 2.0 at the very least.

Comment 6

[Tsahi Asher]

if it's going to look like the screen shot (attachement 235942) then i think it's a bad idea. you don't want people to have to move the mouse across the screen to get from the drop marker to the scroll bar. and i think the favicon should be right where it was, behind the url, so the association between them is clear.

i other words, the way it was in FF 1.5 was just fine IMO.

Comment 7

[Mike Connor [:mconnor]]

not a blocker, would take patch (and will review!)

Comment 8

[Asaf Romano (gone)]

Real screenshot coming.

Comment 9

[Asaf Romano (gone)]

Attachment: screenshot

Comment 10

[Asaf Romano (gone)]

Attachment: put the scrollbar under the dropmarker

Comment 11

[Asaf Romano (gone)]

Attachment: screenshot

Comment 12

[Behnam Esfahbod [:zwnj]]

Thanks Mano, the last shot looks perfect.

Comment 13

[Mike Connor [:mconnor]]

Comment on attachment 236285 [details] [diff] [review]
put the scrollbar under the dropmarker

r=me, thanks

a=mconnor on behalf of drivers for 1.8 branch checkin

Comment 14

[Asaf Romano (gone)]

mozilla/browser/base/content/browser.xul 1.268.2.62
mozilla/browser/themes/winstripe/browser/browser.css 1.17.2.51

Comment 15

[Peter Kasting]

Can this bug be RESOLVED FIXED, or is the trunk currently broken?

Comment 16

[Asaf Romano (gone)]

I need to check-in the browser.xul part on trunk first.

Comment 17

[Asaf Romano (gone)]

browser.xul part landed on trunk:
mozilla/browser/base/content/browser.xul 1.321

Comment 18

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).