Closed Bug 350611 Opened 14 years ago Closed 13 years ago

RTL Address-bar

Categories

(Firefox :: Address Bar, defect, P2)

2.0 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 2

People

(Reporter: zwnj, Assigned: mano)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8.1, l12y, rtl, Whiteboard: [Fx2 theme change])

Attachments

(2 files, 3 obsolete files)

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
Note that the order of two columns of popupset should remain LTR.
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
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.
I'm going to fix this in Winstripe, #urlbar { direction: ltr; } and similar autocomplete rules should be removed from RTLish intl.css files.
Assignee: tsahi_75 → bugs.mano
Component: he-IL / Hebrew → Location Bar and Autocomplete
OS: Linux → All
Product: Mozilla Localizations → Firefox
QA Contact: linxspider → location.bar
Target Milestone: mozilla1.8final → Firefox 2
Version: unspecified → 2.0 Branch
Status: NEW → ASSIGNED
Flags: blocking-firefox2?
Priority: -- → P2
Attached patch patch (obsolete) — Splinter Review
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.
Attachment #235942 - Attachment is obsolete: true
Attachment #236200 - Flags: review?(mconnor)
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.
not a blocker, would take patch (and will review!)
Flags: blocking-firefox2? → blocking-firefox2-
Attachment #236200 - Flags: review?(mconnor) → review+
Whiteboard: [Fx2 theme change]
Attachment #236200 - Attachment is obsolete: true
Attachment #236249 - Attachment is obsolete: true
Attachment #236285 - Flags: review?(mconnor)
Attachment #236200 - Flags: approval1.8.1?
Thanks Mano, the last shot looks perfect.
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
Attachment #236285 - Flags: review?(mconnor)
Attachment #236285 - Flags: review+
Attachment #236285 - Flags: approval1.8.1+
mozilla/browser/base/content/browser.xul 1.268.2.62
mozilla/browser/themes/winstripe/browser/browser.css 1.17.2.51
Keywords: fixed1.8.1
Can this bug be RESOLVED FIXED, or is the trunk currently broken?
I need to check-in the browser.xul part on trunk first.
Blocks: fx20-he
browser.xul part landed on trunk:
mozilla/browser/base/content/browser.xul 1.321
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
You need to log in before you can comment on or make changes to this bug.