[RTL][Contacts] checkboxes overlap with alphabet picker

RESOLVED FIXED in 2.2 S8 (20mar)

Status

defect
P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: ychung, Assigned: arcturus)

Tracking

unspecified
2.2 S8 (20mar)
ARM
Gonk (Firefox OS)
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 fixed, b2g-master verified)

Details

(Whiteboard: [3.0-Daily-Testing])

Attachments

(5 attachments)

Reporter

Description

4 years ago
Posted image CheckboxOverlap.png
Description:
When the user tries to delete contacts, the checkboxes overlap with the alphabet picker.

Pre-requisite: Have at least 1 contact in Contacts.

Repro Steps:
1) Update a Flame to 20150223010224.
2) Set the device language in Arabic under Settings > Language.
3) Open Contacts app.
4) On the main page, press the settings icon.
5) Select "Delete Contacts".
6) Observe the checkboxes.

Actual:
The checkboxes overlap with the alphabet picker on the right side.

Expected:
The checkboxes do not overlap with the alphabet picker.

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, full flash)
Build ID: 20150223010224
Gaia: a6881205deae450757a8d1e1ed65e5e5be0ec633
Gecko: 86d2bb8bb1c9
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 5/5
See attached: screenshot
Reporter

Comment 1

4 years ago
This issue does NOT reproduce on Flame 2.2. However, bug 1134306 might be the cause of this issue. Once the fix is uplifted on Flame 2.2, it could be affected as well.

Result: The alphabet picker is located at the left side of the screen, so it does not overlap with the checkboxes.

Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150223002503
Gaia: 389542b71c89253c0d176d3b0bfb54e275c19bf1
Gecko: 9fd3441c8983
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?][rtl-impact]
Flags: needinfo?(ktucker)
Reporter

Updated

4 years ago
Blocks: contacts-rtl
No longer blocks: 1134306
Yeojin, let's check this again once the uplift to 2.2 occurs for bug 1134306.
QA Whiteboard: [QAnalyst-Triage?][rtl-impact] → [QAnalyst-Triage-][rtl-impact]
Flags: needinfo?(ktucker) → needinfo?(ychung)
Yes, please keep an eye out for that. If it doesn't fix this issue, we will need to nominate this. thanks!
Yes, please keep an eye out for that. If it doesn't fix this issue, we will need to nominate this. thanks!
Reporter

Comment 5

4 years ago
Bug 1134306 is uplifted on Flame 2.2, and now the issue occurs on Flame 2.2 as well.

Result: The checkboxes overlap with the alphabet picker on the right side.

Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150224002637
Gaia: 8e98fe665f3821d10d4d982cbb14cbe5b94d0be5
Gecko: 2b70d9d62799
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage-][rtl-impact] → [QAnalyst-Triage?][rtl-impact]
Flags: needinfo?(ychung) → needinfo?(ktucker)
Keywords: regression
QA Whiteboard: [QAnalyst-Triage?][rtl-impact] → [QAnalyst-Triage+][rtl-impact]
Flags: needinfo?(ktucker)
RTL triage: blocking. Overlap is unsightly and if you try to touch the box to select a contact, it activates the alphabet picker instead. (The contact can be selected if you touch the name instead so this is not completely broken, but presumably most will try to use the checkbox.)
blocking-b2g: --- → 2.2+
Priority: -- → P1
Duplicate of this bug: 1126712
Can we please get someone assigned to this as this is a blocker? Hasn't been touched yet. thanks
Assignee: nobody → francisco
@Delphine, where should the check boxes appear then, if we moved back to the right side the alphabet picker to the right?
Flags: needinfo?(lebedel.delphine)
@Francisco: I believe all this is covered on UX specs p.16: https://mozilla.app.box.com/s/bcm3s5i2v6js5uk0ws3tsywse8bgncgo
Please ni FirefoxOS UX in case you're still unsure about specs! thanks
Flags: needinfo?(lebedel.delphine)

Updated

4 years ago
Status: NEW → ASSIGNED
Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/15412/
Flags: in-moztrap+
Francisco, my interpretation is that the checkboxes should remain on the right side of the screen as they are now, but should shift to the left several pixels such that both they and the alpha-scroll can be accessed independently and predictably. 

However if that is problematic I imagine it would be reasonable to move to checkbox over to the left side of the screen (as they are in LTR) -- we can get UX feedback on that option if it makes any difference to the implementation.
Ouch I read this bug too fast - definitely did not cover Francisco's question about check boxes as I was referring to something else. Sorry about that! FWIW I agree with Dylan's explanation in comment 12
Hi, actually the checkbox it'self is just a visual indicator, the action happens in all the row, but definitely I can see some interaction problems when people try to press the checkbox thinking that is the way of selecting the row.

Will try to have them as Dylan suggest, will ask before merging for ux review just to be sure.
Following suggestions in previous comments, we keed the checkboxes on the right. Asking Fang for ui review.
Attachment #8579430 - Flags: ui-review?(fshih)
Comment on attachment 8579430 [details]
2015-03-18-16-37-54.png

Thanks!
Attachment #8579430 - Flags: ui-review?(fshih) → ui-review+
Attachment #8579431 - Flags: review?(ferjmoreno)
Comment on attachment 8579431 [details] [review]
Pointer to PR 28957

That was easy :)
Attachment #8579431 - Flags: review?(ferjmoreno) → review+
Master: https://github.com/mozilla-b2g/gaia/commit/5be266af6ba3608b877a4d3acbad4dc4165f9cc9
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S8 (20mar)
Comment on attachment 8579431 [details] [review]
Pointer to PR 28957

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
RTL
[User impact] if declined:
Bad user experience
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
Pretty low
[String changes made]:
None
Attachment #8579431 - Flags: approval-gaia-v2.2?
Attachment #8579431 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+

Comment 21

4 years ago
Posted image verify.png
This issue has been verified successfully on Flame 3.0, the checkboxes do not overlap with the alphabet picker.
See attachment:verify.png
Rate:0/5

Flame 3.0 build: pass
Build ID               20150322160204
Gaia Revision          9b6f3024e4d0e62dd057231f4b14abe1782932ab
Gaia Date              2015-03-22 10:09:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/e730012260a4
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150322.192413
Firmware Date          Sun Mar 22 19:24:22 EDT 2015
Bootloader             L1TC000118D0

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+][rtl-impact] → [QAnalyst-Triage+][rtl-impact][MGSEI-Triage+]
Testing this out on master, the visual overlap is fixed but I still trigger the alpha-scroll when I touch the checkbox. I think the box still needs to move further to the left.
Flags: needinfo?(francisco)
(In reply to Dylan Oliver [:doliver] from comment #23)
> Testing this out on master, the visual overlap is fixed but I still trigger
> the alpha-scroll when I touch the checkbox. I think the box still needs to
> move further to the left.

There is several things happening here, IMO, first the alphascroller has a wider scrolling area, that was done to make it easier to work with.

Also the checkbox by itself, doesn't select, actually it has all the pointer events cancelled, it's just a visual indication that the element is selected.

We can move it even more, but the area used for scrolling is still big, any UI advice is more than welcome.
Flags: needinfo?(francisco)
I know it's just a visual indicator, but it's the target that we present to people and most will attempt to use it at first. When they figure out that it doesn't work consistently they'll learn to touch elsewhere in the row, but it's a UI footgun which will annoy users. 

If we need to give the alpha-scroll a wide target then I'd vote for moving the checkbox to the left side of the row instead.

Comment 26

4 years ago
Per comment 6 and comment 12, I have verified this issue on latest build of Flame 2.2 and 3.0 again, and the checkboxes do not overlap with the alphabet picker. But the alphabet picker will be triggered when I touch the checkbox. This phenomenon has been wrote in the duplicate Bug 1126712

Device: Flame 2.2
Build ID               20150324002504
Gaia Revision          014d38f7ad3912b8b33cb08ce7535a5dc5aced59
Gaia Date              2015-03-23 23:27:22
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/7a9f2a248e57
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150324.041652
Firmware Date          Tue Mar 24 04:17:03 EDT 2015
Bootloader             L1TC000118D0

Device: Flame 3.0
Build ID               20150324160206
Gaia Revision          aebfbd998041e960cea0468533c0b5041b504850
Gaia Date              2015-03-24 17:08:51
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/264387e7e453
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150324.193523
Firmware Date          Tue Mar 24 19:35:34 EDT 2015
Bootloader             L1TC000118D0
Stephany, what are your thoughts here? See comments 23-25 for the current state.
Flags: needinfo?(swilkes)

Comment 28

4 years ago
Flagging Amy after a chat with Rob.
Flags: needinfo?(amlee)

Updated

4 years ago
Flags: needinfo?(swilkes)
(In reply to Stephany Wilkes from comment #28)
> Flagging Amy after a chat with Rob.

Fang is the owner of contacts. Flagging her for input.
Flags: needinfo?(amlee) → needinfo?(fshih)
I think for now, maybe adding more space for the scroll area. For visual side, it is a bit heavy on the right side, we have an alpha-scroll, check box and the contact name. But I am not sure if we can move around the check box just for this page. It will be inconsistent with all other checkboxes, we may need more thought from UX side on this. ni Harly ~ Harly what are your thoughts here? Thanks!
Flags: needinfo?(fshih) → needinfo?(hhsu)
It is defined in p.19 of the document below that checkbox needs to be placed at the right side in select mode.
https://mozilla.app.box.com/s/bcm3s5i2v6js5uk0ws3tsywse8bgncgo

Therefore, for consistency, I wouldn't suggest moving the checkbox, and I agree with Fang that adding more space for the scroll area might be a suitable solution for now.
Flags: needinfo?(hhsu)
(In reply to Harly Hsu from comment #31)
> Therefore, for consistency, I wouldn't suggest moving the checkbox, 

It can't stay exactly where it is. Harly, just to be clear you are suggesting that we should shift it to the right some number of pixels so that it doesn't overlap with the alphascroll touch area?

Francisco, can you create a visual of where the box would need to go to avoid the overlap so that we can see how much space we'd lose for the contact name?
Flags: needinfo?(hhsu)
Flags: needinfo?(francisco)
Sorry for the confusion, what I meant was not to move the checkbox to the left of the screen, but we can surely shift the checkbox a little so that it doesn't overlap with the alpha scroll.
Flags: needinfo?(hhsu)
Hi Dylan,

you have an attachment verify.png with the result.
Flags: needinfo?(francisco)
Hi Francisco,

That attachment illustrates the fix of the visual overlap, but not the touch overlap. What I mean is how much further to the left do we need to move the checkbox so that it won't trigger the alphascroll when you touch it?
Flags: needinfo?(francisco)
Hi Dylan,

sorry I misread your previous comment.

I've attached a new document displaying how the checkbox is currently inside the touch area.

We will need to move 20px the whole content of the line to make the box being outside of the navigation area.
Flags: needinfo?(francisco) → needinfo?(dylan)
Flags: needinfo?(dylan) → needinfo?(doliver)
Thanks, that's helpful and confirms my experience that any touch directly on the box is always going to trigger the scroll instead. In my opinion, we need to move the box outside of the shaded area. That will result in an increase of truncated names due to the lost space but in this context I think that's less important than the usability of the screen. 

Of course now we're well into a UX/product decision area and this is not specifically related to RTL, so really it's up to you guys to decide where to go with it. 

ni? to Harly again so he can see the attachment in comment 36 and make a call on whether we need a followup bug here.
Flags: needinfo?(doliver) → needinfo?(hhsu)
Yes, I agree with Dylan that to move the box outside of the shaded area might be the best option we have right now based on the current RTL guideline. But if we have a chance to review the guideline, I would definitely bring up this issue with the UX team to see if we need some adjustment.

BTW, needinfo Fang to check if we need to adjust other stuff if the checkboxes were to move outside of the shaded area.
Flags: needinfo?(hhsu) → needinfo?(fshih)
(In reply to Harly Hsu from comment #38)
> Yes, I agree with Dylan that to move the box outside of the shaded area
> might be the best option we have right now based on the current RTL
> guideline. But if we have a chance to review the guideline, I would
> definitely bring up this issue with the UX team to see if we need some
> adjustment.
> 
> BTW, needinfo Fang to check if we need to adjust other stuff if the
> checkboxes were to move outside of the shaded area.
Thanks Harly, I just did a mock up, and it looks fine. so I think we don't need to adjust other stuff for now. Thanks!
Flags: needinfo?(fshih)
You need to log in before you can comment on or make changes to this bug.