Closed Bug 1094709 Opened 7 years ago Closed 7 years ago
[Flame][Contacts]Tap "x" in left of Name Input Box when edit a contact, it will not delete the name
[1.Description]: Tap "x" in left of Name Input Box when editing a contact, it will not delete the name. video:VIDEO0340_Compress.MP4 log:logcat.txt happen time:3:43 [2.Testing Steps]: 1.Launch contact 2.Tap Add icon to enter contact edit view 3.Input name or last name to input box 4.Tap "x" in name input box [3.Expected Result]: 4.it will delete the name. [4.Actual Result]: 4.it will not delete the name. [5.Reproduction build]: Gaia-Rev 154da5e17029a51002d5d9b7df39563d509edde6 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3b0c3580a58d Build-ID 20141105001204 Version 34.0 [6.Reproduction Frequency]: occasionally Recurrence,5/10
Can you provide a video?
Assignee: nobody → ferjmoreno
The video has been uploaded.
Thanks for the video Elie. It seems that this is not happening on master anymore, I can only reproduce it on 2.1. This makes me wonder if this is worth fixing given the stage we are wrt accepting patches for 2.1. Francisco, what do you think? In any case, this looks like a building blocks issue. Any idea of what might have change between 2.1 and master?
As discussed with Fernando previously, clear button has no functionality in BB, but the button is showed when the input as focus, that means when you tap on the icon the button hides as the input blurs :) Not sure what could have changed between 2.0 to 2.1 and 2.1 to current master. Would be cool to implement something similar to -webkit-search-cancel-button to have this behavior supported in gecko. Another way to improve this would be creating a Web Component.
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #3) > Thanks for the video Elie. > > It seems that this is not happening on master anymore, I can only reproduce > it on 2.1. This makes me wonder if this is worth fixing given the stage we > are wrt accepting patches for 2.1. Francisco, what do you think? > I got some approvals of simple staff for v2.1. Maybe we can try it. The bug it is a bit ugly > In any case, this looks like a building blocks issue. Any idea of what might > have change between 2.1 and master?
Agree with Jose, let's try to fix it as it's pretty ugly and can become a blocker.
I tried but I am basically CSS blind :( So I am unassigning myself from this issue.
Assignee: ferjmoreno → nobody
Assignee: nobody → jmcf
I've looking into this issue and I've found that the issue is that the 'x' button is too close to the right, which basically means that it is very easily that the user can press outside the button and as a result the input field would lose the focus and the effect would be equivalent as if the 'x' button didn't work, but it is actually working. My proposal here would be the following: Hide the Gecko ScrollBar in the 'Contact Form Screen' as we do in the Contact List screen. Then, try to increase the affordance of the 'x' to the right as much as possible, so that if the user clicks on the right the button will respond. I'm now working on this approach
Summary: [Flame][v2.1][Contacts]Tap "x" in left of Name Input Box when edit a contact, it will not delete the name. → [Flame][Contacts]Tap "x" in left of Name Input Box when edit a contact, it will not delete the name.
The proposed patch increase the affordance of the reset button in those input fields that are on rightmost part of the view (name, last name, org).
Attachment #8523850 - Flags: review?(crdlc)
Comment on attachment 8523850 [details] 26192.html LGTM, thanks
Attachment #8523850 - Flags: review?(crdlc) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Once QA verifies in master, we will ask for an uplift to v2.1 .
Reverted for test_add_photo_to_contact.py failures. https://treeherder.mozilla.org/ui/logviewer.html#?job_id=853190&repo=b2g-inbound Master: https://github.com/mozilla-b2g/gaia/commit/ae3a84acaab80a5b35d5542d63e68462273c8a1b
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'm not able to reproduce the test failure locally and I have my doubts that my patch is responsible for the failure, Zac, any clue?
(In reply to Jose Manuel Cantera from comment #15) > I'm not able to reproduce the test failure locally and I have my doubts that > my patch is responsible for the failure, Zac, any clue? As this failed identically on both Linux and Mac I am 100% sure that your patch caused it. You need to update the wait in the EditContact __init__ block. It is expecting the Edit Contact screen to slide in (hence waiting for y == 0) . Has your patch changed this behaviour? The test is probably tapping on the contact picture before the EditContact has finished animating.
I need to investigate more in order to solve the test issue. It seems we need to enlarge the ckick area around the contact photo edition button ...
Target Milestone: 2.1 S9 (21Nov) → 2.2 S1 (5dec)
the same patch but with a pointer-events to enable correct event delivery to the contact photo region
Attachment #8527878 - Flags: review?(crdlc)
Attachment #8523850 - Attachment is obsolete: true
Comment on attachment 8527878 [details] 26326.html LGTM, thanks a lot
Attachment #8527878 - Flags: review?(crdlc) → review+
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Verified the issue is fixed on 2.2 Flame Tapping on the "X" button removes the first or last name "Flame 2.2 Environmental Variables: Device: Flame 2.2 (319mb)(Kitkat Base)(Full Flash) BuildID: 20141201040205 Gaia: 39214fb22c203e8849aaa1c27b773eeb73212921 Gecko: 08be3008650f Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 37.0a1 (Unknown) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 ==================================================================== Leaving "verifyme" for 2.1
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
The v2.2 has verified, clear 'verifyme' keywords.
You need to log in before you can comment on or make changes to this bug.