Closed Bug 157607 Opened 18 years ago Closed 17 years ago

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

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: smontagu, Assigned: smontagu)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 3 obsolete files)

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?
Attached patch Suggested patch v.1 (obsolete) — Splinter Review
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?
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.
Attached 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:
 
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
Attachment #91404 - Attachment is obsolete: true
>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.
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
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
i tried this on mozilla 1.0.0, and it had no effect.
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 :)
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.
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)
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.
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.
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.
so are you waiting until bug 98160 is fixed before fixing this one?
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.
Attached patch New patch with cosmetic changes (obsolete) — Splinter Review
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 on attachment 100943 [details] [diff] [review]
New patch with cosmetic changes

We generally use this convention for class names "uri-element"
Attachment #100943 - Attachment is obsolete: true
Comment on attachment 101178 [details] [diff] [review]
Changed class name to "uri-element"

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

r=jag
Attachment #101178 - Flags: review+
Checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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.
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.
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. 
btw, i noticed that the search from the address bar (comment 10) also turnes LTR
now, so comment 11 still needs to be implemented.
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?
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.) 
 
and another one:
bookmarks manager: file|new|bookmark, the location field,
edit|properties... again, the location field.
and yet another one: form manager>URL specific (at the bottom)>URL and Field
columns.
and newsgroup properties
i suggest to reopen to add at least some of the other fields reported.
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.
Blocks: 219070
Depends on: 220934
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)
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.