727700 - Suppress image invalidations once the decoder hits a data error

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Robert Lickenbrock [:rclick]]

We don't flush image invalidations from RasterImage if there's a data error (see Bug 726004). This check should happen in the decoder superclass to ensure that we don't flush from Decoder::PostFrameStop() either.

This could possibly fix the random orange in Bug 721917.

Comment 1

[Robert Lickenbrock [:rclick]]

Attachment: patch

This should do it.

I haven't tested this at all yet as I'm waiting for my build to finish. Building takes forever on my box, so I probably won't come back to this until tomorrow.

Comment 2

[Justin Lebar (not reading bugmail)]

Robert, do you have level-one commit access?  I can help you get that so you can push to try.

http://www.mozilla.org/hacking/commit-access-policy/

Comment 3

[Justin Lebar (not reading bugmail)]

Robert, what's the status with getting L1 access, etc?  I'd love to get this fix in before we branch.

Let me know if and how I can help.

Comment 4

[Robert Lickenbrock [:rclick]]

Sorry for the delay here. My L1 access is bug 728406. That's waiting for server-ops to do their part.

I've been looking at the BMP decoder and I'm starting to suspect that invalidation isn't the problem. Specifically, the FlushInvalidations() call only does something if the decoder first calls PostInvalidation() to post a region to invalidate. As I'm reading it, the BMP decoder should be bailing with a data error before that happens...

I'll investigate further with a debugger and see if I can figure out what's going on.

Comment 5

[Robert Lickenbrock [:rclick]]

I can reproduce the test failures on my WinXP box (albeit not reliably).I've confirmed that we're not actually invalidating anything so the patch here won't make any difference. WONTFIX'ing based on that.

I have noticed that on the failing runs we're firing onload instead of onerror. I filed Bug 734681 to fix that.