[rtl] lock sreen enter field dots are missaligned when entering password

RESOLVED DUPLICATE of bug 1212329

Status

P3
normal
RESOLVED DUPLICATE of bug 1212329
4 years ago
3 years ago

People

(Reporter: Jamie_, Unassigned)

Tracking

unspecified
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(tracking-b2g:+, b2g-v2.2 affected, b2g-master affected)

Details

(Whiteboard: [2.5-rtl-test-run])

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8547708 [details]
a picture of what it looks like

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150108012614

Steps to reproduce:

1.) have phone in a rtl language
2.) set a password
3.) go to unlock phone


Actual results:

The entry field for the password when entering, the dots are missaligned from the squares


Expected results:

password was enterd and the dots for password were alinged in the center of the square.
Guessing this is not simulator specific.
Component: Simulator → Gaia::System::Lockscreen
(Reporter)

Comment 2

4 years ago
sorry all i have is the simulator, so to be on the safe side i lable them all as simulator to be on the safe side.
(In reply to charja13 from comment #2)
> sorry all i have is the simulator, so to be on the safe side i lable them
> all as simulator to be on the safe side.

The simulator component is really meant for bugs *in the simulator's own functionality*.  If the simulator's home button did not work, this would be a simulator bug.

Nearly all of the bugs you've filed recently are not really about the simulator from what I can tell, but instead are about functionality of a Gaia app.  It's best to file these kind in the right Gaia app component, and note in the bug that you tested on a simulator.  If it's later determined that the Simulator code itself is causing the issue, it can be moved to the simulator component.
(Reporter)

Comment 4

4 years ago
(In reply to J. Ryan Stinnett [:jryans] from comment #3)
> (In reply to charja13 from comment #2)
> > sorry all i have is the simulator, so to be on the safe side i lable them
> > all as simulator to be on the safe side.
> 
> The simulator component is really meant for bugs *in the simulator's own
> functionality*.  If the simulator's home button did not work, this would be
> a simulator bug.
> 
> Nearly all of the bugs you've filed recently are not really about the
> simulator from what I can tell, but instead are about functionality of a
> Gaia app.  It's best to file these kind in the right Gaia app component, and
> note in the bug that you tested on a simulator.  If it's later determined
> that the Simulator code itself is causing the issue, it can be moved to the
> simulator component.

okay sorry about that, will file properly next time.
(In reply to charja13 from comment #4)
> okay sorry about that, will file properly next time.

No worries, Bugzilla is confusing. :)

Comment 6

4 years ago
Reproduced on flame:

Build ID               20150126010231
Build Type             user
Gaia Revision          0f662dffef27599443cfcd790c2b39190a2b35c8
Gaia Date              2015-01-25 00:48:56
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/fa91879c8428
Gecko Version          38.0a1
Device ID              flame
Firmware(Release)      4.4.2
Firmware(Incremental)  39
Firmware Date          Thu Oct 16 18:19:14 CST 2014
Bootloader             L1TC00011880
Reproduced during today's 2.2 bug bash. Can you flag it as feature-b2g 2.2+, J. Ryan?
Blocks: 1064539
Status: UNCONFIRMED → NEW
status-b2g-v2.2: --- → affected
Ever confirmed: true
Flags: needinfo?(jryans)
(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #7)
> Reproduced during today's 2.2 bug bash. Can you flag it as feature-b2g 2.2+,
> J. Ryan?

No, I don't have access to set that flag.  Perhaps it's best to ask someone on the Lockscreen team anyway?
Flags: needinfo?(jryans)
Priority: -- → P3
:bajaj, please flag this bug as feature-b2g 2.2+
QA Whiteboard: [rtl-impact]
Flags: needinfo?(bbajaj)
(In reply to Parul Mathur [:pragmatic] from comment #9)
> :bajaj, please flag this bug as feature-b2g 2.2+

Looks minor, but given that locksceeen will be a frequently used screen we can up the priority. alive/tim, not sure what your load on RTL is right now but is this something that can get fixed?
Flags: needinfo?(timdream)
Flags: needinfo?(bbajaj)
Flags: needinfo?(alive)
Should be trivial to fix. Greg could you help out here?
tracking-b2g: --- → +
Flags: needinfo?(timdream)
Flags: needinfo?(gweng)
Flags: needinfo?(alive)
I've found that -moz-locale-rtl doesn't work well with pseudo elements, and unfortunately the dot was implemented with that. For example:

  #lockscreen-passcode-code > span[data-dot]:-moz-locale-dir(ltr) {
    background: red;
  }

Would change the span as red blocks, but

  #lockscreen-passcode-code > span[data-dot]::before:-moz-locale-dir(ltr) {
    background: red;
  }

Would not work. So even I could manually change the dot from 'left:50%' to 'right:50%' and make them correct while it's RTL, I couldn't apply the rule with the selector. I may need to find out other selection ways, and the worst case is I need to complete change the way we implement the dots. So this looks not trivial.
Flags: needinfo?(gweng)
And I choose '-moz-locale-dir(ltr)' is intentional, since I want to show that it seems a pure selection issue and irrelevant to RTL or LTR.
How about |html[dir=rtl] ... { }| ? That should apply regardless.

Also I wonder if the correct syntax is |span[data-dot]:-moz-locale-dir(ltr)::before { ... }| instead.
Flags: needinfo?(gweng)
I've tried the second one but it didn't work. I need do more tests on these possible solutions.
Flags: needinfo?(gweng)
...I've found a strange issue:

  -moz-locale-dir(ltr):before

would work with mirrored English, while

  -moz-locale-dir(rtl):before

doesn't.
Duplicate of this bug: 1129750

Comment 18

4 years ago
Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/15863/
Flags: in-moztrap+
Hmm still have no luck.

Updated

3 years ago
Whiteboard: MGSEI-RTL-3F
QA Whiteboard: [rtl-impact] → [rtl-impact][MGSEI-Triage+]
QA Whiteboard: [rtl-impact][MGSEI-Triage+] → [rtl-impact][MGSEI-Triage+]MGSEI-RTL-3F
Whiteboard: MGSEI-RTL-3F
Created attachment 8649063 [details]
AriesKK_Arabic.png

This issue can be reproduced on latest AreisKK&FlameKK v2.5 build by the same STR in comment 0.
Actual Result:The entry field for the password when entering, the dots are missaligned from the squares.

See attachment:AriesKK_Arabic.png
Reproducing rate:10/10

Device: AriesKK v2.5 build
Build ID               20150814002719
Gaia Revision          39b121515ab8a8c3ea07f26d3ba1dd792e90217c
Gaia Date              2015-08-13 18:25:42
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/4e883591bb5dff021c108d3e30198a99547eed1e
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150813.235024
Firmware Date          Thu Aug 13 23:50:32 UTC 2015
Bootloader             s1

Device: FlameKK v2.5 build
Build ID               20150817150206
Gaia Revision          60489c1ff8c5d1633fc4837d4f8019623d4e1940
Gaia Date              2015-08-16 02:21:48
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/9673c75864beafca2f6c8b117b98503128bf2e56
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150817.182933
Firmware Date          Mon Aug 17 18:29:45 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0
Blocks: 1181944
status-b2g-master: --- → affected

Updated

3 years ago
Whiteboard: [2.5-rtl-test-run]

Comment 21

3 years ago
Should be fixed when bug 1212329 is merged.

Updated

3 years ago
Depends on: 1212329
Fix will be in bug 1212329
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1212329
You need to log in before you can comment on or make changes to this bug.