860655 - elementslib.ID() fails to grab the element - "could not find element ID: id"

Status: RESOLVED FIXED

(Testing Graveyard :: Mozmill, defect)

Description

[Andrei Eftimie]

elementslib.ID() fails to grab the element

Affected tests:

> /testSecurity/testSafeBrowsingNotificationBar.js
> /testSecurity/testSafeBrowsingWarningPages.js 
> /testTabbedBrowsing/testOpenInBackground.js
> /testTabbedBrowsing/testOpenInForeground.js
> /testToolbar/testStopReloadButtons.js
> /restartTests/testAddons_installMultipleExtensions/test1.js

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Is any of those failures related to an additional page load as for the other bug you lately filed?

Comment 2

[Andrei Eftimie]

They don't appear to be, that's why I filed them separately.

bug 860658 has an explicit page reload then uses the same elements declared before and it fails.
if we redeclare the elements after the reload those tests work fine

In this case however, we fail with "could not find element ID:"
Have not reached a conclusion on why this happens (element might not be ready?, context might be wrong?)

Comment 3

[cmtalbert]

Potentially blocking, but this needs investigation.  If investigation shows that it is not a widespread issue then we can determine blocking status at that time.

Comment 4

[mario garbi]

This depends on bug 761600 as we fail due to elements that either aren't on the page yet or we expect them not to be on the page.

Will have to recheck after bug 761600 lands.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to mario garbi from comment #4)
> This depends on bug 761600 as we fail due to elements that either aren't on
> the page yet or we expect them not to be on the page.

I still don't see any relation to bug 761600 yet. Bug 761600 will only affect us when an element gets used again after a reload of the document. I don't think that this is happening here. See also comment 2 from Andrei. Please come up with a simplified testcase.

Comment 6

[Andrei Eftimie]

It was my suggestion to mark this as dependent on bug 761600 after seeing more of Mario's investigation into them.

It does seem that elements are searched in the DOM at declaration time rather then at invocation time. A simplified testcase might help, but I would also like to see bug 761600 land as quickly as possible and then see which issues still remain on the table for mozmill 2.0

It would probably fix most of the failures we see now.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Andrei Eftimie from comment #6)
> It does seem that elements are searched in the DOM at declaration time
> rather then at invocation time. A simplified testcase might help, but I

If that's the case it is totally different and not related. So please give us a testcase where we can reproduce this problem.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: testcase

Testcase to reproduce the problem. Strange is that it works like a charm in Aurora but not in Nightly, Beta, Release, and Esr17.

Comment 9

[Andreea Matei [:AndreeaMatei]]

Attachment: testcase security

This testcase is reproducing the failing steps from the 2 security tests affected.

After accessing the warning page, we want to take 'main-feature' id before the element is available. It belongs to the page loaded after clicking "Ignore Warning".

If you comment the element from line 12 and uncomment the one at the bottom, testcase will pass.

Is this related to bug 761600? Also if we move the element at the bottom but leave this line:
  assert.ok(!ignoreWarningButton.exists(), "'Ignore warning' button has not been found");

we get "can't access dead object", the element not being on the current page.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Andreea Matei [:AndreeaMatei] from comment #9)
> If you comment the element from line 12 and uncomment the one at the bottom,
> testcase will pass.

Everything in this testcase *after* the 2nd controller.waitForPageLoad() call is bug 761600. Please try to not mix-up testcases.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

All of those cases have been fixed and are working as expected with my fix on bug 761600.