Closed Bug 1074076 Opened 6 years ago Closed 6 years ago

Multiple test failures in relation to the AwesomeBar


(Mozilla QA Graveyard :: Mozmill Tests, defect, P1)



(firefox32 unaffected, firefox33 unaffected, firefox34 unaffected, firefox35 unaffected, firefox36 fixed, firefox-esr31 unaffected)

Tracking Status
firefox32 --- unaffected
firefox33 --- unaffected
firefox34 --- unaffected
firefox35 --- unaffected
firefox36 --- fixed
firefox-esr31 --- unaffected


(Reporter: andrei, Assigned: danisielm)



(Keywords: regression, Whiteboard: [mozmill-test-failure])


(2 files)

The following 4 tests are affected and constantly failing:
> failed  /testAwesomeBar/testAccessLocationBar.js  testAccessLocationBarHistory  
>   Element.waitForElement(): Element 'ID: mozilla_logo' has been found show more
> failed  /testAwesomeBar/testCheckItemHighlight.js testCheckItemHighlight  
>   description is undefined show more
> failed  /testAwesomeBar/testSuggestBookmarks.js testStarInAutocomplete  
>   The auto-complete result is a bookmark - 'action searchengine' should contain 'bookmark' show more
> failed  /testAwesomeBar/testSuggestHistory.js testSuggestHistoryAndBookmarks  
>   Expected to be one visible result in the autocomplete list - '2' should equal '1' show more
Attached patch skip.patchSplinter Review
Attachment #8496708 - Flags: review?(andreea.matei)
This started on 27.09 and here is the Regression Range from the day before to the day it started:

I see 3 candidates here: Bug 1067896, Bug 1067888 and Bug 1067899.

Not sure which of them is the cause, but we'll find out once we have the regression range ready.
Comment on attachment 8496708 [details] [diff] [review]

Review of attachment 8496708 [details] [diff] [review]:

Looks good, lets land this.
Attachment #8496708 - Flags: review?(andreea.matei) → review+
(In reply to daniel.gherasim from comment #6)
> testSwitchTab is also failing, see:
> f11964362bbc85ebfbc5b36de7aaccaa
> f11964362bbc85ebfbc5b36de7962273
> f11964362bbc85ebfbc5b36de7b7eea1

Interesting, that seems to be failing only intermittently. Keep an eye out for those if they keep failing even with the other tests disabled.
I've actually reproduced the switchToTab failure locally in a Win VM:
Pushlog from fx-team:

So bug 1067888 is the reason here. Actually a pre-configured item representing the search engine appears always as the first element of autocomplete results. In our tests we press the "DOWN" button to select the first element, we may have to press twice now to select the correct one, and also update the checks to check for the 2nd element in the autocomplete results popup.

I will come with a fix soon.
Assignee: nobody → daniel.gherasim
Blocks: 1067888
Attached patch fix.patchSplinter Review
And here is the fix patch.
Attachment #8497387 - Flags: review?(andrei.eftimie)
Attachment #8497387 - Flags: review?(andreea.matei)
Comment on attachment 8497387 [details] [diff] [review]

Review of attachment 8497387 [details] [diff] [review]:
----------------------------------------------------------------- (default)
Attachment #8497387 - Flags: review?(andrei.eftimie)
Attachment #8497387 - Flags: review?(andreea.matei)
Attachment #8497387 - Flags: review+
Attachment #8497387 - Flags: checkin+
I was looking if there's a better way to handle this, but the tests changed in the original change from mc have the same thing (push twice the VK_DOWN etc). So this should be good enough.

Closed: 6 years ago
Resolution: --- → FIXED
Thank you Daniel for this quick investigation and fix!
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.