Closed Bug 609077 Opened 9 years ago Closed 9 years ago

Timeout exceeded for 'subject.popup.state == 'open'' in testSearchSuggestions.js

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

All
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ashughes, Assigned: whimboo)

References

()

Details

(Whiteboard: [mozmill-branch-fail][mozmill-test-failure])

Attachments

(3 files, 1 obsolete file)

MODULE: testSearch/testSearchSuggestions.js
TEST: testMultipleEngines
ERROR: controller.waitForEval: Timeout exceeded for 'subject.popup.state == 'open''
BRANCH: All
PLATFORM: All
Blocks: 604718
Whiteboard: [mozmill-branch-fail]
Whiteboard: [mozmill-branch-fail] → [mozmill-branch-fail][mozmill-test-failure]
The only way I've been able to reproduce this is by unfocusing the browser.
How often does it occur? Would be helpful to have the link to the top failures page in the url field. It shoulnd't have a timerange set.
Test is failing due to an issue in the Search API:

  getSuggestions : function(searchTerm) {
    var suggestions = [ ];
    var popup = this.getElement({type: "searchBar_autoCompletePopup"});
    var treeElem = this.getElement({type: "searchBar_suggestions"});

    // Enter search term and wait for the popup
--> this.type(searchTerm);

This is intermittent, but it seems the searchbox does not have focus as nothing is typed into the box.  The test fails because it is expecting the autocomplete list, but since we don't actually type, the box doesnt appear.

I'm wondering if there isn't some way we can do a check for focus in the API itself.
Geo and Henrik, any feedback you can give me here would be great!
We checked the mozmill code that'd handle the type, and it should be implicitly setting the focus.  However, there's a check there that amounts to "if !focused, set focus" and possible that if !focused is somehow not working right.

Try adding:

this.focus("click");

...just above the this.type() line and see what happens.  If it succeeds consistently, then the focus handling in mozmill's typing needs to be looked at.
Move of Mozmill Test related project bugs to newly created components. You can
filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.
Product: Testing → Mozilla QA
I can reliably replicate this on my Ubuntu 10.4 VM, however I *am* seeing the term entered into the search box. I have tried Geo's focus suggestion with no luck. I have also tried adding a delay between each key press, adding sleeps, etc. Any other suggestions?
Is it waiting for the search suggestions popup? I miss a bit of context in comment 4.
Is this still occuring? I havn't seen it of recent.
See the URL. It's a daily problem across branches.
The search term is entered but the search suggestions popup does not display. The test fails because it is waiting for the popup to display.
Oh, I can remember bug 542990!! Do we probably run into this problem? If yes, we should really type slower in the meantime.
I don't believe that's the problem here. I've tried modifying the test to type slower without success. Also, the current search stem used in the test is "Moz" and if I put a sleep after it's typed and then type and additional "i" myself, then I get the search suggestions popup. I also tried changing the search stem to "Mozi" in the test but it made no difference.
I still think it is related, at least given your last comment. On which platform you can reliable reproduce this failure? Do I have to run other tests before?
Summary: Timeout failure in testMultipleEngines → Timeout exceeded for 'subject.popup.state == 'open'' in testSearchSuggestions.js
Attached patch testcase (with loop) (obsolete) — Splinter Review
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Attachment #503810 - Flags: feedback?(dave.hunt)
The loop doesn't really give much benefit as the search results are being cached, so subsequent searches will appear much faster.

I had to increase the value of TIMEOUT_REQUEST_SUGGESTIONS to 750 for this to reliably pass for me. Might want to pad that a little for slower connections.
(In reply to comment #17)
> The loop doesn't really give much benefit as the search results are being
> cached, so subsequent searches will appear much faster.

As far as I know we do not cache any data we get back from the XHR request. So nothing will be cached here. In my case it will even fail in the >5 iteration if I remove the patch for getSuggestions.

> I had to increase the value of TIMEOUT_REQUEST_SUGGESTIONS to 750 for this to
> reliably pass for me. Might want to pad that a little for slower connections.

The reason here could be that it take a split of a second until the request has been send out. Using 500ms here is will return too early, so we fire new requests even with the old one not timed out. See bug 392633. It makes sense to increase it. Lets take 750ms for now.
Attached patch Patch v1Splinter Review
Increased the timeout as given by the last comments. In the future we should try to make this test work with local data to kill this external dependency.
Attachment #503810 - Attachment is obsolete: true
Attachment #503834 - Flags: review?(dave.hunt)
Attachment #503810 - Flags: feedback?(dave.hunt)
Comment on attachment 503834 [details] [diff] [review]
Patch v1

Looks good to me.
Attachment #503834 - Flags: review?(dave.hunt) → review+
Comment on attachment 503849 [details] [diff] [review]
Backport (1.9.2/1.9.1) [checked-in]

Also applies cleanly on 1.9.1
Attachment #503849 - Attachment description: Backport (1.9.2) → Backport (1.9.2/1.9.1)
Comment on attachment 503849 [details] [diff] [review]
Backport (1.9.2/1.9.1) [checked-in]

Looks good.
Attachment #503849 - Flags: review?(dave.hunt) → review+
Comment on attachment 503849 [details] [diff] [review]
Backport (1.9.2/1.9.1) [checked-in]

Landed as:
http://hg.mozilla.org/qa/mozmill-tests/rev/c30521cacecf (1.9.2)
http://hg.mozilla.org/qa/mozmill-tests/rev/680398975766 (1.9.1)
Attachment #503849 - Attachment description: Backport (1.9.2/1.9.1) → Backport (1.9.2/1.9.1) [checked-in]
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Not completely fixed. At least Linux still encounters this failure.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This test fails only on Linux and I would propose to simply disable it on 3.6 and 3.5 for this platform. Patch upcoming.
Status: REOPENED → ASSIGNED
OS: All → Linux
Attachment #526041 - Flags: review?(anthony.s.hughes)
Attachment #526041 - Flags: review?(anthony.s.hughes) → review+
Landed as:
http://hg.mozilla.org/qa/mozmill-tests/rev/7b3337835ee3 (1.9.2)
http://hg.mozilla.org/qa/mozmill-tests/rev/c462fb571465 (1.9.1)

I will update Litmus to ensure this is not covered on both branches.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.