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

RESOLVED FIXED

Status

()

Core
Layout: Text
RESOLVED FIXED
15 years ago
9 years ago

People

(Reporter: smontagu, Assigned: smontagu)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Assignee)

Description

15 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 

 /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?
(Assignee)

Comment 1

15 years ago
Created attachment 91404 [details] [diff] [review]
Suggested patch v.1

Comment 2

15 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

15 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.
(Assignee)

Comment 4

15 years ago
Created attachment 91882 [details] [diff] [review]
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
Attachment #91404 - Attachment is obsolete: true

Comment 5

15 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

15 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

15 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

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

Comment 9

15 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

15 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

15 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

15 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

15 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.
(Assignee)

Comment 14

15 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

15 years ago
so are you waiting until bug 98160 is fixed before fixing this one?
(Assignee)

Comment 16

15 years ago
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.
(Assignee)

Comment 17

15 years ago
Created attachment 100943 [details] [diff] [review]
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.
Attachment #91882 - Attachment is obsolete: true

Comment 18

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

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

Comment 19

15 years ago
Created attachment 101178 [details] [diff] [review]
Changed class name to "uri-element"
Attachment #100943 - Attachment is obsolete: true

Comment 20

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

sr=hewitt
Attachment #101178 - Flags: superreview+

Comment 21

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

r=jag
Attachment #101178 - Flags: review+
(Assignee)

Comment 22

15 years ago
Checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 23

15 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.
(Assignee)

Comment 24

15 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.
(Assignee)

Comment 25

15 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

15 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

14 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

14 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

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

Comment 30

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

Comment 31

14 years ago
and newsgroup properties

Comment 32

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

Comment 33

14 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.

Comment 34

14 years ago
see bug 213727, bug 213735, bug 213738, and bug 213742.

Updated

14 years ago
Blocks: 219070

Updated

14 years ago
Depends on: 220934

Updated

14 years ago
No longer depends on: 220934
Created attachment 167149 [details] [diff] [review]
port to toolkit (checked in)
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)

Updated

13 years ago
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)

Updated

9 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.