Commit r28068 to fix #15974 caused a change in the return value of hasAlpha() for GIF animation frames. Frames that have transparency used to return true but now return false. Looks like "replace" frames return true as expected but "combine" frames always return false now where one would expect true, which should probably remain an implementation detail internal to the GIF decoder rather than affecting hasAlpha(). Test case attached.
Created attachment 17572 [details] Test case Before the changes were made: frame 1 hasAlpha: 1 frame 2 hasAlpha: 1 frame 3 hasAlpha: 1 frame 4 hasAlpha: 1 frame 5 hasAlpha: 1 frame 6 hasAlpha: 1 frame 7 hasAlpha: 1 frame 8 hasAlpha: 1 frame 9 hasAlpha: 1 frame 10 hasAlpha: 1 frame 11 hasAlpha: 1 frame 12 hasAlpha: 1 After the changes: frame 1 hasAlpha: 1 frame 2 hasAlpha: 0 frame 3 hasAlpha: 0 frame 4 hasAlpha: 0 frame 5 hasAlpha: 0 frame 6 hasAlpha: 1 frame 7 hasAlpha: 0 frame 8 hasAlpha: 0 frame 9 hasAlpha: 0 frame 10 hasAlpha: 0 frame 11 hasAlpha: 0 frame 12 hasAlpha: 0 Frames 1 and 6 are replace/background frames -- the rest are combine frames.
The workaround committed in r28109 should be removed when this issue is resolved.
Created attachment 17577 [details] patch v1 Attempted fix (untested). This was just oversight -- I meant to copy the alpha state from the previous buffer at the same time I copied its bits. The FIXME in ImageSourceCairo is based on IRC discussion with alp.
Comment on attachment 17577 [details] patch v1 r=me
Landed in r28114.