Open Bug 1503161 Opened Last year Updated 5 months ago
Address bar placeholder text appears in reverse for RTL locales
47 bytes, text/x-phabricator-request
|Details | Review|
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.
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.
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.
Assignee: nobody → yehudab
Status: NEW → ASSIGNED
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/e6377178d093 Use rtl for placeholder text in urlbar if user interface is rtl r=dao
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.
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.
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
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.
You need to log in before you can comment on or make changes to this bug.