1322542 - [RTL] LTR behavior with the cursor when typing RTL characters in the URL bar

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Itiel]

STR:
1. Type any RTL characters in the URL bar, for example: ניסיון
(for those who copy-pasted the word above, click the End key in the keyboard)
2. Press the space key in the keyboard
3. Observe the cursor's location

Actual result:
The cursor goes (only visually) to the beginning of the string (rightmost)

Expected result:
The cursor should stay where the user recently pressed the space key (leftmost)

Google Chrome behaves okay in this regard.

Comment 1

[Tomer Cohen :tomer]

Attachment: HTML demo

(In reply to ItielMaN from comment #0)
> STR:
> 1. Type any RTL characters in the URL bar, for example: ניסיון
> (for those who copy-pasted the word above, click the End key in the keyboard)
> 2. Press the space key in the keyboard
> 3. Observe the cursor's location
I'd suggest replacing typing an exclamation mark after the term "ניסיון", so the exclamation mark should be displayed at the end of the text, which is at the left side of the sentence in RTL. 

This issue can be simulated in HTML using the attached example, but chrome://browser/content/browser.xul doesn't seems to have similar code.

Comment 2

[Tomer Cohen :tomer]

Attachment: HTML demo

I am attaching a more robust demo, in which the direction is controlled by its content (dir=auto/unicode-bidi:plaintext). ItielMaN said that Expected2 is his expected behavior, while I think that Expected1 is good enough…

Comment 3

[Itiel]

(In reply to Tomer Cohen :tomer from comment #2)
> Created attachment 8817617 [details]
> HTML demo
> 
> I am attaching a more robust demo, in which the direction is controlled by
> its content (dir=auto/unicode-bidi:plaintext). ItielMaN said that Expected2
> is his expected behavior, while I think that Expected1 is good enough…

Having the Expected1 will make no sense for 2 reasons:
1. If the screen is wide enough, right after the user will type any non-RTL character in the URL bar (while Firefox's language is RTL), the text will appear on the left, which will confuse the user as the translated into RTL language "Search or enter address" string appears on the right.
2. According to the new search suggestions design, both a page's title and it's URL appears on the right (which makes sense), and having non-RTL characters appear on the left will be inconsistent with the search suggestions design.

And besides, all other major browsers behaves the same as Expected2 in this regard.

Comment 4

[Tomer Cohen :tomer]

https://dxr.mozilla.org/mozilla-central/rev/5745bab28ff5e85128c774b56b4cc27c2afe2e1b/layout/style/res/forms.css#117-129

input.uri-element-right-align:-moz-locale-dir(rtl) {
    direction: ltr !important;
    text-align: right !important;
}

Comment 5

[Itiel]

I think this should be fixed ASAP as the default text in the URL bar has LTR characters now (the search engine), which causes the entire translated sentence "Search with %S or enter address" in RTL locales to look reversed. See attached.

I still think that expected2 in the HTML demo is the way to go here.

Comment 6

[Itiel]

Attachment: URL bar screenshot

The left part "ניתן לחפש עם" is the translation of "Search with" and should start from the right, where "או להקליד כתובת" is now.

Comment 7

[Itiel]

This issue is not limited to Hebrew only, but also to other languages such as Farsi and Arabic.

Comment 8

[Itiel]

[Tracking Requested - why for this release]:
A (somewhat) recent change in the pre-filled text on the URL bar caused this bug to be more apparent on any New Tab (or when the URL bar is empty of user-typed text).
The issue is that the text "Search with %S or enter address" is shown in reverse for all RTL locales, because the %S is the search engine name and is usually LTR text.

Comment 9

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

mak, it sounds like this bug has gotten worse or is now more apparent. Should this still be P3? Can you take another look?

Comment 10

[Marco Bonardo [:mak]]

I honestly don't see a relation between comment 5 and this bug apart being both about RTL behavior in the address bar.
This bug comment 0 starts with "Type any RTL characters in the URL bar", but if you type anything the placeholder text goes away, and comment 5 seems to be related to the placeholder text.

As I see this, it should be filed as a new regression bug, blocking bug 1449317.

Comment 11

[Marco Bonardo [:mak]]

un-tracking, we should track a proper regression bug.

Comment 12

[Itiel]

Attachment: Bug 1322542 - Display user-typed text in the urlbar according to its direction r?mak

Also fix the fade effect on RTL typed text.

Comment 13

[Oana Pop-Rus]

Backed out changeset f69b1ca45a44 (bug 1322542) for bc failures in browser_UrlbarInput_overflow.js

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Csuperseded%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=linux%2Cx64%2Casan%2Cmochitests%2Ctest-linux64-asan%2Fopt-mochitest-browser-chrome-e10s-2%2Cm%28bc2%29&fromchange=b478b6bb3423e24afb5ad4c10bc4b5c57c263950&selectedJob=280685452

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=280685452&repo=autoland&lineNumber=2290

Backout: https://hg.mozilla.org/integration/autoland/rev/d5c058da8148283fb78efa6f73dd7af916b883ac

Comment 14

[Raul Gurzau (:RaulG)]

.

Comment 15

[Marco Bonardo [:mak]]

Attachment: Bug 1322542 - part 2 - fix textoverflow attribute. r=Itiel

Depends on D54195

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d98ef30b82f7
Display user-typed text in the urlbar according to its direction r=mak
https://hg.mozilla.org/integration/autoland/rev/3f46d4a4341c
part 2 - fix textoverflow attribute. r=Itiel

Comment 17

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/d98ef30b82f7
https://hg.mozilla.org/mozilla-central/rev/3f46d4a4341c