http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1289689295.1289690527.3255.gz Rev3 Fedora 12x64 mozilla-central opt test mochitests-4/5 on 2010/11/13 15:01:35 96352 INFO TEST-START | /tests/modules/plugin/test/test_painting.html NPP_Destroy 96353 INFO TEST-PASS | /tests/modules/plugin/test/test_painting.html | zero-sized plugin not painted - 0 should equal 0 96354 INFO TEST-PASS | /tests/modules/plugin/test/test_painting.html | fully clipped plugin not painted - 0 should equal 0 96355 INFO TEST-PASS | /tests/modules/plugin/test/test_painting.html | partially clipped plugin painted once - 1 should equal 1 96356 ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_painting.html | Test timed out. args: ['/home/cltbld/talos-slave/mozilla-central_fedora64_test-mochitests-4/build/bin/screentopng'] XScreenSaver state: Disabled

Bug 612040 may be related as test_pluginstream_asfile.html also timed out in the test run above.

In comment 2, failure was after "fully clipped plugin not painted". The "partially clipped plugin painted once" test had not been reached.

At the "fully clipped plugin painted once" test, the paint_waiter plugin has already been shown with height:1px and had it's height changed back to 0px. This happens again before the "partially clipped plugin painted once" test. Then the script should wait for reflow, change the height back to 1px, and wait for a paint. Apparently the paint is not happening. It might be worth checking whether the plugin is reliably notified of its change to an empty rectangle and whether this invalidates its surface.

Screenshots from both comment 0 and comment 2 show the expected state, with the correct color for embed#clipped, and embed#paint_waiter is visible (shown on screen).

Tentatively guessing this is related to plugin changes on 2010-11-10, because I don't see any other plugin changes before 2010-11-13.

As far as I can tell, this test is really not all that valuable with async painting, where clipping happens as part of the layer rendering and not as part of painting. Can we perhaps just remove this test? If the *size* of the plugin changes to 0 and then to 1, we should be invalidating the surfaces and repaint, here: http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginInstanceChild.cpp#2170 The patch for bug 611206 may fix this by resetting the size when visibility changes, not just the cliprect.

(In reply to comment #7) > Can we perhaps just remove this test? AFAIK, the test is indicating that something is not behaving as expected, so the test seems to be serving a purpose.

Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that: * Haven't changed in > 6months * Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb} * Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive. I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases). Sorry for the spam! Filter on: #FFA500