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

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Simon Montagu :smontagu]

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 

 /http://www.mozilla.org

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

[Simon Montagu :smontagu]

Attachment: Suggested patch v.1

Comment 2

[Tsahi Asher]

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

[Tsahi Asher]

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

[Simon Montagu :smontagu]

Attachment: Add a bunch more cases

... and I thought this was going to be a one-line fix! This patch forces LTR in
the following cases:
 
Navigator:
 URLbar
 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

Composer:
 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
 
Mailnews:
 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

Comment 5

[Tsahi Asher]

>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

[Shoshannah Forbes]

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

[Ilya Konstantinov]

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

[Tsahi Asher]

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

Comment 9

[Ilya Konstantinov]

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

[Tsahi Asher]

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

[Ilya Konstantinov]

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

[Tsahi Asher]

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

[Ilya Konstantinov]

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

[Simon Montagu :smontagu]

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

[Tsahi Asher]

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

Comment 16

[Simon Montagu :smontagu]

Since everyone asks about RTL IRIs, let me note that the current draft of the
standard http://www.w3.org/International/iri-edit/draft-duerst-iri.html#visual 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
characters).

|direction: ltr;| will conform to this.

Comment 17

[Simon Montagu :smontagu]

Attachment: New patch with cosmetic changes

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.

Comment 18

[Joe Hewitt (gone)]

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

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

Comment 19

[Simon Montagu :smontagu]

Attachment: Changed class name to "uri-element"

Comment 20

[Joe Hewitt (gone)]

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

sr=hewitt

Comment 21

[jag (Peter Annema)]

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

r=jag

Comment 22

[Simon Montagu :smontagu]

Checked in.

Comment 23

[Tsahi Asher]

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

[Simon Montagu :smontagu]

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

[Simon Montagu :smontagu]

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

[Tsahi Asher]

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

[Tsahi Asher]

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

[Ilya Konstantinov]

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

[Tsahi Asher]

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

Comment 30

[Tsahi Asher]

and yet another one: form manager>URL specific (at the bottom)>URL and Field
columns.

Comment 31

[Tsahi Asher]

and newsgroup properties

Comment 32

[Tsahi Asher]

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

Comment 33

[timeless]

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.

Comment 34

[Tsahi Asher]

see bug 213727, bug 213735, bug 213738, and bug 213742.

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: port to toolkit (checked in)

Comment 36

[Christian :Biesinger (don't email me, ping me on IRC)]

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)

Comment 37

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 167149 [details] [diff] [review]
port to toolkit (checked in)

toolkit port checked in.