605568 - Animated GIF with transparency over loading iframe flashes opaque background as iframe loads

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Larry Davis]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

When an animated GIF with transparency is positioned absolutely above an iframe, and one changes the src of the iframe, transparency will be there until the moment before the iframe refreshes its content, at which point the normally transparent area in the GIF will flash white (or other background color) for under a second.

In this case, YUI is being used to display a modal overlay with an animated "loading" spinner to show a process is in progress. Removing the GIF from the overlay causes the problem to go away.

Reproducible: Always

Steps to Reproduce:
1. Create a HTML document with an iframe and an absolutely positioned div with an animated gif and write some javascript to change the iframe source onclick (or any event).

2. Click the document body
Actual Results:  
Transparency will be there until the moment before the iframe refreshes its content, at which point the normally transparent area in the GIF will flash white (or other background color) for under a second.

Expected Results:  
Smooth transition between pages despite presence of animated GIF.

Comment 1

[Larry Davis]

Attachment: A test case the switches an iframe from bing.com to apple.com with a spinner overlayed.

Comment 2

[Larry Davis]

I suppose I should note this only seems to affect certain websites, as switching from blackle.com to bing.com doesn't cause the problem :-\ (test case is bing.com -> apple.com)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is this a problem on trunk?

Comment 4

[Larry Davis]

Attachment: A test case the switches an iframe from blackle.com to bing.com with a spinner overlayed, DOES NOT CAUSE PROBLEM DESCRIBED

I figured it might be nice to have an example of a similar situation in which the bug is not experienced. I wonder why...

Comment 5

[Larry Davis]

@Boris: Our QA team at Adobe caught this in FF 3.6.10 and I checked it out and determined it was a FF specific behavior, but didn't put much time into testing. If I have time later I will test with trunk, but the attached test cases should give you quick insight.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Larry, in 3.6.10 subframes have native widgets.  On trunk they don't.

For what it's worth, your first testcase shows the problem for me in 1.9.2 builds, but not on trunk.

Comment 7

[Larry Davis]

Great, Thanks Boris!

Comment 8

[Tim (fmdeveloper)]

Larry -> Has this issue been resolved in Firefox > 4?

Comment 9

[Larry Davis]

Yes, the problem is gone, tested in Firefox 5.0.1. Thanks!