Closed
Bug 995019
Opened 10 years ago
Closed 10 years ago
Intermittent failing test, test_homescreen_delete_app.py test_homescreen_delete_app.TestDeleteApp.test_delete_app
Categories
(Firefox OS Graveyard :: Gaia::UI Tests, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kgrandon, Assigned: zcampbell)
References
Details
Attachments
(1 file)
This test seems to be failing more and more on travis, and today it's gotten up to 50% or more of all builds. We need to disable this while we investigate what's going on. TEST-START test_homescreen_delete_app.py test_delete_app (test_homescreen_delete_app.TestDeleteApp) ... ERROR ====================================================================== ERROR: None ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/mozilla-b2g/gaia/travis_venv/local/lib/python2.7/site-packages/marionette_client-0.7.5-py2.7.egg/marionette/marionette_test.py", line 163, in run testMethod() File "/home/travis/build/mozilla-b2g/gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/homescreen/test_homescreen_delete_app.py", line 52, in test_delete_app self.homescreen.wait_for_app_icon_not_present(self.APP_NAME) File "/home/travis/build/mozilla-b2g/gaia/tests/python/gaia-ui-tests/gaiatest/apps/homescreen/app.py", line 44, in wait_for_app_icon_not_present self.wait_for_element_not_present(self._homescreen_icon_locator[0], self._homescreen_icon_locator[1] % app_name) File "/home/travis/build/mozilla-b2g/gaia/tests/python/gaia-ui-tests/gaiatest/apps/base.py", line 35, in wait_for_element_not_present lambda m: not m.find_element(by, locator)) File "/home/travis/build/mozilla-b2g/gaia/travis_venv/local/lib/python2.7/site-packages/marionette_client-0.7.5-py2.7.egg/marionette/wait.py", line 143, in until cause=last_exc) TimeoutException: TimeoutException: Timed out after 10.0153160095 seconds TEST-UNEXPECTED-FAIL | test_homescreen_delete_app.py test_homescreen_delete_app.TestDeleteApp.test_delete_app |
Reporter | ||
Comment 1•10 years ago
|
||
This test has been disabled in: https://github.com/mozilla-b2g/gaia/commit/866c05655407097b4d56d72b418920100e029e2c Zac - can you get someone to investigate this? Thanks!
Flags: needinfo?(zcampbell)
Keywords: leave-open
Comment 3•10 years ago
|
||
This is a case of the button being visible but not usable yet: "ElementNotVisibleException: Element is not currently visible and may not be manipulated". I tried waiting for: confirm_button = self.marionette.find_element(*self._confirm_button_locator) confirm_dialog_menu = self.marionette.find_element(*self._confirm_dialog_menu) self.wait_for_condition(lambda m: confirm_dialog_menu.location['x'] + confirm_button.location['x'] == confirm_button.location['x']) But this does not help either.
Comment 4•10 years ago
|
||
confirm_button = self.marionette.find_element(*self._confirm_button_locator) self.wait_for_condition(lambda m: confirm_button.is_displayed()) Does not seem to help :(
Comment 5•10 years ago
|
||
Changed Travis script also, for tests.
Assignee | ||
Comment 6•10 years ago
|
||
(In reply to [:AndreiH] from comment #5) > Created attachment 8405344 [details] [review] > PR https://github.com/mozilla-b2g/gaia/pull/18228 > > Changed Travis script also, for tests. I've seen this on v1.4 too. If we do go with a 'hack' like this then we should file a bug against the app requesting a 'loaded' class and then refer to that in the code comment.
Updated•10 years ago
|
Assignee: nobody → andrei.hutusoru
Comment 7•10 years ago
|
||
(In reply to Zac C (:zac) from comment #6) > (In reply to [:AndreiH] from comment #5) > > Created attachment 8405344 [details] [review] > > PR https://github.com/mozilla-b2g/gaia/pull/18228 > > > > Changed Travis script also, for tests. > > I've seen this on v1.4 too. > If we do go with a 'hack' like this then we should file a bug against the > app requesting a 'loaded' class and then refer to that in the code comment. Sounds good to me. I will file a bug requesting a 'loaded' class. For what gaia component should this bug be filed?
Comment 8•10 years ago
|
||
zac but this cannot be reproducible manually. If this is the case should we open a bug to request a "loaded: class just because our automated tests requires this?
Updated•10 years ago
|
Flags: needinfo?(zcampbell)
Assignee | ||
Comment 9•10 years ago
|
||
(In reply to [:AndreiH] from comment #8) > zac but this cannot be reproducible manually. > If this is the case should we open a bug to request a "loaded: class just > because our automated tests requires this? yeah let's do it, we need stability on this.
Flags: needinfo?(zcampbell)
Comment 10•10 years ago
|
||
I added another wait : 'self.wait_for_condition(lambda m: m.find_element(*self._confirm_dialog_locator).get_attribute('class')=='visible show')' Let's see how Travis likes it this way.
Assignee | ||
Updated•10 years ago
|
Priority: -- → P1
Updated•10 years ago
|
Attachment #8405344 -
Flags: review?(zcampbell)
Attachment #8405344 -
Flags: review?(florin.strugariu)
Updated•10 years ago
|
Attachment #8405344 -
Flags: review?(florin.strugariu) → review+
Assignee | ||
Comment 11•10 years ago
|
||
Comment on attachment 8405344 [details] [review] PR https://github.com/mozilla-b2g/gaia/pull/18228 r+
Attachment #8405344 -
Flags: review?(zcampbell) → review+
Assignee | ||
Comment 12•10 years ago
|
||
Merged: https://github.com/mozilla-b2g/gaia/commit/45f8ee7409d638a84635647e2e5d375f3e131ef0
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 13•10 years ago
|
||
I can still this intermittent failure on master or v2.0, master, https://bugzilla.mozilla.org/show_bug.cgi?id=1016850#c8 v2.0, https://travis-ci.org/mozilla-b2g/gaia/jobs/28486780 -- Zac, Do we need to re-open this bug or disable this test? Thanks.
Flags: needinfo?(zcampbell)
Assignee | ||
Comment 14•10 years ago
|
||
really annoying, the output report has not uploaded to AWS on that job so I can't debug it :(
Flags: needinfo?(zcampbell)
Assignee | ||
Comment 15•10 years ago
|
||
I will try locally.
Assignee: andrei.hutusoru → zcampbell
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 16•10 years ago
|
||
The failure in comment#13 is a dupe of bug 1016850. I'll reclose this as per its original resolution and move discussion over to that bug.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 17•10 years ago
|
||
(In reply to Zac C (:zac) from comment #16) > The failure in comment#13 is a dupe of bug 1016850. > > I'll reclose this as per its original resolution and move discussion over to > that bug. Sorry, if this caused any confusion, but I was thinking to move the discussion here, since I thought bug 1016850 is just about moving the patch here to v1.4. Actually, I thought we should have set bug 1016850 a dupe of this bug, since these 2 bugs talk about the same issue, right?
Comment 18•6 years ago
|
||
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in
before you can comment on or make changes to this bug.
Description
•