Closed
Bug 719984
Opened 12 years ago
Closed 12 years ago
Failure in tesToolbar/testStopReloadButtons.js | Timeout exceeded for waitForElement ID: header
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: u279076, Assigned: remus.pop)
References
()
Details
(Whiteboard: [mozmill-test-failure])
Attachments
(1 file, 1 obsolete file)
1.47 KB,
patch
|
whimboo
:
review+
|
Details | Diff | Splinter Review |
The following failure happens on release branch only. Please investigate as a possible regression. Note that this is the same test, but not the same failure as bug 554883.
Updated•12 years ago
|
Assignee: nobody → alex.lakatos
Status: NEW → ASSIGNED
Comment 1•12 years ago
|
||
This failed on the 18th only, across branches and platforms. I suspect it has the same cause as bug 719987 (Mozilla website changed due to SOPA protest). Marking this RESOLVED WORKSFORME as well.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 2•12 years ago
|
||
Fails locally on all platforms. Maybe a recently change which got into mozilla.org production after the automation daily, because there are no failures in the dashboard. My result for Linux is here: http://mozmill-crowd.blargon7.com/#/functional/report/e1a0928e536ababe778cc98b7c131deb
Assignee: alex.lakatos → remus.pop
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Assignee | ||
Comment 3•12 years ago
|
||
ID of the header changed. Also added a constant for better managing.
Attachment #610859 -
Flags: review?(vlad.mozbugs)
Comment 4•12 years ago
|
||
Comment on attachment 610859 [details] [diff] [review] patch v1 (all branches) This is a +. Thanks Remus, we need to checkin this asap so over to Anthony for sr
Attachment #610859 -
Flags: review?(vlad.mozbugs)
Attachment #610859 -
Flags: review?(ahughes)
Attachment #610859 -
Flags: review+
Comment 5•12 years ago
|
||
Comment on attachment 610859 [details] [diff] [review] patch v1 (all branches) ups sorry, wrong person :) Our Anthony now
Attachment #610859 -
Flags: review?(ahughes) → review?(anthony.s.hughes)
Comment 6•12 years ago
|
||
Remus this should really have been a new bug. It's a totally new issue.
Comment 7•12 years ago
|
||
Comment on attachment 610859 [details] [diff] [review] patch v1 (all branches) We can't wait long for the review to be done. Looks good but I don't see a reason to move it up to a constant for now. I will revert this back and land it right away. Thanks Remus for the investigation.
Attachment #610859 -
Flags: review?(anthony.s.hughes) → review+
Comment 8•12 years ago
|
||
Removed the global constant and also the second call to re-init the element which is not necessary anymore. It was a workaround some time before when we lost references to elements after a page reload.
Attachment #610859 -
Attachment is obsolete: true
Attachment #611132 -
Flags: review+
Comment 9•12 years ago
|
||
Landed across brances: http://hg.mozilla.org/qa/mozmill-tests/rev/f9b73bdfb82f (default) http://hg.mozilla.org/qa/mozmill-tests/rev/ae17d1e22038 (aurora) http://hg.mozilla.org/qa/mozmill-tests/rev/2a7cb793538b (beta) http://hg.mozilla.org/qa/mozmill-tests/rev/24e2ab1521ae (release) http://hg.mozilla.org/qa/mozmill-tests/rev/fd9a59225cb4 (esr10) http://hg.mozilla.org/qa/mozmill-tests/rev/af25a3e73f81 (1.9.2) Remus, would you mind to create a new bug which we can use to move to a test file on mozqa? That would stop us from relying on external content. Not sure yet, if we can have a local test case for this purpose.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•12 years ago
|
||
Comment on attachment 611132 [details] [diff] [review] fix v1.1 [landed] Thanks for taking this Henrik. I got side-tracked with Firefox 12b3 testing yesterday and missed this review.
Attachment #611132 -
Attachment description: Updated patch → fix v1.1 [landed]
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #9) > Remus, would you mind to create a new bug which we can use to move to a test > file on mozqa? That would stop us from relying on external content. Not sure > yet, if we can have a local test case for this purpose. Henrik I think that would be possible if the stop button would allow us to stop a script from executing as follows: script will have 1 sec timeout to load some content, after main content is loaded. So pressing stop will not load second content.
Reporter | ||
Comment 12•12 years ago
|
||
(In reply to Remus Pop (:RemusPop) from comment #11) > (In reply to Henrik Skupin (:whimboo) from comment #9) > > > Remus, would you mind to create a new bug which we can use to move to a test > > file on mozqa? That would stop us from relying on external content. Not sure > > yet, if we can have a local test case for this purpose. > > Henrik I think that would be possible if the stop button would allow us to > stop a script from executing as follows: script will have 1 sec timeout to > load some content, after main content is loaded. So pressing stop will not > load second content. Remus, please file a bug to investigate if that's possible. If not, we can always resolve it WONTFIX. Marking this VERIFIED FIXED due to lack of failures since March 31.
Status: RESOLVED → VERIFIED
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
•