Closed Bug 1191471 Opened 5 years ago Closed 3 years ago
[Contacts] Creating a new contact has no default fields populated
88.90 KB, text/plain
41.74 KB, image/png
1.70 MB, application/pdf
46 bytes, text/x-github-pull-request
|Details | Review|
Description: When the user is in the contacts app and chooses to create a new contact none of the contact fields will be present by default. the user will have to add them. Repro Steps: 1) Update a Flame to 20150805121714 2) Open contacts 3) Select to add a new contact 4) Observe screen Actual: None of the contact fields are present Expected: It is expected that there are fields present for the user to fill in. Environmental Variables: Device: Flame 2.5 [Full Flash] BuildID: 20150805030212 Gaia: c5425d9f1f5184731a59ed4bc99295acbde30390 Gecko: f3b757156f69 Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Repro frequency: 10/10 See attached: screenshot, logcat
This issue DOES occur on Aries 2.5. Environmental Variables: Device: Aries 2.5 [Full Flash] Build ID: 20150805121714 Gaia: 581de383687dc441a878d2c91a0167c6ec688fef Gecko: b12a261ee32e Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 42.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Result: None of the contact fields are present
test_keyboard.py is failing consistently on python automated tests for Jenkins non-smoke.1 builds on mozilla-central by this change. Appears to be failing when the test tries to access the first field to type in a phone number for a new contact. Issue appears very similar to bug 1184649 * http://jenkins1.qa.scl3.mozilla.com/view/UI/job/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/211/HTML_Report/ * http://jenkins1.qa.scl3.mozilla.com/view/UI/job/flame-kk.ui.adhoc.bitbar/165/HTML_Report/ Traceback (most recent call last): File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_client-0.16-py2.7.egg/marionette/marionette_test.py", line 296, in run testMethod() File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/tests/functional/keyboard/test_keyboard.py", line 22, in test_keyboard_basic new_contact_form.type_phone(contact['tel']['value']) File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/apps/contacts/regions/contact_form.py", line 54, in type_phone element = self.marionette.find_element(*self._phone_locator) File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.9-py2.7.egg/marionette_driver/marionette.py", line 1589, in find_element response = self._send_message('findElement', 'value', **kwargs) File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.9-py2.7.egg/marionette_driver/decorators.py", line 36, in _ return func(*args, **kwargs) File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.9-py2.7.egg/marionette_driver/marionette.py", line 715, in _send_message self._handle_error(response) File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.9-py2.7.egg/marionette_driver/marionette.py", line 751, in _handle_error raise errors.lookup(status)(message, stacktrace=stacktrace) NoSuchElementException: NoSuchElementException: Unable to locate element: number_0
This issue DOES NOT occur on Flame 2.2. Environmental Variables: Device: Flame 2.2 [Full Flash] BuildID: 20150805032505 Gaia: f8b119ac30e97df991c97682ac4d4f9ca22e1793 Gecko: 0c7a85251e10 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Result: There are fields present to enter information in.
When landing Bug 1183728, as part of the NGA work, we decided not showing those fields by default. I think it was agreed with Francisco, but leaving to him the decision of including them again or not, or asking UX team...
Whiteboard: [2.5-Daily-Testing][Spark] → [NG Gaia Contacts][2.5-Daily-Testing][Spark]
Right, It was decided to keep the fields not open by default. Will defer this decision to ux team. Harley wdyt?
Flags: needinfo?(francisco) → needinfo?(hhsu)
Hi Francisco, Is there a reason why we change the previous design to not show any fields by default?
Flags: needinfo?(hhsu) → needinfo?(francisco)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Hi Harly, was an engineering decision, to make the more fields appear in the screen, we can rollback to your suggestion.
NI Morpheus, our UX for contact to make the suggestion.
We had defined the feature before. Please find the attached spec and refer to "Default Contacts edit view (full page)" at p.5. I prefer to change back to this version because it can not only provide a default phone field which user needs the most, but also make the more fields appear in the screen. Let me know if any questions, thanks.
Comment on attachment 8648022 [details] [review] [gaia] mwargers:1191471 > mozilla-b2g:master This fixes the failure in test_keyboard.py at least. Whatever is decided, we can change it back, if the UI changes again.
It also fixes test_add_new_contact.py, btw.
Comment on attachment 8648022 [details] [review] [gaia] mwargers:1191471 > mozilla-b2g:master the test script fix looks good, so we're still awaiting for the Contact view fix right?
Attachment #8648022 - Flags: review?(npark) → review+
Yes, although it's not clear to me what has been decided.
Comment on attachment 8648022 [details] [review] [gaia] mwargers:1191471 > mozilla-b2g:master This scrollIntoView method is great! I think it might be a good thing to make it generic in Base, but I wouldn't block on that.
Attachment #8648022 - Flags: review?(jlorenzo) → review+
(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #16) > This scrollIntoView method is great! I think it might be a good thing to > make it generic in Base, but I wouldn't block on that. I filed bug 1195341 for this. I'm a little surprised you're so enthusiastic about this. I actually half expected, you would reject this, because this doesn't reflect a user action. Merged: https://github.com/mozilla-b2g/gaia/commit/2008f033b5734404f8929191e9cd150c280d9869
Actually I think scrollIntoView sort of does reflect a user action, because when you actually see this being run, it doesn't really do any 'magic' - it scrolls until the element is seen and stops, really useful feature.
Yes, I know, but user isn't doing the scrolling. A user is making a swiping movement on the screen, for which he expects a certain scrolling action to occur at certain points and moments. When we do a scrollIntoView directly, we skip that swiping movement part of the UI testing.
Oh, it appears that scrollIntoView() also works on overflow:hidden elements, so that's clearly a difference with a user, which can't scroll elements with overflow: hidden. I noticed while working on a 2nd pull request using scrollIntoView(true), where the UI suddenly looked weird using that.
[Blocking Requested - why for this release]: Based on Morpheus' explanation (comment 10).
blocking-b2g: --- → 2.5?
Hi Borja, could you please show the default contact fields again? In case of a possible roll back of the NGA work, that will be done from the update view and we introduced this issue (that was an owner's request) when landing the new view so it should not be backed out. Thanks a lot!
Bloking as it was in the spec. This bug will suitable for being unnominated if the workload in blockers is too high.
blocking-b2g: 2.5? → 2.5+
After reverting the commits that gave us separated views in Contacts the issue reported in this bug is not happening anymore in master (as it raised when bug 1183728 landed and it has already been backed out) For that reason, removing the 2.5+ flag and adding [only for NGA Contacts branch] whiteboard to ensure that this bug need to be fixed in NGA branch (but not in current master branch).
blocking-b2g: 2.5+ → ---
Whiteboard: [NG Gaia Contacts][2.5-Daily-Testing][Spark] → [NG Gaia Contacts][2.5-Daily-Testing][Spark][only for NGA Contacts branch]
Target Milestone: FxOS-S7 (18Sep) → FxOS-S8 (02Oct)
Assignee: nobody → borja.bugzilla
Status: NEW → ASSIGNED
Target Milestone: FxOS-S8 (02Oct) → FxOS-S9 (16Oct)
Firefox OS is not being worked on
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.