Closed Bug 723484 Opened 12 years ago Closed 12 years ago

Graphic crossfade doesn't work anymore

Categories

(Core :: Graphics, defect)

10 Branch
x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla14
Tracking Status
firefox11 --- wontfix
firefox12 + verified
firefox13 + verified
firefox-esr10 --- wontfix

People

(Reporter: hh_mr.cheat, Assigned: roc)

References

()

Details

(Keywords: regression, testcase, Whiteboard: [qa+][qa!:12][qa!:13])

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

I visited the website http://www.zahnarztpraxis-stoll.de/


Actual results:

The graphic (the middle one) crossfades very ugly to the next one. There shouldn't be a black screen while it's fading.


Expected results:

The graphic should smooth and soft fade to the next graphic, like in the movies. It worked fine in the previous Firefox versions 3-9 but now it doesn't. I used this effect for a lot of customer webpages. If my customers upgrading to Firefox 10 they are going crazy.
Severity: normal → critical
WFM:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.26) Gecko/20120128 Firefox/3.6.26
Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (X11; Linux x86_64; rv:11.0a2) Gecko/20120131 Firefox/11.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120202 Firefox/13.0a1
Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.10.229 Version/11.61
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Does the issue still occur if you start Firefox in Safe Mode?
https://support.mozilla.com/en-US/kb/Safe+Mode

How about with a new, empty profile?
https://support.mozilla.com/en-US/kb/Basic+Troubleshooting#w_8-make-a-new-profile
wfm with Seamonkey trunk and Firefox10.0 on windows7/32. 
I have tested with and without hwa.
In safe mode it works fine. Can't create a new profile, it doesn't work. Mozilla firefox starts without the profile wizard. I tried everything. I really think this is a firefox 10 problem. I just checked it before and after the upgrade. I changed nothing, but firefox did.
Please disable the hardware acceleration under (alt key)/tools/options/advanced/general/ , restart FF in the normal mode and test again.
OK, it's a problem with the hardware acceleration. After disabling the acceleration the graphic crossfade works fine. So it's a bug with the hardware acceleration. Or wasn't there any before FF10?
Please copy+paste the graphic section from about:support in this bug.
This seems to be a possible driver bug because it works on my system with hardware acceleration enabled. (nvidia 310m)

BTW: The site seems to have serious problems with the IPv6 setup.
Now show me how good your german is ;)
--------------------------------------------------
Grafik 
      
Karten-Beschreibung: NVIDIA GeForce 7600 GT
Vendor-ID: 10de
Geräte-ID: 02e0
Karten-RAM: 256
Karten-Treiber: nvd3dum
Treiber-Version: 8.17.12.6099
Treiber-Datum: 10-16-2010
Karten-RAM (GPU #2): Unknown
Karten-Treiber (GPU #2): Unknown
Direct2D aktiviert: false
DirectWrite aktiviert: false (6.1.7601.17563)
ClearType-ParameterClearType-Parameter: nicht gefunden
WebGL-Renderer: Google Inc. -- ANGLE (NVIDIA GeForce 7600 GT) -- OpenGL ES 2.0 (ANGLE 0.0.0.809)
GPU-beschleunigte Fenster: 0/1
--------------------------------------------------

I'm going to update my gfx driver and report after that. When I have some more time left, I'm going to plug out my gfx card and try to use the onboard one.

Thanks for the IPv6 issue tip. I reported it to my webhoster.
Oh ok, you are german :)
Component: Untriaged → Graphics
Product: Firefox → Core
QA Contact: untriaged → thebes
?
This also WFM on Mac OS X; maybe this is a Windows-only bug.
bug 723524 contains more URLs and a better description:

>I set up a page with an image element in it. Through css I specified that the image should fade to opacity 0.2 on hover: img:hover {opacity: 0.2;}
>
>Actual results:
>
>When hovering the mouse over the image, the image fades to black, and switches to 0.2 Tranparency after a short moment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have this problem with graphics acceleration.
It seems to work fine for me with acceleration enabled on my laptop. I'm using an nVidia 555m.

I can try my desktop tomorrow (it uses an ATI card).
I updated my nvidia gfx driver from 260.x to 285.62 (latest). Nothing changed, still got the same problems.
Isn't this a DUPE of bug 656948?
I don't know if this is a dupe. Did this regress with Firefox 10?
The problem emerged with FF10, previously it was fine. We saw the problem with a JQuery fade plugin (http://jquery.malsup.com/cycle/basic.html). On our site http://www.ers-international.com/ it faded to black rather then just fade. On the plugin site it worked fine. Turns out that you now (FF10) need to add a background-color or border-color CSS to the image tag, to avoid this problem. You cannot add "transparent". In previous versions of FF and all other browsers this property did not need to be added.

Hardware acceleration off does work. Could be a good hint where the "bug" was introduced?
A regression range could help.
You can either download and try the nightly builds or use a tool like https://github.com/mozilla/mozregression
if you use a css rule:
background-color:#fff;
it works!

without graphic acceleration the fade is ok!
Nope, doesn't work for me. Even when it works, I can't change all my customers webpages, because of a bug with the webbrowser. No, there must be something wrong. Because all other FF Version worked fine, even FF 3.0.19.
Severity: critical → normal
I can't reproduce this with a MBP on Windows. NVIDIA GeForce GT 330M. Acceleration is on:
GPU Accelerated Windows1/1 Direct3D 10
After Firefox 10.1 update, I still got the problem.
(In reply to Mirko from comment #25)
> After Firefox 10.1 update, I still got the problem.
It's normal because this bug is not fixed.
Same issue here on Windows 7 32-bit with hwa. This bug appeared in firefox 10. My card:

        Adapter Description
        NVIDIA GeForce 7300 GT

        Vendor ID
        10de

        Device ID
        0393

        Adapter RAM
        256

        Adapter Drivers
        nvd3dum

        Driver Version
        8.17.12.8562

        Driver Date
        10-15-2011

        Adapter Description (GPU #2)
        NVIDIA GeForce 6100 nForce 405

        Vendor ID (GPU #2)
        10de

        Device ID (GPU #2)
        03d1

        Adapter RAM (GPU #2)
        64

        Adapter Drivers (GPU #2)
        nvd3dum

        Driver Version (GPU #2)
        8.17.12.8562

        Driver Date (GPU #2)
        10-15-2011

        Direct2D Enabled
        false

        DirectWrite Enabled
        false (6.1.7601.17563)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (NVIDIA GeForce 7300 GT) -- OpenGL ES 2.0 (ANGLE 0.0.0.809)

        GPU Accelerated Windows
        0/1
On Windows 7 & Firefox 10, I'm only able to reproduce this with explicitly setting

gfx.direct2d.disabled;true

i.e., only D3D10 Layers Acceleration + GDI kept active.

The testcase in Bug 656948 is reproducible also with D2D Acceleration active.

Does anyone on Windows Vista/7 with "Direct2D Enabled" = "true" in about:support see this Issue at all?

Graphics
Adapter Description        ATI Radeon HD 4800 Series
Vendor ID        0x1002
Device ID        0x9442
Adapter RAM         512
Adapter Drivers        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Driver Version        8.930.0.0
Driver Date        12-5-2011
Direct2D Enabled        true
DirectWrite Enabled        true (6.1.7601.17563)
ClearType Parameters        Gamma: 1800 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 400
WebGL Renderer        Google Inc. -- ANGLE (ATI Radeon HD 4800 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)
GPU Accelerated Windows        1/1 Direct3D 10
AzureBackend        direct2d
It should not be due to toggling hardware acceleration. After doing an update to Firefox/10.0.2 I was able to reproduce it precisely. No further system setting were not changed.

Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Attached file Testcase with problem —
The problem in this testcase seems to be that, if we set a 'float' in CSS, the image will flicker to black. Omitting the float will fix it in this case.
Attachment #599961 - Attachment mime type: text/plain → text/html
Keywords: testcase
@Sasha van den Heetkamp:
Nope, doesn't solve the problem. I tried it. Btw the crossfading div container never contained float.
Mirko, the test-case is a reduced version that has a correlated issue where more than two CSS selectors applied simultaneously will cause the image to be redrawn.It seems that the image is then redrawn before applying the opacity. Since the drawing is almost instant we get a short black flickering. I made another test-case with an image that is bigger in size. That image loads very slow and consequently when we hover, we see that the image gets drawn over a dark background. That's all I can reduce so far. One possible fix might be, is to see if there are any CSS rules that are applied simultaneously, especially on a hover selector. Another solution might be to set the image background to white, although this is untested.
Happens also on Windows XP, ATI Radeon HD 2400 Pro, Driver version: 8.872.0.0
More details from about:support
Adapter Description	ATI Radeon HD 2400 Pro
Vendor ID	1002
Device ID	94c1
Adapter RAM	Unknown
Adapter Drivers	ati2dvag
Driver Version	8.872.0.0
Driver Date	7-7-2011
Vendor ID (GPU #2)	00df
Device ID (GPU #2)	00df
Adapter RAM (GPU #2)	Unknown
Adapter Drivers (GPU #2)	Unknown
Driver Version (GPU #2)	1.1.68.0
Driver Date (GPU #2)	11-25-2005
WebGL Renderer	Google Inc. -- ANGLE (ATI Radeon HD 2400 Pro  ) -- OpenGL ES 2.0 (ANGLE 0.0.0.809)
GPU Accelerated Windows	1/1 Direct3D 9
(In reply to Sasha van den Heetkamp from comment #32)
> Mirko, the test-case is a reduced version that has a correlated issue where
> more than two CSS selectors applied simultaneously will cause the image to
> be redrawn.It seems that the image is then redrawn before applying the
> opacity. Since the drawing is almost instant we get a short black
> flickering. I made another test-case with an image that is bigger in size.
> That image loads very slow and consequently when we hover, we see that the
> image gets drawn over a dark background. That's all I can reduce so far. One
> possible fix might be, is to see if there are any CSS rules that are applied
> simultaneously, especially on a hover selector. Another solution might be to
> set the image background to white, although this is untested.

We've tested on numerous sites/javascript and adding a background-color or border-color CSS to the image tag fixes this behaviour. The issue is what chnaged in FF 10 to cause this to be necessary.
Confirmed. Setting the background color of the image should fix it. Mirko, if you are in need of a quick solution, try adding: img { background-color:#fff; } just below the /** reset styling **/ in your HTML, as temporary global fix for all images. It should work on the site you gave as an example.
@Sasha: Thanks, this works.
Same for me....

Win XP Pro Service pack 3
Intel(R) G45/G43 Express Chipset 

Description de la carte : Intel(R) G45/G43 Express Chipset
ID du vendeur : 8086
ID du périphérique : 2e22
RAM de la carte : Unknown
Pilotes de la carte : igxprd32
Version du pilote : 6.14.10.5303
Date du pilote : 9-21-2010
ID du vendeur  : (GPU #2)000c
ID du périphérique : (GPU #2)000c
RAM de la carte : (GPU #2)Unknown
Pilote de la carte : (GPU #2)Unknown
Version du pilote : (GPU #2)1.1.0.0
Date du pilote : (GPU #2)5-25-2004
Rendu WebGL : Google Inc. -- ANGLE (Intel(R) G45/G43 Express Chipset) -- OpenGL ES 2.0 (ANGLE 0.0.0.809)
Fenêtres avec accélération graphique : 2/2 Direct3D 9

I hope the next updates will solves this...
(In reply to Damien from comment #38)
> I hope the next updates will solves this...
If someone who can reproduce answers to comment 20, it could be fixed in the best case for Fx 12.
Is there an easy way to get all the Windows binaries for a specific branch, on a specific date?

I'm looking at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and I wouldn't know which versions to download and test.
(In reply to Shai Coleman from comment #40)
> Is there an easy way to get all the Windows binaries for a specific branch,
> on a specific date?
Use mozregression (see http://harthur.github.com/mozregression/) and start with:
mozregression --good=2011-08-16 --bad=2011-09-27
Damn it, now Firefox 11 is out and the BUG (YEAH IT'S A BUG) still exists. That's too bad. Before you add some new features, you should first fix the one's that didn't work. I expect that bug to be fixed in the next update. I still don't understand why this bug still exists. Allot of guys have the some problem and all the other browser doesn't have problems with crossfading. I don't want to know why this isn't be fixed, I want to know WHEN it's going to be fixed, I think this is not to much.
Mirko, don't spam the bug and answer to comment 20 instead, which is the only way to get it fixed.
Talk to my hand, OK!
I cannot reproduce with default setting of HWA.

Graphics        
Adapter Description : ATI Radeon HD 4300/4500 Series
Vendor ID : 0x1002
Device ID : 0x954f
Adapter RAM : 512
Adapter Drivers : aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Driver Version : 8.950.0.0
Driver Date : 2-14-2012
Direct2D Enabled : true
DirectWrite Enabled : true (6.1.7601.17776)
ClearType Parameters : Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 200
WebGL Renderer : Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)
GPU Accelerated Windows : 1/1 Direct3D 10
AzureBackend : direct2d


However, I can reproduce this problem only when I set layers.prefer-d3d9 = true.
GPU Accelerated Windows1/1 Direct3D 9

Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/cc66accc8181
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111026 Firefox/10.0a1 ID:20111026031017
Fails:
http://hg.mozilla.org/mozilla-central/rev/16a8d2ab5240
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111026 Firefox/10.0a1 ID:20111026163203
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc66accc8181&tochange=16a8d2ab5240



Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/98013fe19dcb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111025 Firefox/10.0a1 ID:20111025195747
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/d7f3bfc7cd46
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111025 Firefox/10.0a1 ID:20111025203245
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=98013fe19dcb&tochange=d7f3bfc7cd46

In local build,
Last good: 68d6ef3d84a3
First bad: 8b89d7037306
Triggered by:
8b89d7037306	Matt Woodrow — Bug 695275 - Fix conversion of ThebesLayers to ImageLayers. r=roc
Blocks: 695275
So this bug only happens with d3d9 layers? If that's the case then maybe its a bug in the d3d9 backend that is exposed by bug 695275.
I think the title of this bug should be modified to be more accurate, because fading works for some people.
(In reply to Timothy Nikkel (:tn) from comment #46)
> So this bug only happens with d3d9 layers?
It also happens without HW acceleration (see comment 7 and comment 27).
(In reply to Loic from comment #47)
> I think the title of this bug should be modified to be more accurate,
> because fading works for some people.

It works if you add a style of background-color to the element you are fading. In all other browsers including FF9 this was not the case. There was/is no need to add this style.
For me, the testcase in comment #30 works fine with BasicLayers and D3D10, but is clearly buggy in D3D9.
Attached patch fix — — Splinter Review
Assignee: nobody → roc
Attachment #607116 - Flags: review?
Attachment #607116 - Flags: review? → review?(bas.schouten)
Target Milestone: --- → mozilla14
Attachment #607116 - Flags: review?(bas.schouten) → review+
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #52)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/1383ac50bcff

> +<img style="opacity:0.001" src="http://i.imgur.com/Ct8Zm.jpg">

Was that intended (remote image in the reference case)?

This just hit a reftest orange, with "723484-1-ref.html | load failed: null", possibly (?) because of that remote image.
That reftest orange being:
https://tbpl.mozilla.org/php/getParsedLog.php?id=10215207&tree=Mozilla-Inbound
Rev3 Fedora 12 mozilla-inbound opt test reftest on 2012-03-20 09:24:26 PDT for push 3b64dbdc8d39
I backed this out, on the assumption that the remote image was unintended & is the cause of the "load failed: null" orange.  Also -- I just noticed that there's a reference to the remote image in the testcase, too (as well as the reference case).  I think that'd make this an orange-timebomb, failing whenever imgur's servers are overloaded / down (which may have been what happened in comment 54):
  https://hg.mozilla.org/integration/mozilla-inbound/rev/a403afe78c47
Target Milestone: mozilla14 → ---
Oops, this got merged to mozilla-central before it was backed out.  Leaving open because the backout should hit mozilla-central on the next merge.

https://hg.mozilla.org/mozilla-central/rev/1383ac50bcff
(In reply to Daniel Holbert [:dholbert] from comment #55)
> I backed this out
[...]
>   https://hg.mozilla.org/integration/mozilla-inbound/rev/a403afe78c47

(sorry, that's a different cset from the same push -- the backout cset was actually:
  https://hg.mozilla.org/integration/mozilla-inbound/rev/4672702bf939
)
https://hg.mozilla.org/mozilla-central/rev/c3d27335a1f2
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Version: 10 Branch → Trunk
Version: Trunk → 10 Branch
When will this bug fix be incorporated into the code in your estimation?
(In reply to Daveed from comment #61)
> When will this bug fix be incorporated into the code in your estimation?

The fix is in our code (that's what comment 60 meant). It should be available in Nightly builds tomorrow.
(In reply to Daveed from comment #61)
> When will this bug fix be incorporated into the code in your estimation?

Per the target milestone, the fix will currently ship to end users first in Firefox 14. However, there's a good chance that approval will be requested to land it for Firefox 12/13 as well. Since you're CCed to this bug, you will see the future emails as that process moves forward.
Comment on attachment 607116 [details] [diff] [review]
fix

Review of attachment 607116 [details] [diff] [review]:
-----------------------------------------------------------------

Risk analysis: extremely simple bug and low-risk patch. Enough impact that Web devs are trying to work around the bug. I strongly recommend aurora and beta approval.
Attachment #607116 - Flags: approval-mozilla-beta?
Attachment #607116 - Flags: approval-mozilla-aurora?
Comment on attachment 607116 [details] [diff] [review]
fix

[Triage Comment]
Low risk, and we're early enough still to get some bake time.
Attachment #607116 - Flags: approval-mozilla-beta?
Attachment #607116 - Flags: approval-mozilla-beta+
Attachment #607116 - Flags: approval-mozilla-aurora?
Attachment #607116 - Flags: approval-mozilla-aurora+
Comment on attachment 607116 [details] [diff] [review]
fix

Review of attachment 607116 [details] [diff] [review]:
-----------------------------------------------------------------

Risk analysis: extremely simple bug and low-risk patch. Enough impact that Web devs are trying to work around the bug. I strongly recommend aurora and beta approval.
Attachment #607116 - Flags: approval-mozilla-esr10?
Flags: in-testsuite+
Whiteboard: [qa+]
I've tested this on different machines on Win 7, Win 7/64, Ubuntu 11.10, Mac OS X 10.6 on FF 10 & 11. I could reproduce the problem only when I set layers.prefer-d3d9 =true only on Win 7/64.
The issue is also not reproducible on FF 12b3 on any of the above OSes.
Marking the bug as verified fixed.
Comment on attachment 607116 [details] [diff] [review]
fix

Let's fix this on ESR10 if organizations find this a major pain point.
Attachment #607116 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10-
(In reply to Alex Keybl [:akeybl] from comment #69)
> Let's fix this on ESR10 if organizations find this a major pain point.
You should have not rejected the review in that case.
Verified fixed on Firefox 13b2:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0
Whiteboard: [qa+] → [qa+][qa!:12][qa!:13]
I have ran into this problem this week as well!

It is fixed w/ a background color ALTHOUGH, if you use transform:rotate or
-moz-transform:rotate(270deg); /* Firefox */ in this case... than the problem comes bacK!

so once u rotate your screen in Firefox and try to Toggle Opacity or FadeTo, than the white/black screen issue comes back :(

www.artpineda.com   //live sample on my porfolio site using firefox 22.0
I have ran into this problem this week as well!

It is fixed w/ a background color ALTHOUGH, if you use transform:rotate or
-moz-transform:rotate(270deg); /* Firefox */ in this case... than the problem comes bacK!

so once u rotate your screen in Firefox and try to Toggle Opacity or FadeTo, than the white/black screen issue comes back :(

www.artpineda.com   //live sample on my porfolio site using firefox 22.0
This issue was fixed back in Firefox 12. Please open a new bug for your specific use case.

Thank you
You need to log in before you can comment on or make changes to this bug.