Force urlbar to be left-to-right even when chrome is right-to-left




17 years ago
11 years ago


(Reporter: smontagu, Assigned: smontagu)


(Blocks 1 bug)


Firefox Tracking Flags

(Not tracked)



(2 attachments, 3 obsolete attachments)



17 years ago
When debugging problems with right-to-left chrome, I always find the
right-to-left urlbar annoying. Entering a URL in right-to-left direction creates
strange displays like 


which are technically correct, but confusing, and editing them can be awkward. I
think the urlbar should always be left-to-right.

Tsahi, do you agree? Do you think there are any other elements which should
always be left-to-right?

Comment 1

17 years ago
Posted patch Suggested patch v.1 (obsolete) — Splinter Review

Comment 2

17 years ago
i agree, for as long as there is no standard for non-english URLs. there is no
reason to have the url bar in rtl.

other places: Home page setting in Preferences dialog, Mail start page in
Preferences, Host Name in Directory Server Properties dialog in LDAP settings
(through Preferences), Add HTML/Plain Text Domain in Send Format preferences,
Link Properties dialog in Composer - Link Location field, automatic proxy
configuration URL in preferences/advanced.

i hope i didn't miss anything here..

Shosh: any other ideas?

Comment 3

17 years ago
another place that has URLs in it is the status bar, when the mouse hovers over
a link or during page loading. but this area also contains strings like "getting
data from...", connecting to..." etc., so here it can be more complicated.

Comment 4

17 years ago
Posted patch Add a bunch more cases (obsolete) — Splinter Review
... and I thought this was going to be a one-line fix! This patch forces LTR in
the following cases:
 Open Location dialog
 Home page location in Prefs | Navigator
 File extension, MIME type and Application in Prefs | Helper Applications
 Email address for anonymous FTP password in Prefs | Advanced
 Disk Cache Folder in Prefs | Cache
 Proxies, No Proxy for and URL in Prefs | Proxies

 Background Image in New Page Settings
 Filename and Site subdirectory (x 2) in Publish
 Publishing address and HTTP addres in Publish | Settings
 Background Image in Format | Page Colors and Background
 Link Location in Insert | Link
 Image Location in Insert | Image
 HTML Source in Insert | HTML
 Email address fields when composing a message
 Email, Additional Email and Web Page (x 2) in Address Book
 Email Address, Incoming Server, SMTP Server, and News Server in Account Wizard

 Email Address, Reply-to Address, and Signature in Account Settings | Main
 Bcc address in Account Settings | Copies
 Server Name and Local directory in Account Settings | Server Settings
 Local directory in Account Settings | Local Folders
 SMTP server in Account Settings | Advanced
 Mail Start Page in Preferences
 Hostname, Base DN and Bind DN in Directory Server Properties
Attachment #91404 - Attachment is obsolete: true

Comment 5

17 years ago
>Email address fields when composing a message

a user can also enter the nick name of the recipient, which could be in hebrew,
so i'm not sure about this one. you should also make sure that the To:/Cc:/Bcc:
drop down remains on the right side of the addressing area.

Comment 6

17 years ago
Outlooks express does that. However, one of the most common questions is 'how do
i turn it off". so I am not sure it is such a good idea.
The best solution would be to go by the first chracters: rtl if it is hebrew,
ltr if it is roman

Comment 7

17 years ago
The proper fix IMHO to be adding a new CSS class to the chrome, named
"hostInput" or "urlInput" and assign it to all such input boxes, with the CSS
rule "rtl:direction !important".

A temporary solution would be adding:
.urlbar { direction:rtl !important; }
to ~/.mozilla/profile/*/chrome/userChrome.css

Comment 8

17 years ago
i tried this on mozilla 1.0.0, and it had no effect.

Comment 9

17 years ago
Whoops -- make that:
#urlbar { direction:ltr !important; }

Notice "ltr" and not "rtl" -- "rtl" was obviously a mistake. Also, the
"rtl:direction" is a mistake too. Don't know how I ended up writing something
that messed up :)

Comment 10

17 years ago
this works better :) it also works when i put it in intl.css in the language
pack, so if such a solution can be applied to all places that need it, that were
mentioned above, it will satisfy me.

one problem with it: it also affects the "search from the address bar" feature.
when the user enters some text at the address bar, he gets a drop down menu with
an option to search the text in his default search engine (if enabled). the line
there is
"Search %S for "%S" "
where the first %S takes the engine's name, and the second taked the text. when
translated to RTL language, since this is left in LTR, i have to write the text
backwards (i.e. first the first %S, then the word for "at", then the second %S,
and then the word for "search"). the result is that the strings for the text and
the engine's name are in a reversed order comparing to the english version.

however, as i wrote, it can be worked around, and the user won't know about it
at all.

Comment 11

17 years ago
You want it not to apply to the "Search %s for %s" menu item?
Make that
#urlbar .autocomplete-search-engine
direction:rtl !important;

(or you can make it the opposite -- make it match only the URL bar, the history
dropdown list and the autocompletion URL items)

You can find all those CSS classes and IDs via the DOM Inspector. Simply do:
1. File > Inspect a window > the browser's window.
2. Search > Select element by click
3. Click on the URL bar.
and explore the tree from there. It's pretty self-descriptive, and you can apply
style rules on the nodes to see how they react (you need to open new browser
windows to see the changes in effect)

Comment 12

17 years ago
kewl, this works fine. now Mozilla behaves better than IE in this respect :)

now we have to find a solution to all other places Simon found. can CSS be
applied to them too? it looks like an easier solution (and quicker, considering
the time it takes to resolve a bug here) than a patch to the tree.

Comment 13

17 years ago
You can do it yourself with DOM Inspector, though that'll require you to be
fairly familiar with CSS.

The correct solution for this would be adding a "hostname-input-box" (we have
hostnames too - like in Mail Accounts prefs - not just URLs) class and having
that class apply on all the relevant input boxes.
That'll require a patch to Mozilla, of course.

Comment 14

17 years ago
That is pretty much what attachment 91882 [details] [diff] [review] does. I agree that something like
"hostname-input-box" is a better name for the class than my "forceLTR".

Doing it this way is probably too heavy-handed, because of cases like nicknames
for email addresses, right-to=left IRIs (potentially) and right-to-left volume
names on Macs. However, I think left-to-right remains the correct default, and
those cases will be less of a problem when bug 98160 gets fixed.

Comment 15

17 years ago
so are you waiting until bug 98160 is fixed before fixing this one?

Comment 16

17 years ago
Since everyone asks about RTL IRIs, let me note that the current draft of the
standard says:

:Bidirectional IRIs MUST be rendered visually by rendering each component and
each :structural character from left to right. They MUST render each component
according :to its natural direction (i.e. left-to-right for components with
left-to-right :characters, right-to-left for components with right-to-left

|direction: ltr;| will conform to this.

Comment 17

17 years ago
I have changed the class name to "URIElement", and also moved the changes to
xul.css to the top of the patch to make it more readable.
Attachment #91882 - Attachment is obsolete: true

Comment 18

17 years ago
Comment on attachment 100943 [details] [diff] [review]
New patch with cosmetic changes

We generally use this convention for class names "uri-element"

Comment 19

17 years ago
Attachment #100943 - Attachment is obsolete: true

Comment 20

17 years ago
Comment on attachment 101178 [details] [diff] [review]
Changed class name to "uri-element"

Attachment #101178 - Flags: superreview+
Comment on attachment 101178 [details] [diff] [review]
Changed class name to "uri-element"

Attachment #101178 - Flags: review+

Comment 22

17 years ago
Checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 23

16 years ago
i tried to use this css class in my upcoming language pack for mozilla 1.3, and
it works pretty well. however, i didn't notice at the time that in your list
(comment 4) you missed the Add HTML/Plain Text Domain in Send Format preferences
(comment 2), so this one is still in RTL. so it would be great if you could add
the class to this one as well.

please reopen.

Comment 24

16 years ago
There seem to be two problems: the "Plain Text Domains" and "HTML Domains"
listboxes, and the dialog that comes up when pressing Add for either one of
them. The first is no problem, but the second is tricky, because it's not XUL
but dynamically created by nsIPromptService.

Comment 25

16 years ago
My last comment is not quite right: the dialog is XUL, defined in
xpfe/global/resources/content/commonDialog.xul. That still leaves the problem of
how to set the style on the textbox for a particular invocation. 

Comment 26

16 years ago
btw, i noticed that the search from the address bar (comment 10) also turnes LTR
now, so comment 11 still needs to be implemented.

Comment 27

16 years ago
found another one: File>Page Setup>Margins and Header/Footer tab>custum footer
(at the drop-down menues). all the codes there are in latin characters, so
shouldn't the field be LTR? on the one side, when you enter something like "&P",
it becomes "P&". but on the other hand, won't the data be printed RTL, so making
the input field LTR might confuse the users?

Comment 28

16 years ago
I say: since the Custom Footer Language (consisting of all kinds of funny 
symbol sequences) is a left-to-right language (just as C++ is a left-to-right 
language), we should display it left-to-right always. Fill out a bug to make 
its direction:ltr in the main CSS. 
In addition, I suggest opening a UI bug "Printing header/footer should be 
WYSIWYG-editable". It should call for replacing the Custom Footer Language 
"hack" with an embedded Composer WYSIWYG editor. In this editor, automatic 
text (such as "Current Page") should be represented by an XML tag, insertable 
via a menu (Insert > Automatic text > Page number) and visually be represented 
as an inline element, e.g.: 
Author: <AUTOTEXT TYPE="author"/> Page: <AUTOTEXT TYPE="pageNumber"/> 
would be drawn as: 
Author: <SPAN STYLE="border:1px outset">Author</SPAN> Page: <SPAN 
STYLE="border:1px outset">Page Number</SPAN> 
("Author" and "Page Number" should be localizable strings.) 

Comment 29

16 years ago
and another one:
bookmarks manager: file|new|bookmark, the location field,
edit|properties... again, the location field.

Comment 30

16 years ago
and yet another one: form manager>URL specific (at the bottom)>URL and Field

Comment 31

16 years ago
and newsgroup properties

Comment 32

16 years ago
i suggest to reopen to add at least some of the other fields reported.

Comment 33

16 years ago
this bug was fixed. if you have other fields you want changed then you should
file other bugs for them against the appropriate products/components.


16 years ago
Blocks: 219070


16 years ago
Depends on: 220934


16 years ago
No longer depends on: 220934
Comment on attachment 167149 [details] [diff] [review]
port to toolkit (checked in)

while firefox does not make use of this class, thunderbird does in some places

(this patch only affects xul.css)
Attachment #167149 - Flags: review?(mconnor)
Attachment #167149 - Flags: review?(mconnor) → review+
Comment on attachment 167149 [details] [diff] [review]
port to toolkit (checked in)

toolkit port checked in.
Attachment #167149 - Attachment description: port to toolkit → port to toolkit (checked in)


11 years ago
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.