1057416 - Test failure 'aElem is undefined' in testAddons/testInstallAddonWithoutEula.js Remote test

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[Andreea Matei [:AndreeaMatei]]

Failed with Beta sv-SE on OS X 10.6.8, once:
http://mozmill-release.blargon7.com/#/remote/report/2561af7d8c83a450772e8c4380cee836

We'll monitor if it fails again.

Comment 1

[Cosmin Malutan, [:cosmin-malutan]]

I ran this test for a couple of times and it doesn't reproduce, after looking at the report I incline to think this is a network related failure.
http://mozmill-crowd.blargon7.com/#/remote/report/2f56cb3a3728c2c47cd1b44f77298071

Comment 2

[Tracy Walker [:tracy]]

This appeared against 33.0b2 in very high volume mast night. It's not just sv-SE and not just on Mac.  This bug and bug 847885.

Comment 3

[Teodor Druta]

Attachment: b1057416.patch

Comment 5

[Andrei Eftimie]

With the argument name change it seems I missed this bug and recently opened a new one.

Some information from the now duped bug 1086266

We had a few others in the past:
> 2014-10-21T11:29:08.000Z  Firefox 34.0 (20141020184313) Mac OS X 10.7.5 mr  aElem is undefined
> 2014-09-24T13:42:45.000Z  Firefox 33.0 (20140923222114) Mac OS X 10.9.4 ja-JP-mac aElem is undefined
> 2014-09-12T09:58:08.000Z  Firefox 33.0 (20140911191954) Win 6.0.6002  fr  aElem is undefined
> 2014-09-09T09:34:44.000Z  Firefox 33.0 (20140908190852) Win 6.2.9200  hr  aElem is undefined
> 2014-09-09T08:22:28.000Z  Firefox 33.0 (20140908190852) Win 5.1.2600  fr  aElem is undefined
> 2014-09-09T08:02:26.000Z  Firefox 33.0 (20140908190852) Mac OS X 10.6.8 bg  aElem is undefined
> 2014-09-09T07:54:27.000Z  Firefox 33.0 (20140908190852) Mac OS X 10.7.5 vi  aElem is undefined
> 2014-09-09T07:52:27.000Z  Firefox 33.0 (20140908190852) Linux Ubuntu 12.04  id  aElem is undefined
> 2014-09-09T07:51:59.000Z  Firefox 33.0 (20140908190852) Linux Ubuntu 12.04  he  aElem is undefined
> 2014-09-09T07:51:58.000Z  Firefox 33.0 (20140908190852) Linux Ubuntu 13.10  tr  aElem is undefined
> 2014-09-09T07:51:51.000Z  Firefox 33.0 (20140908190852) Linux Ubuntu 12.04  vi  aElem is undefined
> 2014-09-09T07:43:59.000Z  Firefox 33.0 (20140908190852) Linux Ubuntu 12.04  bg  aElem is undefined
> 2014-09-09T07:43:30.000Z  Firefox 33.0 (20140908190852) Linux Ubuntu 12.04  th  aElem is undefined
> 2014-09-09T07:43:29.000Z  Firefox 33.0 (20140908190852) Linux Ubuntu 12.04  tr  aElem is undefined


If I remember correctly in 2014-09-09 we had a big network outage. If that is true, possible this failure is network related. This is what Tracy mentioned in comment 2 about a high failure rate.

Comment 6

[Andrei Eftimie]

Comment on attachment 8506929 [details] [diff] [review]
b1057416.patch

Review of attachment 8506929 [details] [diff] [review]:
-----------------------------------------------------------------

I don't think your proposed solution would help in any particular way.

Were you able to reproduce the issue? It would be great to share any particular info you have when you upload a patch.
I still feel this failure is network related.

We had 1 instance yesterday, but on a now known bad machine:
http://mozmill-release.blargon7.com/#/remote/report/447e3274a76247e6567e1c2aa64a9ea8 (see bug 1086266)

And the last previous failure is more then 1 month old:
http://mozmill-release.blargon7.com/#/remote/report/bfd52839a01858de2f33d25f769ec689

----

We might not be able to have a solution in mozmill-tests for this issue.

::: firefox/tests/remote/restartTests/testAddons_InstallAddonWithoutEULA/test1.js
@@ +73,1 @@
>      expect.waitFor(() => utils.isDisplayed(controller, addButton),

We already wait for the button to be visible. Both waitForElement and waitThenClick should be redundant in this case.

::: lib/addons.js
@@ +1744,2 @@
>    assert.waitFor(function () {
>      return !installButton.getNode().disabled;

Same here. We have the node, and we wait for the disable attribute to be gone.

Comment 7

[Teodor Druta]

I could reproduce it at the time I wrote the patch. I tried to reproduce it now and it didn't failed at all.

::: lib/addons.js
@@ +1744,2 @@
>    assert.waitFor(function () {
>      return !installButton.getNode().disabled;

Here the installButton.getNode() returned null that's why I've added the:
>    installButton.waitForElement();
line above it.

::: firefox/tests/remote/restartTests/testAddons_InstallAddonWithoutEULA/test1.js
@@ +73,1 @@
>      expect.waitFor(() => utils.isDisplayed(controller, addButton),

same here, the addButton was a null object, so I've added the line:
>      addButton.waitForElement();
above

Comment 8

[Andrei Eftimie]

(In reply to Teodor Druta from comment #7)
> I could reproduce it at the time I wrote the patch. I tried to reproduce it
> now and it didn't failed at all.
> 
> ::: lib/addons.js
> @@ +1744,2 @@
> >    assert.waitFor(function () {
> >      return !installButton.getNode().disabled;
> 
> Here the installButton.getNode() returned null that's why I've added the:

Sure, that's why this code is wrapped in a waitFor call. This will run until it returns true or we reach the timeout value (5sec by default)

Comment 9

[Mihaela Velimiroviciu (:mihaelav)]

I re-enabled the tests on beta and ran the testrun, but the failure didn't reproduce.
Reports: http://mozmill-crowd.blargon7.com/#/remote/reports?app=All&branch=36&platform=Win&from=2015-02-03&to=2015-02-03

Comment 10

[Teodor Druta]

Even though this is not failing any more, it could be failing again sometime in the future, because we should change the way we handle the "install-button" element, I filed Bug 1128946 for that.

Comment 11

[Teodor Druta]

This should've been fixed by Bug 1128946, event if it doesn't (not likely) this failure will not be seen anymore. Let's mark the branches as verified. And bug as fixed.