1174268 - test_setup_basic_gmail.py: "NoSuchElementException: NoSuchElementException: Unable to locate element: Passwd"

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::UI Tests, defect)

Description

[Oliver Nelson [:oliverthor]]

Description:
When the test attempts to perform an automatic setup of Gmail account, it will encounter a new screen UI screen that will block the test from navigating. We'll have to introduce this path through the test.

Repro Steps:
1) Update device to 20150612010203
2) Open the E-Mail app
3) Enter a Name plus Gmail Email address
4) Tap Next
5) Progress through the UI flow

Actual:
After tapping next, user must confirm Email Address and tap next to sign in. Test is expecting being able to enter address here. Then secondary screen will appear confirming account and requesting password. Test attempts to access previous password element for different UI screen and fails. 

Expected: 
UI is successful navigated and flow finds the correct password field.


Traceback (most recent call last):
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.smoke.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_client-0.13-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.smoke.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/tests/functional/email/test_setup_basic_gmail.py", line 28, in test_setup_basic_gmail
self.environment.email['gmail']['password'])
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.smoke.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/apps/email/app.py", line 48, in basic_setup_email
google_login.type_password(password)
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.smoke.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/apps/email/regions/google.py", line 35, in type_password
self.marionette.find_element(*self._password_locator).send_keys(password)
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.smoke.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.7-py2.7.egg/marionette_driver/marionette.py", line 1538, in find_element
response = self._send_message('findElement', 'value', **kwargs)
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.smoke.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.7-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.smoke.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.7-py2.7.egg/marionette_driver/marionette.py", line 711, in _send_message
    self._handle_error(response)
  File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.smoke.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.7-py2.7.egg/marionette_driver/marionette.py", line 747, in _handle_error
    raise errors.lookup(status)(message, stacktrace=stacktrace)
NoSuchElementException: NoSuchElementException: Unable to locate element: Passwd


Environmental Variables:
Device firmware (base) 	L1TC100118D0
Device firmware (date) 	12 Jun 2015 08:30:09
Device firmware (incremental) 	eng.cltbld.20150612.042958
Device firmware (release) 	4.4.2
Device identifier 	flame
Device memory 	219772 kB
Device serial 	f0314099
Device uptime 	0 days 0 hours 2 minutes 19 seconds
Gaia date 	11 Jun 2015 18:09:27
Gaia revision 	9f36b711af75
Gecko build 	20150612010203
Gecko revision 	0093691d3715
Gecko version 	41.0a1


Reproducible manually: YES [no error, but user does encounter an extra UI screen]

Repro frequency: 3/3

Comment 1

[Mike Lien[:mlien]]

It's a generic issue, v2.1 and v2.2 also have this problem

Comment 2

[Martijn Wargers (dead)]

Ok, I have a fix for this, but test_import_contacts_from_gmail.py and test_import_gmail_no_network.py also suffer from this for which I have to adjust 
http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/contacts/regions/gmail.py
(I see many similarities between gmail.py and google.py actually)

Comment 3

[Martijn Wargers (dead)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/30598

Ok, this fixes the failures.
I think there is some follow-up work to do:
- Close the keyboard after entering email and password (because it might be the cause for intermittent failures when tapping the Next button)
- Consolidate the code in gmail.py and google.py

Comment 4

[No-Jun Park [:njpark]]

Comment on attachment 8622559 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/30598

The fix looks good to me, and I do see self.keyboard.dismiss() in gmail.py.  Do you need the command for the keyboard to disappear on other codes as well?

Comment 5

[Johan Lorenzo [:jlorenzo]]

Comment on attachment 8622559 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/30598

I find weird the fact that Marionette doesn't wait for the whole page to be loaded and we need to do [1]. Apart from that, I don't see anything blocking.

[1] https://github.com/mozilla-b2g/gaia/pull/30598/files#diff-150afcb85854944251f36ab53ddec76eR37

Comment 6

[Martijn Wargers (dead)]

(In reply to No-Jun Park [:njpark] from comment #4)
> Comment on attachment 8622559 [details] [review]
> https://github.com/mozilla-b2g/gaia/pull/30598
> The fix looks good to me, and I do see self.keyboard.dismiss() in gmail.py. 
> Do you need the command for the keyboard to disappear on other codes as well?

Yes, we would need it every place where something is typed in an input box, because I remember something about intermittent failures when trying to tap a button when the vkb is still around (sometimes overlapping the button). However, that might not be an issue anymore, nowadays.

Comment 7

[Martijn Wargers (dead)]

Attachment: google.diff

This is to show what happens when I don't have the wait_for_page_load() in there, because I had some discussion with this on irc with Dave Hunt.

This is on top of the attached pull request in this bug.

When running this test, I get this error:
TEST-START | test_setup_basic_gmail.py TestSetupGmail.test_setup_basic_gmail
uninitialized
interactive
TEST-UNEXPECTED-ERROR | test_setup_basic_gmail.py TestSetupGmail.test_setup_basic_gmail | TimeoutException: TimeoutException: Timed out after 5.2 seconds


Traceback (most recent call last):
  File "/Users/mwargers/.virtualenvs/gaia-py-latest/lib/python2.7/site-packages/marionette_client-0.13-py2.7.egg/marionette/marionette_test.py", line 296, in run
    testMethod()
  File "/Users/mwargers/B2G/gaia_clean/tests/python/gaia-ui-tests/gaiatest/tests/functional/email/test_setup_basic_gmail.py", line 28, in test_setup_basic_gmail
    self.environment.email['gmail']['password'])
  File "/Users/mwargers/B2G/gaia_clean/tests/python/gaia-ui-tests/gaiatest/apps/email/app.py", line 50, in basic_setup_email
    google_login.type_password(password)
  File "/Users/mwargers/B2G/gaia_clean/tests/python/gaia-ui-tests/gaiatest/apps/email/regions/google.py", line 59, in type_password
    *self._password_locator))
  File "/Users/mwargers/.virtualenvs/gaia-py-latest/lib/python2.7/site-packages/marionette_driver-0.7-py2.7.egg/marionette_driver/wait.py", line 143, in until
    cause=last_exc)
TEST-INFO took 17939ms

It's stuck on the email page, because tapping on the Next button didn't work.

Comment 8

[Martijn Wargers (dead)]

Attachment: all.diff

Full diff to make it clearer.

Comment 9

[Martijn Wargers (dead)]

Comment on attachment 8622559 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/30598

Dave, let me know what to have changed. In this case, waiting for the page to load is enough to be sure that the Next button can be tapped upon.

I haven't found a better way to make sure that the Next button can be tapped upon. The code that Google uses on that page is quite complicated.

From my point of view, the wait_for_page_load() call works here, but if you prefer a time.sleep(10) here, I can do that.

Comment 10

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Comment on attachment 8622559 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/30598

I feel strongly that we should not wait on the readyState of the document, but instead wait on the elements to be in the state we want them for interaction. When I ran this test locally the issue was that the keyboard was displayed. By adding a line to dismiss this the test passes for me. My diff can be seen here: https://gist.github.com/davehunt/a093d28786077b78b50f

Comment 11

[Martijn Wargers (dead)]

Ah, thanks! So this was the "vkb interfering with tapping" problem. Apparently Marionette can still tap on elements that are hidden behind the vkb here, as it appears here. So I guess my script that waited on the page to load allowed the vkb to fully appear, which makes the tapping not getting interfered anymore by the vb appearing.

Comment 12

[Martijn Wargers (dead)]

Fwiw, I think it would be better if marionette would refuse to tap on elements that are not visible to the user, like in this case where it was obscured by the vkb. It would make it easier to know what the cause of the problem was.

Comment 13

[Martijn Wargers (dead)]

(In reply to Martijn Wargers [:mwargers] (QA) from comment #12)
> Fwiw, I think it would be better if marionette would refuse to tap on
> elements that are not visible to the user, like in this case where it was
> obscured by the vkb. It would make it easier to know what the cause of the
> problem was.

Hrm, otoh, it probably still wouldn't have caught this, because the visibility check would be happening at a point where the element was still not obscured by the vkb.

Comment 14

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to Martijn Wargers [:mwargers] (QA) from comment #12)
> Fwiw, I think it would be better if marionette would refuse to tap on
> elements that are not visible to the user, like in this case where it was
> obscured by the vkb. It would make it easier to know what the cause of the
> problem was.

Marionette should raise an exception if an element is not visible when attempting to interact with it. I believe there are a number of edge cases where this does not work as expected, and like you suggest, we can have elements moving around that causes the check to become stale.

Comment 15

[Martijn Wargers (dead)]

Comment on attachment 8622559 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/30598

Thanks for your help, Dave.
I updated the pull request (with basically your changes) and on b2g desktop it makes test_import_contacts_from_gmail.py and test_setup_basic_gmail.py pass.

Comment 16

[Lance（leave from Mozilla）]

Attachment: https://github.com/mozilla-b2g/gaia/pull/30667

Hi Martijn,
I have run it, and it still passes(10/10). Could you please review this patch. Thanks!

Comment 17

[Martijn Wargers (dead)]

(In reply to Lance from comment #16)
> Created attachment 8624660 [details] [diff] [review]
> https://github.com/mozilla-b2g/gaia/pull/30667
> 
> Hi Martijn,
> I have run it, and it still passes(10/10). Could you please review this
> patch. Thanks!

Is this made from a diff against trunk or something? I see changes that aren't part of the pull request here. But if it works for you, then I'm fine with it.

Comment 18

[Martijn Wargers (dead)]

Comment on attachment 8624660 [details] [diff] [review]
https://github.com/mozilla-b2g/gaia/pull/30667

Ok, at least stuff from the pull request from bug 1116566 is in there. If it's working for you on v2.2, then I guess it's all right. 
But you'll have to wait on the r+ from Dave Hunt first for the original pull request.

Comment 19

[Martijn Wargers (dead)]

Merged: https://github.com/mozilla-b2g/gaia/commit/d8bac9577a537b5e6bafc3f7ed088af5ea60c99e

Merged v2.2: https://github.com/mozilla-b2g/gaia/commit/1f8981d7872e3c0053571c26fb3edaf401844d75

Comment 20

[Hermes Cheng (inactive after July 27, 2015)]

Lance, could you check if it passes at gaia-ui-test smoke test?

Comment 21

[Lance（leave from Mozilla）]

Hi Hermes,

It still passes at gaia-ui-test smoke test.
Fail rate:0/10

Flame 2.2 Build ID: 20150619002501