Closed Bug 820738 Opened 13 years ago Closed 11 years ago

Intermittent browser_newtab_block.js | grid status = 0,1,2,3,6,7,8,9, - Got 0,1,2,3,6,7,8,9,http://mochi.test:8888/browser/browser/base/content/test/test_wyciwyg_copying.html, expected 0,1,2,3,6,7,8,9, (and another)

Categories

(Firefox :: Tabbed Browser, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Firefox 24

People

(Reporter: emorley, Unassigned)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

Rev3 WINNT 6.1 mozilla-inbound pgo test mochitest-browser-chrome on 2012-12-10 00:25:10 PST for push 0770315e3538 slave: talos-r3-w7-098 https://tbpl.mozilla.org/php/getParsedLog.php?id=17771989&tree=Mozilla-Inbound { TEST-START | chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js | grid status = 0,1,2,3,4,5,6,7,8 TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js | grid status = 0,1,2,3,5,6,7,8,9 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js | grid status = 0,1,2,3,6,7,8,9, - Got 0,1,2,3,6,7,8,9,http://mochi.test:8888/browser/browser/base/content/test/test_wyciwyg_copying.html, expected 0,1,2,3,6,7,8,9, Stack trace: JS frame :: chrome://mochikit/content/browser-test.js :: test_is :: line 474 JS frame :: chrome://mochitests/content/browser/browser/base/content/test/newtab/head.js :: checkGrid :: line 261 JS frame :: chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js :: runTests :: line 22 JS frame :: chrome://mochitests/content/browser/browser/base/content/test/newtab/head.js :: TestRunner.next :: line 54 JS frame :: chrome://mochikit/content/browser-test.js :: test_executeSoon/<.run :: line 503 native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js | grid status = 0,1,2,3,7,8,9,, - Got 0,1,2,3,7,8,9,http://mochi.test:8888/browser/browser/base/content/test/test_wyciwyg_copying.html,http://example.org/, expected 0,1,2,3,7,8,9,, Stack trace: JS frame :: chrome://mochikit/content/browser-test.js :: test_is :: line 474 JS frame :: chrome://mochitests/content/browser/browser/base/content/test/newtab/head.js :: checkGrid :: line 261 JS frame :: chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js :: runTests :: line 25 JS frame :: chrome://mochitests/content/browser/browser/base/content/test/newtab/head.js :: TestRunner.next :: line 54 JS frame :: chrome://mochikit/content/browser-test.js :: test_executeSoon/<.run :: line 503 native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 }
Blocks: 870453
There are some pages in the list of links shown on the new tab page that shouldn't be there because we cleared the history before running tests. I figured there might be some race condition or timing issue and we should actually wait until pages are expired.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Attachment #748885 - Flags: review?(mak77)
Hi gavin, We're trying to reduce the # of Windows 7 on iX intermittent oranges and a test that was committed by you is giving us trouble. Would you please be able to give us a hand? http://hg.mozilla.org/mozilla-central/annotate/6066b9d92032/browser/base/content/test/test_wyciwyg_copying.html
Attachment #748885 - Flags: review?(mak77) → review+
test_wyciwyg_copying.html is just a file loaded by a previous test, that is interfering with the test that's actually failing (browser_newtab_block.js, because it doesn't clear history). The failing test lists URLs from history, which is why that file is referenced in the log. So I have nothing to do with this :) In any case it looks like the patch is ready to land anyways.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ok, another theory is that setLinks might interfere with a running populateCache() call. populateCache() takes a callback and if there are other callbacks already in the queue we just push the new callback and return. So I think what might happen here is that there is a populateCache() call still in progress while we're clearing and filling the history. If we then call populateCache() again we'll just be enqueued and get stale entries. This can be solved by calling populateCache(force=false) once before starting to clear/fill the history.
Attachment #755329 - Flags: review?(jaws)
Comment on attachment 755329 [details] [diff] [review] call populateCache() before overwriting history with test data to make sure we're not enqueued with an in-progress populateCache() call Review of attachment 755329 [details] [diff] [review]: ----------------------------------------------------------------- I'll send this over to Marco since he reviewed the first patch for this bug.
Attachment #755329 - Flags: review?(jaws) → review?(mak77)
Comment on attachment 755329 [details] [diff] [review] call populateCache() before overwriting history with test data to make sure we're not enqueued with an in-progress populateCache() call Review of attachment 755329 [details] [diff] [review]: ----------------------------------------------------------------- I see what you mean, still this is very foggy. On the other side, I suppose probability to happen in real life is very very low.
Attachment #755329 - Flags: review?(mak77) → review+
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: ttaubert → nobody
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: