993806 - URL Bar text alignment in RTL mode

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[Yaron]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Aligning the URL bar text to the right in RTL mode makes no sense; - we hardly ever use non-Latin characters in that bar.



Expected results:

Default alignment to the left.

Comment 1

[(no longer active)]

Need-infoing myself to remember to look at this tomorrow.

Comment 2

[(no longer active)]

Yaron, one question.  Do you ever find yourself typing something in Hebrew in the location bar directly in order to search for it?  If I remember correctly, the last time we discussed this, that was the reason why we decided to make the location bar right aligned.

Comment 3

[(no longer active)]

Simon, do you think it makes sense to make the URL bar dir="auto" and remove the explicit text-align on it?

Comment 4

[Yaron]

Ehasan,

I personally never use Hebrew in the URL bar.
In the Firefox Hebrew forum, aligning the text to the left is a common request.

Comment 5

[(no longer active)]

(In reply to comment #4)
> Ehasan,
> 
> I personally never use Hebrew in the URL bar.

OK, but I think we should try to solve that problem too.

> In the Firefox Hebrew forum, aligning the text to the left is a common request.

Understood.  My suggestion in comment 3 will give us best of both worlds I think.  It will make the URL bar left aligned normally but will make it right alined if you start typing Hebrew text in it.

Comment 6

[Yaron]

That would be great!

Comment 7

[Simon Montagu :smontagu]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #3)
> Simon, do you think it makes sense to make the URL bar dir="auto" and remove
> the explicit text-align on it?

Yes, but it's a little more complicated than that because ideally we need to fix the autocomplete dropdown as well. If you think that just fixing the URL bar is enough, I have a patch in my tree that does just that.

Comment 8

[Simon Montagu :smontagu]

Attachment: Give the URL bar dir=auto

Comment 9

[(no longer active)]

(In reply to Simon Montagu :smontagu from comment #7)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #3)
> > Simon, do you think it makes sense to make the URL bar dir="auto" and remove
> > the explicit text-align on it?
> 
> Yes, but it's a little more complicated than that because ideally we need to
> fix the autocomplete dropdown as well. If you think that just fixing the URL
> bar is enough, I have a patch in my tree that does just that.

I _think_ that's good enough, yes, but can you please post some screenshots of what the location bar will look like in RTL/LTR mode with the dropdown visible after this patch?  Thanks!

Comment 10

[Tomer Cohen :tomer]

(In reply to Yaron from comment #4)
> I personally never use Hebrew in the URL bar.
> In the Firefox Hebrew forum, aligning the text to the left is a common
> request.

Personally speaking I don't like the idea of having right-aligned English text in the location bar, and I try to change the alignment back to the left every time I start the browser. For unknown reasons ctrl-shift-x isn't working for me recently on the browser chrome but on the content area (I am on Aurora/Linux and this problem first occur to me months ago, not sure if it reproduce to other users as well), so sadly I am starting to get used to ignoring its alignment. 

As for our forum, I am not sure what Yaron is talking about. The location bar alignment problem was asked once or twice, few people were concerned, but please don't get the idea that this is the most high priority problem to us. We have enough bugs in the RTL UI for everyone, and these bugs are not just cosmetic problems but broken features (for example, check out the Network Panel on RTL builds…). 

Since the world is going into an area of having full URIs in any language, including some RTL languages, I think that we should not hard-code the location bar direction any more, and go with the dir=auto solution. I can't provide real-world demonstration of full URI in Hebrew, but as far as I know there is some usage of such addresses in Arabic speaking countries, even though it is very rare. Also, having dir=auto enabled could be helpful to users who tend to type search keywords in the location bar.

Comment 11

[(no longer active)]

That is actually a good point.  Simon, if you're looking for some example URLs, check out the table on http://www.nic.ir/Example-Dot-Test.

Comment 12

[Tomer Cohen :tomer]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #11)
> That is actually a good point.  Simon, if you're looking for some example
> URLs, check out the table on http://www.nic.ir/Example-Dot-Test.

As far as I know, these testing TLDs were shutdown about a month ago. Currently these addresses doesn't resolve, so the error message is shown in the browser after it try to manually inject a www subdomain, which could mess-up the general idea because an address that has LTR subdomain should be shown as LTR because this is how the current dir=auto implementation works (LTR characters before RTL). 

Do you know of an Arabic-speaking country which have activated their gTLD? https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains#Internationalized_country_code_top-level_domains

Comment 13

[(no longer active)]

(In reply to Tomer Cohen :tomer from comment #12)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #11)
> > That is actually a good point.  Simon, if you're looking for some example
> > URLs, check out the table on http://www.nic.ir/Example-Dot-Test.
> 
> As far as I know, these testing TLDs were shutdown about a month ago.
> Currently these addresses doesn't resolve, so the error message is shown in
> the browser after it try to manually inject a www subdomain, which could
> mess-up the general idea because an address that has LTR subdomain should be
> shown as LTR because this is how the current dir=auto implementation works
> (LTR characters before RTL). 

Sure, but that should be enough for testing purposes, right?

> Do you know of an Arabic-speaking country which have activated their gTLD?
> https://en.wikipedia.org/wiki/List_of_Internet_top-
> level_domains#Internationalized_country_code_top-level_domains

Not really, sorry.  Perhaps Gerv knows?

Comment 14

[Tomer Cohen :tomer]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #13)
> > As far as I know, these testing TLDs were shutdown about a month ago.
> Sure, but that should be enough for testing purposes, right?
Only if you are going to manually configure your /etc/hosts file to resolve such addresses, so the browser won't prefix it with www when showing the error message. It is possible and not very difficult to configure, but please note that it will require the same manual configuration for everyone who might be interested in testing this feature. 

Also please note that since there is no use for these testing TLDs any more, I guess they'd be removed from the browser list of IDN-enabled TLDs sooner or later.

Comment 15

[Tomer Cohen :tomer]

http://nic.شبكة allow domain registration under .شبكة, and these seems to resolve well by modern browsers. A Google search for site:.شبكة gives some results of currently established sites we can use in order to test this scenario.

Comment 16

[(no longer active)]

Great, thanks Tomer!

Comment 17

[Yaron]

https://bugzilla.mozilla.org/show_bug.cgi?id=641238

Tomer Cohen :tomer 2011-04-25 16:13:17 PDT

We are weeks from the next release, and this issue is one of the top local feedbacks we got about the Firefox 4.0 release.

*

https://bugzilla.mozilla.org/show_bug.cgi?id=979653

Comment 18

[Simon Montagu :smontagu]

Finding the right thing to do with all the possible usages of the location bar and the drop-down is hard, and RTL domain names make it harder. Mixed direction domain names make it harder still.

The standard "direction from first strong directional character" that dir=auto uses is not ideal for URIs: why should إكسون-موبيل-مصر.com have a different directionality from www.إكسون-موبيل-مصر.com, for example?

RTL display for mixed direction URIs is highly confusing and could possibly be used for spoofing, since the domain can end up non-contiguous. Another example from the same site (with RLE to simulate the auto-RTL display):

إكسون-موبيل-مصر.com/Egypt-Arabic/PA/default.aspx

Just looking at that makes me feel dizzy.

(These two are relatively new issues, by the way, since we stopped displaying the URI scheme in the location bar. In the past the "http://" ensured that URIs always had an LTR first strong character).

Comment 19

[Gervase Markham [:gerv]]

(In reply to Simon Montagu :smontagu from comment #18)
> (These two are relatively new issues, by the way, since we stopped
> displaying the URI scheme in the location bar. In the past the "http://"
> ensured that URIs always had an LTR first strong character).

Can we insert a LTR_FORCING_NON_BREAKING_ZERO_WIDTH_SPACE or equivalent character, to regain the same effect?

Interestingly, your example looks different in my Bugzilla email in Thunderbird than it does in the web page! In Thunderbird it's:

com/Egypt-Arabic/PA/default.aspx.<arabic-here>

Above, in the web page, it's:

<arabic-here>.com/Egypt-Arabic/PA/default.aspx

Gerv

Comment 20

[Simon Montagu :smontagu]

(In reply to Gervase Markham [:gerv] from comment #19)
> Interestingly, your example looks different in my Bugzilla email in
> Thunderbird than it does in the web page! In Thunderbird it's:
> 
> com/Egypt-Arabic/PA/default.aspx.<arabic-here>
> 
> Above, in the web page, it's:
> 
> <arabic-here>.com/Egypt-Arabic/PA/default.aspx

That is indeed interesting! In the text box when I was typing it, it appeared as in your first example from Thunderbird, and that is what I intended. In the web page I see the same as you. I don't see the RLE (U+202B) in the page source either. I didn't know that bugzilla strips control characters from comments (though it can often be good policy to do so!)

Comment 21

[Gervase Markham [:gerv]]

Bug 405011 comment 2 suggests we do, although I don't know where the code is.

Gerv

Comment 22

[Simon Montagu :smontagu]

(In reply to Gervase Markham [:gerv] from comment #19)
> Can we insert a LTR_FORCING_NON_BREAKING_ZERO_WIDTH_SPACE or equivalent
> character, to regain the same effect?

U+200E LEFT-TO-RIGHT mark has the characteristics you list :) I don't know anything about the code that fixes up URIs for location bar display, so I can't answer the question beyond that fact.

Comment 23

[Dão Gottwald [:dao]]

(In reply to Simon Montagu :smontagu from comment #22)
> (In reply to Gervase Markham [:gerv] from comment #19)
> > Can we insert a LTR_FORCING_NON_BREAKING_ZERO_WIDTH_SPACE or equivalent
> > character, to regain the same effect?
> 
> U+200E LEFT-TO-RIGHT mark has the characteristics you list :) I don't know
> anything about the code that fixes up URIs for location bar display, so I
> can't answer the question beyond that fact.

I think we can do that, yes.

Comment 24

[(no longer active)]

(In reply to comment #23)
> (In reply to Simon Montagu :smontagu from comment #22)
> > (In reply to Gervase Markham [:gerv] from comment #19)
> > > Can we insert a LTR_FORCING_NON_BREAKING_ZERO_WIDTH_SPACE or equivalent
> > > character, to regain the same effect?
> > 
> > U+200E LEFT-TO-RIGHT mark has the characteristics you list :) I don't know
> > anything about the code that fixes up URIs for location bar display, so I
> > can't answer the question beyond that fact.
> 
> I think we can do that, yes.

That sounds good to me, too!

Comment 25

[Tomer Cohen :tomer]

(In reply to Simon Montagu :smontagu from comment #18)
> The standard "direction from first strong directional character" that
> dir=auto uses is not ideal for URIs: why should إكسون-موبيل-مصر.com have a
> different directionality from www.إكسون-موبيل-مصر.com, for example?
If so, direction should be set by the first strong letter in the domain part and not any subdomain. We could use the public suffix list to find out the domain part of every address, which we already doing by using a stronger text in the location bar (since Firefox 4.0 or so). 

> RTL display for mixed direction URIs is highly confusing and could possibly
> be used for spoofing, since the domain can end up non-contiguous. Another
> example from the same site (with RLE to simulate the auto-RTL display):
See bug 525831 for the spoofing issue. ☺

Comment 26

[Simon Montagu :smontagu]

So we could insert the LEFT-TO-RIGHT MARK in trimURL in browser/base/content/utilityOverlay.js? Where would we strip it again so that it doesn't appear when copying from the location bar, or editing the URI in place?

Comment 27

[Gervase Markham [:gerv]]

I think there might be value in including it in text copied from the bar, just like we include "http(s)" silently. At least, it's worth testing the ramifications of doing so.

Not doing so might lead to confusion as someone copies and pastes a URL and what is pasted is very different to what they thought they copied.

Gerv

Comment 28

[Simon Montagu :smontagu]

(In reply to Gervase Markham [:gerv] from comment #27)
> I think there might be value in including it in text copied from the bar,
> just like we include "http(s)" silently. At least, it's worth testing the
> ramifications of doing so.

But what if someone copies and pastes from the bar to another browser tab? The URL with added LRM won't resolve.
 
> Not doing so might lead to confusion as someone copies and pastes a URL and
> what is pasted is very different to what they thought they copied.

Since, as you mention, we reinclude the stripped "http" when copying, removing the LRM shouldn't change the bidi resolution of the copied text.

Comment 29

[(no longer active)]

(In reply to Simon Montagu :smontagu from comment #28)
> (In reply to Gervase Markham [:gerv] from comment #27)
> > I think there might be value in including it in text copied from the bar,
> > just like we include "http(s)" silently. At least, it's worth testing the
> > ramifications of doing so.
> 
> But what if someone copies and pastes from the bar to another browser tab?
> The URL with added LRM won't resolve.

Yeah I don't think we should include any invisible control chars automagically when copying the URL to the clipboard.

> > Not doing so might lead to confusion as someone copies and pastes a URL and
> > what is pasted is very different to what they thought they copied.
> 
> Since, as you mention, we reinclude the stripped "http" when copying,
> removing the LRM shouldn't change the bidi resolution of the copied text.

Indeed.

Comment 30

[(no longer active)]

Simon, what happened here?  Are you still interested in finishing the patch?  :-)

Comment 31

[Amir Farsi]

Hi Ehsan and all of followers, But you forgot the IDN(International Domain Names). 
The Perrsian IDN started by IrNic(www.nic.ir) officially. 
Now all Web browsers supports the IDN. 

The IDN of Iran is .ایران as result you may have http://www.موزیلا.ایران or http://www.سنجش.ایران 
Also Arabic countries started IDN. Although I think IDN for RTL languages is not useful. Because part of URL(http://www) is LTR and another part of URL is RTL(like http://www.آزمایشی.ایران) 

Microsoft have a very good solution for this thing. Microsoft Edge(The new browser of Microsoft), have smart address bar. When you type a RTL address, it is RTL when yopu type a classic LTR address, it is LTR! 
Yes, I think this solution is better than Only LTR address bar. 

What is your opinion?

Comment 32

[Tomer Cohen :tomer]

Please note that domains that contain only RTL characters can be used for phishing by directing users to different domain than they thought they are going to, thus can be considered as a security risk (see bug 525831). 

In my opinion, URLs should be displayed as most file managers display the file path these days. The whole path is replaced by clickable links, so users could be easily navigate upward (see below [1]). By replacing the URL with a graphical representation, and could be easier to deal with such cases. 

[1] Example for clickable URL:
http://example.com/path/to/page.html should be displayed as - 

http://<strong><a href="/">example.com</a></strong> / <a href="../..">path</a> / <a href="..">to</a> / page.html

In order to make sure that make sure that it'd be displayed well on RTL, we'd just have to add unicode-bidi:isolate to every element of the the URL. 

As for RTL addresses, these should be displayed as RTL only if the URL is indeed RTL. I guess that people who maintain sites on an RTL domains (and not just redirect visitors to an LTR domains) will be interested in having the URL displayed from the right to the left, while it doesn't make sense at all if the URL is indeed LTR to others.

Comment 33

[Amir Farsi]

Attachment: Microsoft Edge RTL Url ScreenShot

This is the screen shot of Microsoft Edge when I entered an RTL URL in Persian(Farsi) language.
Please compare it with Firefox in Next Comment

Comment 34

[Amir Farsi]

Attachment: Firefox RTL URL in Address Bar

This is screen shot of Firefox address bar when I entered a RTL URL in Persian(Farsi) language.
Also you can see the information about DotIran(ایران.) TLD in this screenshot.
Note: That site which you can see in this screenshot, isn't related to that URL enters. The site address is www.nic.ir (Iranian NIC for DotIR(LTR and English) and DotIran(RTL and Persian).

Comment 35

[Amir Farsi]

Hi again.
In my opinion have an address bar which can be RTL, its necessary. Because the address bar isn't only for entering URLS! The address bar is a search engine also(Connected to default browser search engine. This means if you entered a word or phrase in adress bar of browser, the browser will redirect to a search engine(Like Google, Yahoo!, Bing), then shwos search engine results about that word or phrase.
It shows if the word or phrase which entered in address bar is RTL, the address bar direction should be RTL. This event for search Engine Bar in Firefox also should be happened, although that Firefox UI isn't Persian or a RTL language. May be I create a new bug for it.

Also I want say if some of RTL domains used for non secure websites and harmful actions, we can't say all of the RTL URLS are bad reasons. It is like we say because those people of a country/city which we saw them in our travel was bad, then fundamentally all of that country/city citizens are bad!

I want to share the screenshot of Microsoft Edge and Firefox URL bars when I entered Persian(Farsi) language URL in them. You can see that screenshots in attachment of my comments(Comment 33 and 34) and Top of this Bug in attachments section.

Thanks for your attention.

Comment 36

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.