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

RESOLVED FIXED

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: AndreeaMatei, Unassigned)

Tracking

unspecified

Firefox Tracking Flags

(firefox32 wontfix, firefox33 wontfix, firefox34 wontfix, firefox35 verified, firefox36 verified, firefox37 verified, firefox38 verified, firefox-esr31 verified)

Details

(Whiteboard: [mozmill-test-failure], URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

4 years ago
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.
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
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.
OS: Mac OS X → All
Hardware: x86_64 → All
Summary: [sv-SE] Test failure "elem is undefined" in testAddons_InstallAddonWithoutEULA/test1.js → Test failure "elem is undefined" in testAddons_InstallAddonWithoutEULA/test1.js

Updated

4 years ago
Assignee: nobody → teodor.druta

Updated

4 years ago
Status: NEW → ASSIGNED

Comment 3

4 years ago
Created attachment 8506929 [details] [diff] [review]
b1057416.patch
Attachment #8506929 - Flags: review?(andrei.eftimie)
Attachment #8506929 - Flags: review?(andreea.matei)

Updated

4 years ago
Duplicate of this bug: 1086266

Comment 5

4 years ago
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.
status-firefox33: --- → affected
status-firefox34: --- → affected
Summary: Test failure "elem is undefined" in testAddons_InstallAddonWithoutEULA/test1.js → Test failure 'aElem is undefined' in /restartTests/testAddons_InstallAddonWithoutEULA/test1.js

Comment 6

4 years ago
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.
Attachment #8506929 - Flags: review?(andrei.eftimie)
Attachment #8506929 - Flags: review?(andreea.matei)
Attachment #8506929 - Flags: review-

Comment 7

4 years ago
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

4 years ago
(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)

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME

Updated

4 years ago
Assignee: teodor.druta → nobody
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Test failure 'aElem is undefined' in /restartTests/testAddons_InstallAddonWithoutEULA/test1.js → Test failure 'aElem is undefined' in testAddons/testInstallAddonWithoutEula.js Remote test
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

Updated

4 years ago
status-firefox32: affected → wontfix
status-firefox33: affected → wontfix
status-firefox34: affected → wontfix
status-firefox35: --- → affected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox-esr31: --- → wontfix

Comment 10

4 years ago
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.
Depends on: 1128946

Updated

4 years ago
Attachment #8506929 - Attachment is obsolete: true

Comment 11

4 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
status-firefox35: affected → verified
status-firefox36: affected → verified
status-firefox37: affected → verified
status-firefox38: affected → verified
status-firefox-esr31: wontfix → verified
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.