555519 - xpcshell: test_doSetAndLoadFaviconForPage_failures.js randomly succeeds

Status: RESOLVED FIXED

(Toolkit :: Places, defect)

Description

[Serge Gautherie (:sgautherie)]

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1269726905.1269729299.29491.gz&fulltext=1
Linux comm-central-trunk debug test xpcshell on 2010/03/27 14:55:05
{
TEST-UNEXPECTED-FAIL | .../xpcshell/tests/test_places/unit/test_doSetAndLoadFaviconForPage_failures.js | test failed (with xpcshell return code: 0), see following log:
[...]
TEST-UNEXPECTED-FAIL | .../test_doSetAndLoadFaviconForPage_failures.js | false == true - See following stack:
JS frame :: .../xpcshell/head.js :: do_throw :: line 257
JS frame :: .../xpcshell/head.js :: do_check_eq :: line 287
JS frame :: .../xpcshell/head.js :: do_check_true :: line 299
JS frame :: .../test_doSetAndLoadFaviconForPage_failures.js :: historyObserver_onPageChanged :: line 154
[...]
TEST-UNEXPECTED-FAIL | .../test_doSetAndLoadFaviconForPage_failures.js | file:///builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/xpcshell/tests/test_places/unit/favicon-normal16.png == file:///builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/xpcshell/tests/test_places/unit/favicon-normal32.png - See following stack:
JS frame :: .../xpcshell/head.js :: do_throw :: line 257
JS frame :: .../xpcshell/head.js :: do_check_eq :: line 287
JS frame :: .../test_doSetAndLoadFaviconForPage_failures.js :: historyObserver_onPageChanged :: line 163
}

All the changes of that bug seem to be in /toolkit.
Might this test (not) rely on the usual preference differences between FF and SM?

Comment 1

[Robert Kaiser]

I can produce locally, and I also can figure out that it's test2 - "test setAndLoadFaviconForPage with history disabled" - which fails.

Marco, do you have any clue why this could happen on SeaMonkey only?

Comment 2

[Robert Kaiser]

Ah, one more thing that I could find out: For some reason the historyObserver triggers an onPageChanged for that test2, and that's where we're failing.

Comment 3

[Marco Bonardo [:mak]]

hm, yes in your case the page is added to history, indeed in the log it appears in moz_places_temp. i'd not expect this to be possible at all with places.history.enabled set to false :(
So far i can't think of a reason, there must be though.

Comment 4

[Robert Kaiser]

When I bump the timeout in http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/tests/unit/test_doSetAndLoadFaviconForPage_failures.js#207 to 5000, the test passes locally.

Comment 5

[Marco Bonardo [:mak]]

the problem is that comm-central is correct and due to some difference in timing mozilla-central passes the test.
This test should be disabled for now till we get rid of LAZY_ADD.

Comment 6

[Marco Bonardo [:mak]]

so, this is not a Seamonkey bug, but a real bug, i can't fix the test cause it would take 12s to run.
I'll disable it.

Comment 7

[Marco Bonardo [:mak]]

i'll disable on my next push.

Comment 8

[Justin Wood (:Callek)]

Marco just to be clear and out of curiosity; is it a test bug, or a bug in backend code?

Just to know how we view this here.

Comment 9

[Marco Bonardo [:mak]]

it's a test bug.

Comment 10

[Marco Bonardo [:mak]]

disabled
http://hg.mozilla.org/mozilla-central/rev/5764a8b05e4b

Comment 11

[Marco Bonardo [:mak]]

this is currently fixed and the test has been re-enabled with other async fixes.