1503161 - Address bar placeholder text appears in reverse for RTL locales

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Itiel]

See attachment 8991891 [details] for screenshot on how this currently looks on RTL locales.
The underlying bug of this has been an issue for a long time (see bug 1322542), but bug 1449317 exposed it more by adding an LTR search engine text to the address bar, which causes the text to be read as "or enter address %S search with".

Fixing this bug should probably fix 1322542 and vice versa.
In bug 1322542 we discussed which of the 4 methods (see attachment 8817617 [details]) should be used, I believe the expected2 is the way to go.

Comment 1

[Pascal Chevrel:pascalc (PTO until April 26)]

Not a recent regression, setting as wontfix for 63

Comment 2

[Yehuda]

I can take this.
Wondering if it's better to fix just the placeholder issue, or also the behavior described in bug 1322542.
The placeholder fix is straightforward, while changing the behavior of the component during typing as well might introduce other side-effects.

Comment 3

[Yehuda]

Attachment: Bug 1503161 - Use rtl for placeholder text in urlbar if user interface is rtl

The URL bar is used for showing the URL, but also as a way to start a search.
A placeholder text is shown to let the user know about these possibilities.
In right-to-left (RTL) interface, URLs are forced to be displayed from left-to-right (LTR) to avoid confusion.
This creates an undesired side-effect, causing the placeholder text to also display LTR. 
Following changes in bug 1449317, this placeholder text now contains both localized text, and names of search engines (such as Google), which causes a break in the bidi flow of text.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e6377178d093
Use rtl for placeholder text in urlbar if user interface is rtl r=dao

Comment 5

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/e6377178d093

Comment 6

[Itiel]

Dão, can this get an uplift request?
This is a main UI RTL regression from Firefox 61 which a simple CSS change fixes, and I can confirm it's fixed on latest Nightly without any visible side-effects.

Comment 7

[Itiel]

Scratch that, I just found a visual regression when searching for something in the URL bar. The fading effect appears unnecessarily. Will file a follow-up bug on that.

Comment 8

[Dão Gottwald [:dao]]

I've backed this out for causing bug 1509484 and bug 1510434:
https://hg.mozilla.org/integration/mozilla-inbound/rev/94ff32de21d6fcb638a3759e12735edf31136033

Yehuda, if you have time, do you want to look into what went wrong here and how we can fix this without causing these regressions?

Comment 9

[Yehuda]

(In reply to Dão Gottwald [::dao] from comment #8)
> I've backed this out for causing bug 1509484 and bug 1510434:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/
> 94ff32de21d6fcb638a3759e12735edf31136033
> 
> Yehuda, if you have time, do you want to look into what went wrong here and
> how we can fix this without causing these regressions?

Yes, sure. I'll give it a try.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Since this is triaged and has a priority set, marking this fix-optional to remove it from regression triage. 
Happy to still take a patch in nightly.

Comment 11

[Neha Kochar [:neha]]

Yehuda, since this is assigned to you, I'm checking in to see if this will be fixed in time for 67 soft freeze (Mar 11)?

Comment 12

[Yehuda]

(In reply to Neha Kochar [:neha] from comment #11)

Yehuda, since this is assigned to you, I'm checking in to see if this will be fixed in time for 67 soft freeze (Mar 11)?
Hi Neha,
Unfortunately, my attempt to fix this issue did not go well, and was reverted.
After that I couldn't find a better solution, so I suggest you change the owner to someone with better knowledge.

Comment 13

[Itiel]

Fixed by bug 1322542.