Closed
Bug 609077
Opened 14 years ago
Closed 13 years ago
Timeout exceeded for 'subject.popup.state == 'open'' in testSearchSuggestions.js
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: u279076, Assigned: whimboo)
References
()
Details
(Whiteboard: [mozmill-branch-fail][mozmill-test-failure])
Attachments
(3 files, 1 obsolete file)
2.65 KB,
patch
|
davehunt
:
review+
|
Details | Diff | Splinter Review |
8.50 KB,
patch
|
davehunt
:
review+
|
Details | Diff | Splinter Review |
840 bytes,
patch
|
u279076
:
review+
|
Details | Diff | Splinter Review |
MODULE: testSearch/testSearchSuggestions.js TEST: testMultipleEngines ERROR: controller.waitForEval: Timeout exceeded for 'subject.popup.state == 'open'' BRANCH: All PLATFORM: All
Whiteboard: [mozmill-branch-fail] → [mozmill-branch-fail][mozmill-test-failure]
Comment 1•14 years ago
|
||
The only way I've been able to reproduce this is by unfocusing the browser.
Assignee | ||
Comment 2•14 years ago
|
||
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.
http://mozmill-release.brasstacks.mozilla.com/#/general/failure?test=firefox%2FtestSearch%2FtestSearchSuggestions.js&func=testMultipleEngines This has happened 3 times in the last week on both branches, linux-only.
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.
Assignee | ||
Comment 7•14 years ago
|
||
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
Comment 8•13 years ago
|
||
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?
Assignee | ||
Comment 9•13 years ago
|
||
Is it waiting for the search suggestions popup? I miss a bit of context in comment 4.
Comment 10•13 years ago
|
||
Is this still occuring? I havn't seen it of recent.
Assignee | ||
Comment 11•13 years ago
|
||
See the URL. It's a daily problem across branches.
Comment 12•13 years ago
|
||
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.
Assignee | ||
Comment 13•13 years ago
|
||
Oh, I can remember bug 542990!! Do we probably run into this problem? If yes, we should really type slower in the meantime.
Comment 14•13 years ago
|
||
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.
Assignee | ||
Comment 15•13 years ago
|
||
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
Assignee | ||
Comment 16•13 years ago
|
||
Comment 17•13 years ago
|
||
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.
Assignee | ||
Comment 18•13 years ago
|
||
(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.
Assignee | ||
Comment 19•13 years ago
|
||
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 20•13 years ago
|
||
Comment on attachment 503834 [details] [diff] [review] Patch v1 Looks good to me.
Attachment #503834 -
Flags: review?(dave.hunt) → review+
Assignee | ||
Comment 21•13 years ago
|
||
Attachment #503849 -
Flags: review?(dave.hunt)
Assignee | ||
Comment 22•13 years ago
|
||
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 23•13 years ago
|
||
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+
Assignee | ||
Comment 24•13 years ago
|
||
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]
Assignee | ||
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 25•13 years ago
|
||
Not completely fixed. At least Linux still encounters this failure.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 26•13 years ago
|
||
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
Assignee | ||
Comment 27•13 years ago
|
||
Attachment #526041 -
Flags: review?(anthony.s.hughes)
Attachment #526041 -
Flags: review?(anthony.s.hughes) → review+
Assignee | ||
Comment 28•13 years ago
|
||
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: 13 years ago → 13 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•