1191471 - [Contacts] Creating a new contact has no default fields populated

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Description

[Adam Alldredge [:AdamA][Inactive]]

Attachment: logcat

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

Comment 1

[Adam Alldredge [:AdamA][Inactive]]

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

Comment 2

[Adam Alldredge [:AdamA][Inactive]]

Attachment: No contacts auto populated

Comment 3

[Oliver Nelson [:oliverthor]]

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

Comment 4

[Adam Alldredge [:AdamA][Inactive]]

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.

Comment 5

[Maria Angeles Oteo (:oteo)]

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...

Comment 6

[Francisco Jordano [:arcturus] [:francisco]]

Right,

It was decided to keep the fields not open by default. Will defer this decision to ux team.

Harley wdyt?

Comment 7

[Harly Hsu[:harly]]

Hi Francisco, Is there a reason why we change the previous design to not show any fields by default?

Comment 8

[Francisco Jordano [:arcturus] [:francisco]]

Hi Harly,

was an engineering decision, to make the more fields appear in the screen, we can rollback to your suggestion.

Comment 9

[Harly Hsu[:harly]]

NI Morpheus, our UX for contact to make the suggestion.

Comment 10

[Morpheus Chen [:morpheus] UX]

Attachment: [2.1 Contacts] Actionable field - Contact edit page redesign v0.2.pdf

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 11

[GitHub Autolander Bot]

Attachment: [gaia] mwargers:1191471 > mozilla-b2g:master

Comment 12

[Martijn Wargers (dead)]

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.

Comment 13

[Martijn Wargers (dead)]

It also fixes test_add_new_contact.py, btw.

Comment 14

[No-Jun Park [:njpark]]

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?

Comment 15

[Martijn Wargers (dead)]

Yes, although it's not clear to me what has been decided.

Comment 16

[Johan Lorenzo [:jlorenzo]]

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.

Comment 17

[Martijn Wargers (dead)]

(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

Comment 18

[No-Jun Park [:njpark]]

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.

Comment 19

[Martijn Wargers (dead)]

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.

Comment 20

[Martijn Wargers (dead)]

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.

Comment 21

[Johan Lorenzo [:jlorenzo]]

[Blocking Requested - why for this release]: Based on Morpheus' explanation (comment 10).

Comment 22

[Maria Angeles Oteo (:oteo)]

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!

Comment 23

[Francisco Jordano [:arcturus] [:francisco]]

Bloking as it was in the spec.

This bug will suitable for being unnominated if the workload in blockers is too high.

Comment 24

[Maria Angeles Oteo (:oteo)]

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).

Comment 25

[BMO Automation]

Firefox OS is not being worked on