Expectation timeout on mac: http://trac.webkit.org/changeset/125191

I've replaced this test with fast/images/jpeg-partial-load.html http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&showAllRuns=true&tests=http%2Ftests%2Fimages%2Fjpg-img-partial-load.html%20%20http%2Ftests%2Fimages%2Fjpeg-partial-load.html%20%20

Created attachment 171810 [details] Patch

What was the reason that jpg-img-partial-load.html fails on Lion? Was that because of a difference jpeg image and stall offset?

I don't know why your test timed-out on LIon. I do know that your test also fails with a timed-out on Snow Leopard and Mountain Lion, so it's not just Lion. > Was that because of a difference jpeg image and stall offset? Nope. The test times-out regardless of image and regardless of stall offset. RenderImage::paintIntoRect() is never called.

This test and the one I wrote are using the same technique but the stopping conditions are different. Your test is using a timeout of 500m while mine is using availability of width and height as a signal. It is best to avoid using timeout as it depends and the running time (debug vs release vs speed), have you explored other options?

It's good that we remove this test by the way as it times out on Mac anyway I think it's because of the difference in platform decoder that requires more bytes to decode header. I just want to know how we can avoid using timeout for test.

(In reply to comment #7) > It's good that we remove this test by the way as it times out on Mac That's the point of this bug, so let's remove it. > Anyway I think it's because of the difference in platform decoder that requires more bytes to decode header. Maybe, maybe not. You could test your theory to find out. > I just want to know how we can avoid using timeout for test. Not sure you can avoid it for partial load tests. I also choose timeout values to account for debug builds on all ports. The values seem to work: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&showAllRuns=true&tests=http%2Ftests%2Fimages

Ping?

Comment on attachment 171810 [details] Patch Clearing flags on attachment: 171810 Committed r133695: <http://trac.webkit.org/changeset/133695>

All reviewed patches have been landed. Closing bug.

I feel sorry for removing this awesome test. It is because the following reason. Currently, we can not pause a git animation image at the specific frame by javascript. I think this approach makes us check whether the specific frame of the gif animation image is rendered or not. However, we can not use this approach in mac so we can not use this approach for gif animations too.

(In reply to comment #12). > Currently, we can not pause a git animation image at the specific frame by javascript. I think this approach makes us check whether the specific frame of the gif animation image is rendered or not. However, we can not use this approach in mac so we can not use this approach for gif animations too. This bug is about JPEG images. I'm not sure why you are talking about GIF images.

(In reply to comment #13) > (In reply to comment #12). > > Currently, we can not pause a git animation image at the specific frame by javascript. I think this approach makes us check whether the specific frame of the gif animation image is rendered or not. However, we can not use this approach in mac so we can not use this approach for gif animations too. > > This bug is about JPEG images. I'm not sure why you are talking about GIF images. I skipped the detailed explanation. I'm sorry. This test intentionally pauses loading an image. When the image is a gif animation image, the default imageDecoder decodes the image until the last frame of the data received. If we use this technique properly, we can pause a git animation image at the specific frame. I had a plan to make some tests for gif animations using this technique. However, I knew this technique has a problem from this bug and this situation made me feel sorry.