Same as bug 557456, except it's permanent. http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1270934406.1270936064.1695.gz WINNT 5.2 comm-central-trunk debug test mochitests-5/5 on 2010/04/10 14:20:06 { 211 INFO Running /tests/modules/plugin/test/test_painting.html... ++DOMWINDOW == 20 (0D351B48) [serial = 43] [outer = 0B1CB958] For application/x-test found plugin nptest.dll For application/x-test found plugin nptest.dll NPP_Destroy 212 INFO TEST-PASS | /tests/modules/plugin/test/test_painting.html | zero-sized plugin not painted --DOMWINDOW == 19 (0D9F9030) [serial = 37] [outer = 0B1CB958] [url = http://mochi.test:8888/tests/modules/plugin/test/test_npn_asynccall.html] --DOMWINDOW == 18 (0DC043F0) [serial = 38] [outer = 0B1CB958] [url = http://mochi.test:8888/tests/modules/plugin/test/test_npn_timers.html] --DOMWINDOW == 17 (0B4B7530) [serial = 40] [outer = 0B1CB958] [url = http://mochi.test:8888/tests/modules/plugin/test/test_npruntime_npnevaluate.html] --DOMWINDOW == 16 (0CFA2868) [serial = 39] [outer = 0B1CB958] [url = http://mochi.test:8888/tests/modules/plugin/test/test_npobject_getters.html] --DOMWINDOW == 15 (0B9C8748) [serial = 41] [outer = 0B1CB958] [url = http://mochi.test:8888/tests/modules/plugin/test/test_npruntime_npninvoke.html] --DOMWINDOW == 14 (0CF31750) [serial = 42] [outer = 0B1CB958] [url = http://mochi.test:8888/tests/modules/plugin/test/test_npruntime_npninvokedefault.html] NEXT ERROR 213 ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_painting.html | Test timed out. }

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a5pre) Gecko/20100410 SeaMonkey/2.1a1pre] (comm-central-trunk-win32/1270896177) I don't reproduce locally with Optimized build.

1) Trying with a debug build from the packages our builds deleiver might be interesting 2) I see you are using Win2k, the test machines are on Win2k3, that might possibly give a difference 3) What screen size are you using? I wonder if the VMs are set to a smaller screen size and if that might make a difference on some tests.

Likely the same (as yet unknown) cause as for bug 558604.

(In reply to comment #2) > 1) Trying with a debug build from the packages our builds deliver might be > interesting Anyone is welcome to do so. I can't atm: see bug 556686 comment 3. > 2) I see you are using Win2k, the test machines are on Win2k3, that might > possibly give a difference It might, yet Firefox passes on Win2k3... > 3) What screen size are you using? I wonder if the VMs are set to a smaller > screen size and if that might make a difference on some tests. 1152*864px, yet I think the comparison should be with the Firefox boxes...

(In reply to comment #4) > (In reply to comment #2) > > 3) What screen size are you using? I wonder if the VMs are set to a smaller > > screen size and if that might make a difference on some tests. > > 1152*864px, yet I think the comparison should be with the Firefox boxes... I know that Firefox is running with a larger resolution than we are on Windows, as anything larger than 1024x768 makes remote administration much harder for me and I'd like to avoid that if possible as long as there are still regular tasks I need to perform that way (e.g. clobbering). Could you try and see if tests like this one paint something that *might* go out of screen on 1024x768? In case this is true and we need to bump it up to succeed, I'll probably have to bite the bullet but will refrain from any remote admin requests even more than now.

(In reply to comment #5) > Could you try and see if tests like this one paint something that *might* go > out of screen on 1024x768? I tried this test and bug 558604 test (individually) at "800*600px with 16-bit colors" and they passed.

(In reply to comment #6) > I tried this test and bug 558604 test (individually) at "800*600px with 16-bit > colors" and they passed. Thanks, so we can exclude one reason, that's good. Still, we're not nearer to what is the actual problem, which makes me unhappy. :(

Not blocking the release on this until it becomes clear this hurts regular users.

Looks to me like bug 571855 has fixed this. If that holds true, I'll dupe this to it.

OK, this has succeeded multiple times now, so let's call it a success, bug 571855 was the actual bug behind this.