Closed
Bug 987565
Opened 10 years ago
Closed 10 years ago
Test failure "controller.waitForPageLoad" in testBookmarks_OpenAndClose/test1.js and testBookmarks_OpenAllInTabs/test1.js
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect, P1)
Tracking
(firefox35 fixed, firefox36 fixed)
RESOLVED
FIXED
People
(Reporter: danisielm, Assigned: AndreeaMatei)
References
()
Details
(Whiteboard: [mozmill-test-failure][sprint])
Attachments
(2 files, 1 obsolete file)
1.31 KB,
patch
|
andrei
:
review+
andrei
:
checkin+
|
Details | Diff | Splinter Review |
2.88 KB,
patch
|
andrei
:
review+
andrei
:
checkin+
|
Details | Diff | Splinter Review |
This happened on Mac OSX 10.7 (mm-osx-107-2). Log says it failed loading about:newtab and the readyState it's marked as complete. 17:19:14 TEST-START | testBookmarks_OpenAndClose/test1.js | setupModule 17:19:17 TEST-START | testBookmarks_OpenAndClose/test1.js | testOpenAndCloseAllBookmarks 17:21:24 ERROR | Test Failure | { 17:21:24 "exception": { 17:21:24 "message": "controller.waitForPageLoad(URI=about:newtab, readyState=complete)", 17:21:24 "lineNumber": 27, 17:21:24 "name": "AssertionError", 17:21:24 "fileName": "resource://mozmill/modules/errors.js" 17:21:24 } 17:21:24 } 17:21:24 TEST-UNEXPECTED-FAIL | testBookmarks_OpenAndClose/test1.js | testOpenAndCloseAllBookmarks 17:21:24 TEST-START | testBookmarks_OpenAndClose/test1.js | teardownModule
Reporter | ||
Updated•10 years ago
|
OS: Linux → Mac OS X
Hardware: x86_64 → All
Comment 1•10 years ago
|
||
So what are we going to load in that line? Also I miss the link to the dashboard failure list for this kind of failure. Which branches are affected?
Updated•10 years ago
|
Whiteboard: [mozmill-test-failure]
Reporter | ||
Updated•10 years ago
|
Comment 2•10 years ago
|
||
Daniel please check all the open waitForPageLoad() bugs for the about:newtab failure. There should be a single bug only for that issue.
Reporter | ||
Comment 3•10 years ago
|
||
We have a more general waitForPageLoad() bug where we tracked all this types of failures and other test specific bugs with no information about the page that failed. Now that we have more information about each call, we can group this failures by the page that failed loading, like about:newtab or about:blank, or a remote page. I suggest we name this bug 'Test failure "controller.waitForPageLoad()" waiting for 'about:newtab' page'. Henrik, would that be a good way of tracking this failures in the future ?
Flags: needinfo?(hskupin)
Comment 4•10 years ago
|
||
We might only want to differentiate between remote pages, local pages, and self-served (about:) pages. So lets create check all existing bugs for about: and mark those as dupe of the bug first created for it.
Flags: needinfo?(hskupin)
Assignee | ||
Comment 5•10 years ago
|
||
I reproduced this last week while testing 2.0.7, we should check continue on it this week. http://mozmill-daily.blargon7.com/#/endurance/reports
Assignee | ||
Comment 6•10 years ago
|
||
Fails on production too every time with Nightly only, raising priority, adding a skip patch in a moment.
Assignee: nobody → andreea.matei
Status: NEW → ASSIGNED
status-firefox30:
affected → ---
status-firefox35:
--- → affected
Priority: -- → P1
Assignee | ||
Comment 7•10 years ago
|
||
Adding skip patch. I will update the summary here as this bug was initially created for testBookmarks_OpenAndClose with the same failure. testBookmarks_OpenAllInTabs started to fail on September 11th, will investigate further.
Attachment #8489320 -
Flags: review?(andrei.eftimie)
Assignee | ||
Updated•10 years ago
|
OS: Mac OS X → All
Summary: Test failure "controller.waitForPageLoad" in testBookmarks_OpenAndClose/test1.js → Test failure "controller.waitForPageLoad" in testBookmarks_OpenAndClose/test1.js and testBookmarks_OpenAllInTabs/test1.js
Comment 8•10 years ago
|
||
Comment on attachment 8489320 [details] [diff] [review] skip.patch Review of attachment 8489320 [details] [diff] [review]: ----------------------------------------------------------------- Interestingly I can't reproduce this at all on my machine. This does fail at all on CI. Disabled: https://hg.mozilla.org/qa/mozmill-tests/rev/d947a65ee957 (default)
Attachment #8489320 -
Flags: review?(andrei.eftimie)
Attachment #8489320 -
Flags: review+
Attachment #8489320 -
Flags: checkin+
Updated•10 years ago
|
Assignee | ||
Comment 9•10 years ago
|
||
The issue here is that we have the new settings button on the right side, regarding tiles options when we open a new tab. The fix needs this notification to be turned off, by setting browser.newtabpage.introShown pref to true. I'll file a bug for it. I tested it by setting the pref in the test itself.
Comment 10•10 years ago
|
||
I'm not sure a new bug is warranted. We should disable it here at the same time as we unskip the test. ATM if we want it globally we need to insert it into mozprofile, and that's a bit over-the-top. I've seen that notification locally lately, but it hasn't impacted any of the testruns I've run.
Assignee | ||
Comment 11•10 years ago
|
||
Sounds good to me, I was thinking to add it to mozprofile. But we do have only one test affected.. maybe add it in the tabs lib instead of the test, since that appears the first time you open about:newtab.
Comment 12•10 years ago
|
||
We should stop adding preferences to mozprofile. Especially those which only affect us in Mozmill, but not users of mozrunner. We can only add those to mozmill as I have lately done for e10s.
Assignee | ||
Comment 13•10 years ago
|
||
Enabling test and setting the pref in closeAllTabs(). This is affecting only nightly. http://mozmill-crowd.blargon7.com/#/endurance/report/f11964362bbc85ebfbc5b36de767ba8a Ran also functional and remote on OSX to make sure we don't affect other tests.
Attachment #8495189 -
Flags: review?(andrei.eftimie)
Comment 14•10 years ago
|
||
Comment on attachment 8495189 [details] [diff] [review] patch v1 Review of attachment 8495189 [details] [diff] [review]: ----------------------------------------------------------------- ::: firefox/lib/tabs.js @@ +56,5 @@ > * MozMillController of the window to operate on > */ > function closeAllTabs(aController) > { > + prefs.preferences.setPref(PREF_NEWTAB_INTRO, true); Please add this in the tabBrowser constructor so it will always apply. File a bug against mozmill to get this pref directly in as Henrik pointed out (see bug 1065436 attachment 8487894 [details] [diff] [review]), and add a comment referencing that bug as usual when we add a workaround so we know when to safely remove it.
Attachment #8495189 -
Flags: review?(andrei.eftimie) → review-
Assignee | ||
Comment 15•10 years ago
|
||
Updated as requested.
Attachment #8495189 -
Attachment is obsolete: true
Attachment #8498875 -
Flags: review?(andrei.eftimie)
Comment 16•10 years ago
|
||
Comment on attachment 8498875 [details] [diff] [review] patch v2 Review of attachment 8498875 [details] [diff] [review]: ----------------------------------------------------------------- Changed the commit message slightly. Landed: https://hg.mozilla.org/qa/mozmill-tests/rev/728f48e975df (default)
Attachment #8498875 -
Flags: review?(andrei.eftimie)
Attachment #8498875 -
Flags: review+
Attachment #8498875 -
Flags: checkin+
Updated•10 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•10 years ago
|
Whiteboard: [mozmill-test-failure] → [mozmill-test-failure][sprint]
Assignee | ||
Comment 17•10 years ago
|
||
This is still failing for testBookmarks_OpenAllInTabs/test1.js, not sure why the pref isn't working as it should. I think it did for a while, then started to fail again. Will have to look further.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 18•10 years ago
|
||
(In reply to Andreea Matei [:AndreeaMatei] from comment #17) > This is still failing for testBookmarks_OpenAllInTabs/test1.js, not sure > why the pref isn't working as it should. I think it did for a while, then > started to fail again. Will have to look further. I don't see the Intro panel, so the preference is indeed working fine. What I do see is the e10s notification panel (test manages to pass for me locally, but I did experience failures because of it in other places recently). If it is indeed the issue, it will get fixed by mozmill 2.0.9
Depends on: 1082077
Comment 19•10 years ago
|
||
This should have been a new bug since it's a different issue. The original issue has been fixed on 2014-10-03 and we had no failures new failures in 2 weeks. Lets leave it for now. The new issue has a high failure rate, so we should disable the test again. Linux and WindowsXP don't seem to be affected. OSX and all other Win versions are failing at close to 100% rate. I've relanded the initial skip patch: https://hg.mozilla.org/qa/mozmill-tests/rev/e1af80200231 (default)
status-firefox36:
--- → disabled
Assignee | ||
Updated•10 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 20•10 years ago
|
||
This was failing due to the e10s popup, I tested with 2.0.9 env and it's passing now. So we'll wait for that in production before re-enabling this test.
Comment 21•10 years ago
|
||
With mozmill 2.0.9 all is green. We have again all endurance tests running! > RESULTS | Passed: 19 > RESULTS | Failed: 0 > RESULTS | Skipped: 0 Backed out skip: https://hg.mozilla.org/qa/mozmill-tests/rev/492178336ac8 (default)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 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
•