1120018 - [RTL][Messages] Latin characters and numbers are right-aligned on input field

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::SMS, defect, P2)

Description

[Yeojin Chung [:YeojinC]]

Attachment: SMSInput.png

Description:
Latin and numeric characters should be left-aligned on the input field. However, all input is right-aligned on the input field.

Repro Steps:
1) Update a Flame device to BuildID: 20150109010206.
2) Set the device language in Arabic under Settings > Language.
3) Open Messages app.
4) Select New message icon.
5) Type in any numeric or Latin character on the input field.
  
Actual:
Latin and numeric characters are displayed right-aligned on the input field.
  
Expected: 
Latin and numeric characters are displayed left-aligned on the input field.
  
Environmental Variables:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20150109010206
Gaia: 2c7d14040149e1f9b1bb3972ff150be0472fa6b6
Gecko: b3f84cf78dc2
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Repro frequency: 100%
See attached: screenshot

Comment 1

[Julien Wajsberg [:julienw]]

I think we made this on purpose, but I'm not sure. What do you think Ahmed?

Comment 2

[Ahmed Nefzaoui [:Nefzaoui]]

(In reply to Julien Wajsberg [:julienw] (PTO until 1/5) from comment #1)
> I think we made this on purpose, but I'm not sure. What do you think Ahmed?

Actually it would be a little better to make it align based on the nature of the text. The problem here, (along the problem with not aligning text based on the language direction in message bubbles too) is that text will be *completely* not understandable because in case of RTL for example when Arabic text is left-aligned, LTR text is prioritized over RTL text so the order of the Arabic words will differentiate (especially with the case of mixed content) and a sentence that is not phrased correctly because words order is lost, wouldn't be understandable either :)

Comment 3

[Julien Wajsberg [:julienw]]

Ok I understand what you mean, the main issue is when we mix RTL and LTR in one line.

Comment 4

[Ahmed Nefzaoui [:Nefzaoui]]

To better describe the purpose of this bug as it wasn't clear to everyone during the rtl triage:

It basically means that if the user is writing in english/LTR we might want to align the text being written to the left, if their writing Arabic/RTL, it should be right-alined.

(In reply to Julien Wajsberg [:julienw] from comment #3)
> Ok I understand what you mean, the main issue is when we mix RTL and LTR in
> one line.
I was thinking of maybe something as simple as dir="auto"
?

Comment 5

[Julien Wajsberg [:julienw]]

Why not :)

Which style do we have currently?

Comment 6

[Dylan Oliver [:doliver]]

RTL triage: P2 -- will make a best effort to get this into the 2.2 release.

Comment 7

[Dylan Oliver [:doliver]]

RTL update: marking required bugs as feature-b2g:2.2+ (and removing blocking flags)

Comment 8

[Oleg Zasypkin [:azasypkin]]

Hey Stephany, 

We're going start working on this bug based on comment 4. I just want to confirm with you in advance that all other certified apps should follow the same behaviour for inputs (or maybe they already do) so that we're all consistent?

Thanks!

Comment 9

[Stephany Wilkes]

I can't ask strongly enough that people review the bidi pattern carefully, please please please. The below are covered in it, with the exception of the certified apps question.

I actually see four different questions here:

1) The direction and alignment of numerals (and the numerals we use in the Latin-alphabet world today are actually Arabic - 1, 2, 3, etc.) and 
2) The direction and alignment of text, based on the script in which that text is input, and
3) What to do when a "mixed" situation occurs: i.e. numerals with text in Arabic script, and
4) what certified apps should do.

If I understand correctly (and Ahmed and/or Craig, please correct me ASAP if I am WRONG here):
1) In a language with an LTR script, text should align left and (in presentation and input) flow LTR.
2) In a language with a RTL script, text should align right and (in presentation and input) flow RTL.
3) In a language with an LTR script, numerals should align left and flow LTR.
4) In a language with a RTL script, numerals should align right and flow LTR (as shown in the bidi pattern for time display on the homescreen, for example, and as noted in the input methods page of the bidi pattern, page 12). Same for a "mixed" situation - see page 12.
5) As to the certified apps question, I think it's a larger one: Are we asking or requiring certified apps to provide Arabic support and, if they do, to follow our pattern? I can't answer this question - who can?

Comment 10

[Julien Wajsberg [:julienw]]

Stephany, the main question here is:

* with the phone is configured with a RTL language, but the user inputs a latin text in the SMS application composer input, how should this text flow?

Currently, it's align to the right and flows LTR, as you says. Ahmed says it's not really understandable when there is mixed content.

I think the native BiDi algorithm is producing a result that Ahmed does not like much. For example Ahmed, what do you think of the text in [1] ?

[1] http://www.w3.org/International/articles/inline-bidi-markup/images/intro-to-C-right.png

Comment 11

[Craig Cummings]

Apologies for the late comment, but my Android Studio emulator was being uncooperative this morning. I'd recommend the fix you want for the EditText in question is to add "android:textDirection="firstStrong". The 'firstStrong' attribute makes the text field input behave pretty much the same as dir="auto" does in the HTML paradigm. There are actually some very minor differences I'm seeing between Android and Gecko. That could be due, in part, to first strong functionally having been implemented specifically for Android before it was a part of the Unicode Bidi Algorithm (UBA). It may not have changed when the UBA of Unicode release 6.3 implemented first strong.

Anyway, with Android's 'first strong' detection on the text field all the LTR/RTL cases Stephany speaks of will work though case #4 is another beast (as numbers are neutrals; later inheriting direction from the first strong character or application direction). Though I'm still doing some testing, mixed text seems work well, too. Give the excellent example Julien found on the W3 a try with first strong.

For Stephany's case #4, if digits/numbers entered in the text field first they should inherit direction based on the first strong character. In the Android context the appear on the right initially and likely inherit from the Android application's overall direction/language and input settings. In in the HTML paradigm, numbers appear on the left of the text field initially then inherit based on first strong -- even when I set the whole page to dir="rtl".

You may note that there are other textDirection settings. Though I haven't tried yet, I have seen other Android APIs to programmatically manipulate even finer control over text input and layout within the text field. I can discuss such options more (have seen a couple implementations), but would encourage the use of 'firstStrong' for this bug (and certain other FFOS app text fields).

Comment 12

[Julien Wajsberg [:julienw]]

Hey Craig, in case it was not obvious, we're not using any Android stuff, it's all pure HTML. From what you're saying, I understand we should use dir=auto :)

Note that Gecko does not implement Unicode 6.3 yet. See bug 922963.

Comment 13

[Craig Cummings]

My apologies, I didn't catch the obvious and I really need to start taking a better look at FFOS source. If the Messages app text field in question can take the dir="auto", then that would be a better bidi text solution (if not best). 

The FFOS dir="auto" functionality matches the Gecko dir="auto" functionality, yes? If so, thats the way to fix this bug.

Comment 14

[Ahmed Nefzaoui [:Nefzaoui]]

(In reply to Julien Wajsberg [:julienw] from comment #10)
> Stephany, the main question here is:
> 
> * with the phone is configured with a RTL language, but the user inputs a
> latin text in the SMS application composer input, how should this text flow?
> 
> Currently, it's align to the right and flows LTR, as you says. Ahmed says
> it's not really understandable when there is mixed content.
> 
> I think the native BiDi algorithm is producing a result that Ahmed does not
> like much. For example Ahmed, what do you think of the text in [1] ?
> 
> [1]
> http://www.w3.org/International/articles/inline-bidi-markup/images/intro-to-
> C-right.png

The text in this example is actually correct. :)

Comment 15

[Julien Wajsberg [:julienw]]

OK; but in this example they know the text (see http://www.w3.org/International/articles/inline-bidi-markup/#usecase1) and they can use appropriate markup. In our case I don't really know what we should do :/ Can we know better than "dir=auto"? Should we use the "unicode-bidi: plaintext" ?

Comment 16

[Steve Chung [:steveck]]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> OK; but in this example they know the text (see
> http://www.w3.org/International/articles/inline-bidi-markup/#usecase1) and
> they can use appropriate markup. In our case I don't really know what we
> should do :/ Can we know better than "dir=auto"? Should we use the
> "unicode-bidi: plaintext" ?

I think we should set "unicode-bidi: plaintext" for text area because it will apply better bidi algorithm if text content have paragraphs(just like we we did in message bubbles). But for subject "dir=auto" should be enough since there is no paragraph in subject. For recipient part I have no idea to make it align with editing content, maybe we need a follow up for it later.

Comment 17

[GitHub Autolander Bot]

Attachment: Link to github

Comment 18

[Steve Chung [:steveck]]

Attachment: Link to github

After more investigation on browser, here are some brief result:
- dir=auto and unicode-bidi: plaintedxt will align right when parent is rtl in firefox browser(And in device's browser), it only work for contentEditable elements, input and text-area will still align left(seems only text-align could change the direction). And none of them could work on chrome webkit.
- But when backspace pressed to delete the content to empty, the caret will still align left no matter the direction of the removed text.

Since any content changes in contentEditable will cause the caret starting from left easily, maybe that's why we saw caret in subject and composer in left side. Even we align with the browser behavior, we still need to handle the content reset issue. So I propose a solution that only set dir=auto and unicode-bidi: plaintedxt only when text content exist. Please note that it still have an issue for unicode-bidi: -moz-plaintext that new paragraph will starting from left no matter the content in previous paragraph(same behavior in desktop browser). That's the most acceptable approach I could found by far.

Comment 19

[Julien Wajsberg [:julienw]]

Comment on attachment 8558959 [details] [review]
Link to github

I agree that plaintext feels better.

I still don't really understand how the bidi algorithm behaves when we set plaintext but for such cases it looks the best solution we have.

I'm not sure about the change to fix the caret position in the empty case though :/ It's small enough to make us want to take it. Maybe put it in a separate bug so that we can put it in v2.2 only (for now) and apply it in later versions if we need it?

Comment 20

[Steve Chung [:steveck]]

Comment on attachment 8558938 [details] [review]
Link to github

One unit test with some refinement addressed. Maybe we can land thiss patch on master as well and create another bug to track bug 1103011.

Comment 21

[Julien Wajsberg [:julienw]]

(In reply to Steve Chung [:steveck] from comment #20)
> Comment on attachment 8558938 [details] [review]
> Link to github
> 
> One unit test with some refinement addressed. Maybe we can land thiss patch
> on master as well and create another bug to track bug 1103011.

no need to have another bug to track a bug :)

Comment 22

[Julien Wajsberg [:julienw]]

Comment on attachment 8558938 [details] [review]
Link to github

r=me with some nits

this is still weird as soon as we mix RTL and LTR texts in the same paragraph.

It looks like "plaintext" behaves kind of like "dir=auto" per paragraph.

I don't know if we can do better than this so let's land this :/

Comment 23

[Steve Chung [:steveck]]

In master: https://github.com/mozilla-b2g/gaia/commit/54c2cccc72fb9acefbc63099301ef68a0fc4b6a7

Basically you are right about the "plaintext" behaves kind of like "dir=auto" per paragraph, and I'm afraid that there is no better solution with RTL/LTR mix up case here.

Comment 24

[Julien Wajsberg [:julienw]]

Don't forget to ask for approval ;)

Comment 25

[Steve Chung [:steveck]]

Comment on attachment 8558938 [details] [review]
Link to github

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Original behavior from beginning
[User impact] if declined: If system language is set to Arabic or other RTL language, input caret direction will always start from right no matter input text is RTL or LTR.  
[Testing completed]: yes
[Risk to taking this patch] (and alternatives if risky): Low
[String changes made]: N/A

Comment 26

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/705699a9366b7574e2c937a5fdc6baf7f39b7066

Comment 27

[Coler]

This issue has been verified on Flame 2.2/3.0
Attachment:Verify_RTL_SMS.png

Flame 2.2 build:

Gaia-Rev        791e53728cd8018f1d7cf7efe06bbeb1179f0370
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/dcf030ef499d
Build-ID        20150211162505
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150211.194909
FW-Date         Wed Feb 11 19:49:19 EST 2015
Bootloader      L1TC000118D0

Flame 3.0:

Gaia-Rev        e280a660955bbdab265d50f8d9e009de34082332
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/650863f6987b
Build-ID        20150211160231
Version         38.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150211.192431
FW-Date         Wed Feb 11 19:24:42 EST 2015
Bootloader      L1TC000118D0

Comment 28

[Coler]

Attachment: Verify_RTL_SMS.png

Comment 29

[Alissa（leave from Mozilla）]

Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/15374/