Suggested URL in the Awesomebar should appear as LTR in RTL languages

RESOLVED INVALID

Status

()

Firefox
Address Bar
RESOLVED INVALID
2 years ago
a year ago

People

(Reporter: Itiel, Unassigned)

Tracking

({rtl})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8745009 [details]
image of the issue.png

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

1. Install Firefox RTL version (e.g. Hebrew or Arabic) with a clean profile
2. In the awesomebar, start typing (in my example it's 'q')


Actual results:

The first suggestion (the "Search with Google" one) should be RTL'd.
Currently it's meaning in hebrew would be "Google Search with - q"


Expected results:

The first suggestion (the "Search with Google" one) should be RTL'd

Image attached.
(Reporter)

Updated

2 years ago
Summary: RTL issue in the Awesome Bar → "Search with" suggestion result in the Awesomebar is not RTL'd in RTL languages
(Reporter)

Comment 1

2 years ago
Related: bug 1267360

Updated

2 years ago
Keywords: rtl

Updated

2 years ago
Component: Untriaged → Location Bar

Updated

2 years ago
Blocks: 1262507
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

2 years ago
Duplicate of this bug: 1267360

Comment 3

2 years ago
There are a couple of problems here:

(1) The searchWithEngine string is incorrectly localized in Hebrew, it sounds like you're saying.  The %S should come at the beginning, not the end: http://hg.mozilla.org/l10n-central/he/file/tip/toolkit/chrome/global/autocomplete.properties#l8  That's why you're seeing "Google Search with" (translated into English) instead of the correct "Search with Google".

(2) The search query should come before the "Search with Google", but you're seeing it come after.  I don't understand why that's happening, especially since your screenshot in the other bug 1267360 is showing the correct order.  That bug and this bug should show the same thing in this respect.

Comment 4

2 years ago
By the way, when I use the Force RTL add-on, "Search with Google" and the search query are ordered correctly -- "Search with Google" is on the left, the query string is on the right.

Comment 5

2 years ago
I just noticed in bug 1267360 that "nirsoft.net/" has a darker blue background -- non-standard styling.  Are you using some add-on or theme that affects the urlbar popup?
Flags: needinfo?(itiel_yn8)
(Reporter)

Comment 6

2 years ago
(In reply to Drew Willcoxon :adw from comment #3)
> There are a couple of problems here:
> 
> (1) The searchWithEngine string is incorrectly localized in Hebrew, it
> sounds like you're saying.  The %S should come at the beginning, not the
> end:
> http://hg.mozilla.org/l10n-central/he/file/tip/toolkit/chrome/global/
> autocomplete.properties#l8  That's why you're seeing "Google Search with"
> (translated into English) instead of the correct "Search with Google".

That's incorrect my friend :)
Because it's shown incorrectly in the browser (since it's shown in LTR), and that's a known bug to all RTL translators. To prove it, copy this entire string to notepad for example, then click Ctrl+Shift to change to RTL. You'll see that the %S comes at the end.

> (2) The search query should come before the "Search with Google", but you're
> seeing it come after.

Hmm. Now that I've google searched it, you're right. Never really gave it a thought. Though it may be bacause it's not RTL'd?

> I don't understand why that's happening, especially since your screenshot in the other bug 1267360 is showing
> the correct order.

Umm.. no it isn't? Remember we're talking RTL here. So the "Visit" should appear to the right of the URL, not to the left.

(In reply to Drew Willcoxon :adw from comment #4)
> By the way, when I use the Force RTL add-on, "Search with Google" and the
> search query are ordered correctly -- "Search with Google" is on the left,
> the query string is on the right.

Don't know what to say about that.
Maybe because the addon is really FORCING it to be RTL'd, while the normal hebrew Firefox build is not?
You may have different results if you install the hebrew build of Firefox, without tempering with addons.

(In reply to Drew Willcoxon :adw from comment #5)
> I just noticed in bug 1267360 that "nirsoft.net/" has a darker blue
> background -- non-standard styling.  Are you using some add-on or theme that
> affects the urlbar popup?

Nope. Using the built in theme of Firefox. No addons that would change the appearance of Firefox (currently active ABP, Hide My Ass! Proxy, Session Manager, IDM Integration and Tab Counter).
Why would it be bizarre? Makes sense for it to be darker. I'm using Windows 10 by the way.


Thanks for your time.
Flags: needinfo?(itiel_yn8)
(In reply to ETL from comment #6)
> > I don't understand why that's happening, especially since your screenshot in the other bug 1267360 is showing
> > the correct order.
> 
> Umm.. no it isn't? Remember we're talking RTL here. So the "Visit" should
> appear to the right of the URL, not to the left.

In LTR we show "url - visit" so in RTL it should be "visit - url"
(Reporter)

Comment 8

2 years ago
(In reply to Marco Bonardo [::mak] from comment #7)
> (In reply to ETL from comment #6)
> > > I don't understand why that's happening, especially since your screenshot in the other bug 1267360 is showing
> > > the correct order.
> > 
> > Umm.. no it isn't? Remember we're talking RTL here. So the "Visit" should
> > appear to the right of the URL, not to the left.
> 
> In LTR we show "url - visit" so in RTL it should be "visit - url"

Hmm? In LTR the opposite is shown-
http://media.askvg.com/articles/images6/Visit_Website_Option_Firefox_Addressbar_Results.png
But yeah, in RTL it should be "visit - url"
In short, it should look like the attached image.
(Reporter)

Comment 9

2 years ago
Created attachment 8746516 [details]
How it should look like.png
(In reply to ETL from comment #8)
> Hmm? In LTR the opposite is shown-
> http://media.askvg.com/articles/images6/
> Visit_Website_Option_Firefox_Addressbar_Results.png

Oh wait, this is a screenshot of the old style!
Firefox 48 has a new awesomebar style, and this is likely what was causing me confusion.

would you mind testing with a separate profile a current nightly build and tell us if it works as expected? We may have fixed this bug with the new style already.

Updated

2 years ago
No longer blocks: 1262507
(Reporter)

Comment 11

2 years ago
(In reply to Marco Bonardo [::mak] from comment #10)
> (In reply to ETL from comment #8)
> > Hmm? In LTR the opposite is shown-
> > http://media.askvg.com/articles/images6/
> > Visit_Website_Option_Firefox_Addressbar_Results.png
> 
> Oh wait, this is a screenshot of the old style!
> Firefox 48 has a new awesomebar style, and this is likely what was causing
> me confusion.
> 
> would you mind testing with a separate profile a current nightly build and
> tell us if it works as expected? We may have fixed this bug with the new
> style already.

Oh.
Will test and report back.
(Reporter)

Comment 12

2 years ago
(In reply to Marco Bonardo [::mak] from comment #10)
> (In reply to ETL from comment #8)
> > Hmm? In LTR the opposite is shown-
> > http://media.askvg.com/articles/images6/
> > Visit_Website_Option_Firefox_Addressbar_Results.png
> 
> Oh wait, this is a screenshot of the old style!
> Firefox 48 has a new awesomebar style, and this is likely what was causing
> me confusion.
> 
> would you mind testing with a separate profile a current nightly build and
> tell us if it works as expected? We may have fixed this bug with the new
> style already.

On second thought, how can I test it in nightly?
I can't find an hebrew version of it.
And using the Force RTL add-on won't be useful here since it might (and correct me if I'm wrong) force RTL what isn't normally RTL'd in RTL builds.
developer edition 48 would be fine too... is there an hebrew version of it already?
(Reporter)

Comment 14

2 years ago
(In reply to Marco Bonardo [::mak] from comment #13)
> developer edition 48 would be fine too... is there an hebrew version of it
> already?

You mean Developer Edition 47?
(Reporter)

Comment 15

2 years ago
Oh no sorry, my bad. It seems there isn't?
https://www.mozilla.org/en-US/firefox/developer/all/
yeah, looks like it has not been released yet, should be matter of days though since 46 has been released.
(Reporter)

Comment 17

2 years ago
Okay then, will wait until Developer Edition 48 will be released and report back.
Thanks.
(Reporter)

Comment 18

2 years ago
(In reply to Marco Bonardo [::mak] from comment #16)
> yeah, looks like it has not been released yet, should be matter of days
> though since 46 has been released.

Well what do you know, it looks okay in Firefox 48 Developer Edition.
Though, should the "visit" look like:
Visit - www.example.com
or:
www.example.com - Visit?

Also, the URL itself isn't RTL'd.
Which means, now it looks:
Visit - /nirsoft.net
instead of:
Visit - nirsoft.net/
(or even without the '/' at the end)
It looks OK now in Firefox 46.

Should I open a new bug for it or it can be fixed here?
I don't think the url itself changed compared to the previous design, since it comes from the backend.
And iirc, we never RTL-ed URIs.

So, is there anything that to your more trained RTL knowledge looks plain wrong in 48?
(Reporter)

Comment 20

2 years ago
(In reply to Marco Bonardo [::mak] from comment #19)
> I don't think the url itself changed compared to the previous design, since
> it comes from the backend.
> And iirc, we never RTL-ed URIs.
> 
> So, is there anything that to your more trained RTL knowledge looks plain
> wrong in 48?

Well take a look for yourself :)
attachment 8745016 [details] vs the new attached screenshot. Both are from the dropdown.
The first is LTR'd and the other is RTL'd (which shouldn't be- the misplaced '/' confirms it).

I can see some issues with the new awesomebar but nothing that concerns RTL.
(Reporter)

Comment 21

2 years ago
Created attachment 8747628 [details]
URL RTL'd.png
(Reporter)

Comment 22

2 years ago
Same issue in the latest build of Developer Edition..
(Reporter)

Updated

a year ago
Summary: "Search with" suggestion result in the Awesomebar is not RTL'd in RTL languages → Suggested URL in the Awesomebar should appear as LTR in RTL languages
Version: 45 Branch → unspecified
(Reporter)

Comment 23

a year ago
No longer an issue, because of the new design, closing as INVALID.
See bug 1290490 for tracking the issue in the new design.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.