Last Comment Bug 590568 - [D3D9] plugin area is shown in toolbars when scrolled off the screen as a rectangle about the size of plugin area being scrolled
: [D3D9] plugin area is shown in toolbars when scrolled off the screen as a rec...
Status: RESOLVED FIXED
[Input]
: regression
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All Windows 7
: -- normal with 9 votes (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
:
Mentors:
http://www.youtube.com/watch?v=IejYtD...
: 597955 599695 601419 608533 610445 612000 612061 615204 615370 615821 619139 (view as bug list)
Depends on: 622492 613449
Blocks: d2d 564991 d3d9-layers
  Show dependency treegraph
 
Reported: 2010-08-25 09:51 PDT by [not reading bugmail]
Modified: 2012-06-09 02:27 PDT (History)
54 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
betaN+


Attachments
plugin area scrolled off content area shown as rectangle in chrome area (557.93 KB, image/png)
2010-08-25 09:53 PDT, [not reading bugmail]
no flags Details
[D3D9] Another version of the plugin resized (175.46 KB, image/jpeg)
2010-08-27 23:15 PDT, [not reading bugmail]
no flags Details
simple testcase (87 bytes, text/html)
2010-11-17 19:20 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
slightly more interesting testcase (198 bytes, text/html)
2010-11-17 19:28 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
black background testcase (131 bytes, text/html)
2010-11-17 19:39 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
Screenshot (11.64 KB, image/png)
2010-11-17 19:40 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
even creepier screenshot (52.29 KB, image/png)
2010-11-17 19:48 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
Simplified XUL testcase (542 bytes, application/vnd.mozilla.xul+xml)
2010-11-18 20:19 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
D3DTest.cpp (7.57 KB, text/plain)
2010-11-18 20:54 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
fix (1.88 KB, patch)
2010-11-22 18:29 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
jmathies: review+
Details | Diff | Splinter Review
Change of bug rendering in toolbars from white rectangle to "Aero" effect in Windows 7 (227.32 KB, image/png)
2010-12-13 11:48 PST, kolubinowicki
no flags Details
Plugin content is improperly rendered outside the toolbar area. (1008.06 KB, video/webm)
2010-12-14 15:48 PST, kolubinowicki
no flags Details
situation after recent d3d9 changes (33.96 KB, image/jpeg)
2010-12-21 09:54 PST, Marco Bonardo [::mak]
no flags Details
Change of bug rendering. Gecko/20101221 Firefox/4.0b9pre (428.05 KB, image/png)
2010-12-21 12:58 PST, kolubinowicki
no flags Details
Glitches Gecko/20101223 Firefox/4.0b9pre (175 bytes, text/html)
2010-12-24 05:14 PST, kolubinowicki
no flags Details
Patch 2: try resetting clip region immediately before and after moving/resizing the plugin window, if we're clipped (6.14 KB, patch)
2010-12-27 13:17 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
Patch 3: repaint under the moved plugin (4.87 KB, patch)
2010-12-27 13:44 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
Screencast with bug behaviour with tryserver-build (fc2bc1ec371c) (175 bytes, text/html)
2010-12-28 01:56 PST, kolubinowicki
no flags Details
"flickering" + "persistent damage" tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c (784.51 KB, video/webm)
2010-12-28 02:44 PST, kolubinowicki
no flags Details
Screencast "Persistent damage" Minefield Gecko/20101227 Firefox/4.0b9pre (1.33 MB, video/webm)
2010-12-28 04:17 PST, kolubinowicki
no flags Details
Screencast of glitches outside the toolbar area tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c (1.46 MB, video/webm)
2010-12-28 05:57 PST, kolubinowicki
no flags Details
screencast of plugin overwriting chrome on first scroll and flickering (1.35 MB, video/webm)
2010-12-29 18:03 PST, voracity
no flags Details
Screencast resizing window Gecko/20101229 Firefox/4.0b9pre (416.74 KB, video/webm)
2010-12-30 06:05 PST, kolubinowicki
no flags Details
patch 4: always update stored window clip region (3.64 KB, patch)
2010-12-30 23:03 PST, Timothy Nikkel (:tnikkel)
roc: review+
Details | Diff | Splinter Review
patch for checkin - always update stored window clip region (3.66 KB, patch)
2010-12-31 11:59 PST, Timothy Nikkel (:tnikkel)
tnikkel: review+
Details | Diff | Splinter Review
Sample Paint Error latest patch (80.11 KB, image/jpeg)
2010-12-31 17:25 PST, [not reading bugmail]
no flags Details
Screencast overlaying of plugin area over site toolbar. Gecko/20110101 Firefox/4.0b9pre (784.60 KB, video/webm)
2011-01-01 12:46 PST, kolubinowicki
no flags Details
Before Scrolling (84.27 KB, image/jpeg)
2011-01-04 13:13 PST, dfghjkjhg
no flags Details
After Scrolling (95.21 KB, image/jpeg)
2011-01-04 13:14 PST, dfghjkjhg
no flags Details

Description [not reading bugmail] 2010-08-25 09:51:08 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100824 Minefield/4.0b5pre Firefox/4.0b4pre
Build Identifier: 

Plugin shows white/bluish box in the chrome area when scrolling a playing plugin off screen with direct2d enabled.


Reproducible: Always

Steps to Reproduce:
1. Turn on D2d
2. Load Youtube flash video
3. scroll page down off so video is half cut over chrome and content area
Actual Results:  
box is shown where plugin would be painting

Expected Results:  
No box is shown in chrome/toolbars area

This is a regression from retain layers.  See screenshot.
Comment 1 [not reading bugmail] 2010-08-25 09:53:25 PDT
Created attachment 469081 [details]
plugin area scrolled off content area shown as rectangle in chrome area
Comment 2 Brian Carpenter [:geeknik] 2010-08-26 19:53:38 PDT
This is blocking B5+ and still marked Uncomfirmed? Setting status to New since I can confirm this behavior.
Comment 3 Bas Schouten (:bas.schouten) 2010-08-26 20:15:55 PDT
(In reply to comment #2)
> This is blocking B5+ and still marked Uncomfirmed? Setting status to New since
> I can confirm this behavior.

How do you reproduce it, we haven't seen it on any of our machines. I can't seem to reproduce it anywhere either? (I can reproduce the flash invalidation bug, but that doesn't interfere with chrome)

What kind of hardware are you on and what drivers? Also are you manually turning on D2D or is it being turned on by default?
Comment 4 Jeff Muizelaar [:jrmuizel] 2010-08-27 08:59:18 PDT
(In reply to comment #0)
> Steps to Reproduce:
> 1. Turn on D2d
> 2. Load Youtube flash video
> 3. scroll page down off so video is half cut over chrome and content area
> Actual Results:  
> box is shown where plugin would be painting

How consistently can you reproduce this?
Comment 5 [not reading bugmail] 2010-08-27 12:35:47 PDT
I can reproduce 100%, I was trying to figure out how to make a screencast incase the STR is a bit fuzzy.  Testing on Nvidia 7050 D3D9, D2D enabled using render-mode 6.
Comment 6 [not reading bugmail] 2010-08-27 12:38:22 PDT
It happens as I scroll the page down/up and plugin moves under the chrome/toolbars area.  the video doesn't always have to be playing, but as the plugin goes off the screen edge, it shows a rectangle about the same as the area moving off, but in the chrome area, so when I release the mouse and move it around, the rectangle in the chrome area will disappear.
Comment 7 Wes Kocher (:KWierso) 2010-08-27 13:19:01 PDT
(In reply to comment #5)
> I can reproduce 100%, I was trying to figure out how to make a screencast
> incase the STR is a bit fuzzy.  Testing on Nvidia 7050 D3D9, D2D enabled using
> render-mode 6.

If you're on recent trunk builds, render-mode 6 is not D2D enabled.
Comment 8 [not reading bugmail] 2010-08-27 13:24:10 PDT
its forced on using 6.
about:support Graphics
        Adapter Description        NVIDIA GeForce 7050 / NVIDIA nForce 610i
        Vendor ID        10de
        Device ID        07e3
        Adapter RAM        256
        Adapter Drivers        nvd3dum  捑ဈ
        Driver Version        8.17.12.5721
        Driver Date        6-7-2010
        Direct2D Enabled        true
        DirectWrite Enabled        true
Comment 9 Gary [:streetwolf] 2010-08-27 13:46:33 PDT
The video in question does all sorts of strange things on my system. I get an empty grey screen with the audio playing.  Sometimes I'll get the video playing in this same grey screen. Sometimes just an empty white screen.  In all cases I eventually get a screen with the close button (X) so I can get out of it.

I have an ATI HD5870.

Direct2D Enabled     true
DirectWrite Enabled  true


Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre - Build ID: 20100827101721
Comment 10 [not reading bugmail] 2010-08-27 14:04:27 PDT
Updated URL with YouTube screencast of this bug.
Comment 11 Joe Drew (not getting mail) 2010-08-27 17:48:39 PDT
I believe that Rob wanted to look into this.
Comment 12 [not reading bugmail] 2010-08-27 21:53:28 PDT
If I turn off DirectWrite pref, but leave on the Render Mode pref at 6, I see a section of the flash object painting instead of a white rectangle box.
Comment 13 [not reading bugmail] 2010-08-27 22:02:17 PDT
(In reply to comment #12)
> If I turn off DirectWrite pref, but leave on the Render Mode pref at 6, I see a
> section of the flash object painting instead of a white rectangle box.

I see it the plugin paint in the chrome no matter what the preferences are set to after this hourly cset: http://hg.mozilla.org/mozilla-central/rev/0886ad6e6aaa 
which changed the behavior of this bug.
Comment 14 [not reading bugmail] 2010-08-27 23:10:01 PDT
Filed bug 591570 for the new behavior and didn't know if we should morph this bug.
Comment 15 [not reading bugmail] 2010-08-27 23:15:29 PDT
Created attachment 470158 [details]
[D3D9] Another version of the plugin resized

This one shows white over gradient toolbars, and black in glass area, when using the resize plugin option
Comment 16 Bas Schouten (:bas.schouten) 2010-08-27 23:38:11 PDT
(In reply to comment #15)
> Created attachment 470158 [details]
> [D2D] Another version of the plugin resized
> 
> This one shows white over gradient toolbars, and black in glass area, when
> using the resize plugin option

I wouldn't be surprised if after 130078 landed tonight, and once the subsequent bugfixes are landed. This bug either completely changes behavior or doesn't reproduce anymore.
Comment 17 [not reading bugmail] 2010-08-28 09:15:10 PDT
This bug is still reproduceable in the nightly.
Comment 18 Bas Schouten (:bas.schouten) 2010-08-28 09:32:00 PDT
(In reply to comment #17)
> This bug is still reproduceable in the nightly.

Neat. Might be a D3D9 issue I suppose.
Comment 19 Jim Mathies [:jimm] 2010-08-30 06:13:43 PDT
WFM, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100829 Firefox/4.0b5pre.

I see some pretty nasty scroll artifacts in the plugin window, but I think that might be another bug.
Comment 20 Joe Drew (not getting mail) 2010-08-30 10:03:23 PDT
Unless this can be reproduced with DX10 hardware, this doesn't block at all.
Comment 21 Brian Carpenter [:geeknik] 2010-08-30 11:23:00 PDT
ATI 5870 w/ Cat 10.8 drivers on Win 7 Pro x64 and the only thing I see are issues like http://imgur.com/N0046.png on Youtube while scrolling, sometimes switching tabs or minimizing and maximizing the windows eradicates them until I scroll again.
Comment 22 Bas Schouten (:bas.schouten) 2010-08-30 11:29:08 PDT
(In reply to comment #21)
> ATI 5870 w/ Cat 10.8 drivers on Win 7 Pro x64 and the only thing I see are
> issues like http://imgur.com/N0046.png on Youtube while scrolling, sometimes
> switching tabs or minimizing and maximizing the windows eradicates them until I
> scroll again.

This is bug 587508. It's reproducable for everyone.
Comment 23 [not reading bugmail] 2010-09-02 20:23:43 PDT
updating summary, the color is not real important, as it also changes based on using personas; I've seen it shown as black and gray as well.
Comment 24 u88484 2010-09-18 07:44:50 PDT
Should bug 585912 or this one be duped to each other?
Comment 25 imradyurrad 2010-09-21 20:50:17 PDT
Since D2D is on by default now, shouldn't this be blocking?
Comment 26 Joe Drew (not getting mail) 2010-09-21 20:53:43 PDT
Not unless this can be reproduced with DX10 hardware. See comment 20.
Comment 27 Riccio 2010-09-26 03:12:54 PDT
I'm seeing this bug with the latest nightly on Win7x64 and
Adapter Description  NVIDIA GeForce 7600 GT 
Vendor ID  10de
Device ID  0391
Adapter RAM  256
Adapter Drivers  nvd3dumx,nvd3dum
Driver Version  8.17.11.9713
Driver Date  3-15-2010
Direct2D Enabled  false
DirectWrite Enabled  false
GPU Accelerated Windows  1/1 Direct3D 9
Comment 28 voracity 2010-09-28 04:42:27 PDT
I've been seeing this since direct3d layers got turned on by default. My system:

Windows 7 x64 (32 bit Fx and Flash)
Adapter Description        NVIDIA GeForce 7600 GS
Vendor ID                  10de
Device ID                  0392
Adapter RAM                256
Adapter Drivers            nvd3dumx,nvd3dum
Driver Version             8.17.12.5896
Driver Date                7-9-2010
Direct2D Enabled           false
DirectWrite Enabled        true
GPU Accelerated Windows    1/1 Direct3D 9

So looks like might be an issue with either NVidia GeForce 7600 and/or Win7 x64.

Also, when I try and copy/paste the table from about:support, it comes out like this:

Adapter DescriptionNVIDIA GeForce 7600 GS Vendor ID10deDevice ID0392Adapter RAM256Adapter Driversnvd3dumx,nvd3dumDriver Version8.17.12.5896Driver Date7-9-2010Direct2D EnabledfalseDirectWrite EnabledtrueGPU Accelerated Windows1/1 Direct3D 9

Off-topic, I know, but very annoying...
Comment 29 Bas Schouten (:bas.schouten) 2010-09-28 06:38:36 PDT
This is being reported by people with no D2D, but just D3D9.
Comment 30 fxtech 2010-10-07 20:04:32 PDT
i have same issue with 

Adapter DescriptionNVIDIA GeForce 7600 GS 
Vendor ID10de
Device ID0392
Adapter RAM 512
Adapter Drivers nvd3dum 
Driver Version8.17.12.6063
Driver Date9-10-2010
Direct2D Enabledtrue
DirectWrite Enabledtrue
GPU Accelerated Windows1/1 Direct3D 10
Comment 31 lopardo 2010-10-11 15:45:59 PDT
I still have the same problem, using latest beta drivers (260.89).

Adapter Description
NVIDIA GeForce 7600 GT

Vendor ID
10de

Device ID
0391

Adapter RAM
256

Adapter Drivers
nvd3dumx,nvd3dum

Driver Version
8.17.12.6089

Driver Date
10-8-2010

Direct2D Enabled
false

DirectWrite Enabled
true

GPU Accelerated Windows
1/1 Direct3D 9
Comment 32 fxtech 2010-10-12 00:09:23 PDT
ok the issue is partially fixed with the bug https://bugzilla.mozilla.org/show_bug.cgi?id=600908 (fixed in the hourly http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1286860041/ )

now the withe box over the toolbar is showed less and just during fast scrolling , when you stop to scroll the toolbar is repainted over it)
Comment 33 fxtech 2010-10-12 00:18:15 PDT
sorry , i partialli fix just some youtube , but the problem still here in the strongest way , please try www.autoblog.it (page with some embeded flash player)
Comment 34 Timothy Nikkel (:tnikkel) 2010-10-12 21:57:28 PDT
I wonder if this and bug 593703 are the same?
Comment 35 [not reading bugmail] 2010-10-12 23:04:52 PDT
(In reply to comment #34)
> I wonder if this and bug 593703 are the same?

It looks like it to me, the screenshot is what I think makes it so, even though I didn't read all the way through that bug.
Comment 36 fxtech 2010-10-13 00:35:58 PDT
yes it is the same, could we move to the other bug ?
Comment 37 Tomas 2010-10-16 10:05:22 PDT
Time to mark this bug as dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=593703 ?
Comment 38 imradyurrad 2010-10-16 10:45:47 PDT
Other way around.
Comment 39 fxtech 2010-10-18 12:06:17 PDT
i know , title already said it , but just to confirm , that even using DX9 card , enabling "layers.use-d3d10" the youtube glitch disappears , so we can assume that the issue is on layer code and not on flash
Comment 40 fxtech 2010-10-19 16:28:53 PDT
another round 

strange situation here:

layers.accelerate-all;false

layers.prefer-d3d9;false

gfx.direct2d.force-enabled;true

result in

Direct2D Enabled true
DirectWrite Enabled true
GPU Accelerated Windows 0/1

all seams accelerated , i have better score on ie9 test drive than before

all the glitch (black box , trasparent layer not rendere etc etc) gone

flash player glitch gone (a white box is drawed on the toolbar but is repainted
almost immediatly with chrome element)
Comment 41 [not reading bugmail] 2010-10-19 18:27:41 PDT
(In reply to comment #40)

> layers.prefer-d3d9;false
> GPU Accelerated Windows 0/1

Bas, I'm guess it should be a d3d10 as a GPU accelerated Window, not 0/1, no?  

This bug is still about d3d9 regardless.
Comment 42 [not reading bugmail] 2010-10-19 19:11:03 PDT
(In reply to comment #41)
> (In reply to comment #40)
> 
> > layers.prefer-d3d9;false
> > GPU Accelerated Windows 0/1
> 
> Bas, I'm guess it should be a d3d10 as a GPU accelerated Window, not 0/1, no?  
> 

I see the issue with that now.. read on:

(In reply to comment #40)
> layers.accelerate-all;false
> layers.prefer-d3d9;false
> gfx.direct2d.force-enabled;true

I see you have layer.accelerate-all;false.  about:support would of said GPU Acceleration: Direct3D 10 1/1, so your just running D2D/DW, not D3D9 or D3D10, so false alarm.  We already know this case works.
Comment 43 fxtech 2010-10-20 05:50:36 PDT
if im using accelerate-all; true, i have the D3D10 work well with flash player but if i force to use D3D9 the flash player paint over the crhome toolbar
Comment 44 fxtech 2010-10-23 14:39:45 PDT
duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=593839 ?
Comment 45 kolubinowicki 2010-10-27 13:28:02 PDT
The white rectangle don't occur when scrolling on Liveleak.com video site (different video flash player?):

http://www.liveleak.com/view?i=84c_1288188804

but I have 100% repetition of this bug on any Youtube video.

More info:

Windows 7 32bit
Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101027 Firefox/4.0b8pre
Adapter Description ATI MOBILITY RADEON X1300
Vendor ID 1002
Device ID714a
Adapter RAM 128MB 
Drivers atiumdag atiumdva atitmmxx 
Driver Version 8.593.100.0 
Driver Date 2-10-2010 
Direct2D Enabled false 
DirectWrite Enabled false 
GPU Accelerated Windows 1/1 Direct3D 9
Comment 46 Hao Shen 2010-11-11 01:15:31 PST
I have the same problem.

Windows7 32bit
Mozilla/5.0 (Windows NT 6.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Adapter Description ATI RADEON X1600
Driver Version 8.56.1.15
Comment 47 Bas Schouten (:bas.schouten) 2010-11-11 02:32:04 PST
That's odd, I thought this would've been fixed by all the work we've done on plugins.
Comment 48 voracity 2010-11-11 04:25:18 PST
Wow, this is certainly not fixed. I'm currently using FlashBlock to make the browser usable with hardware acceleration on. (The browser is _so_ much faster with acceleration that I'd rather give up convenient Flash.)

Personally, I hadn't followed up because I assumed it was being worked on. Did you need regular reports on whether this has been fixed yet?
Comment 49 Bas Schouten (:bas.schouten) 2010-11-11 05:54:28 PST
Hrm, well, mainly I wish I had a clue about what's going on. I can't reproduce it anywhere either.
Comment 50 Jem 2010-11-11 05:59:30 PST
Reproducible here: http://www.bbc.co.uk/news/uk-politics-11728546

Play the vid and scroll up.

(b8 pre Win32 20101111)
Comment 51 [not reading bugmail] 2010-11-11 08:24:06 PST
So there must be some code in D3D9 that is different then the D3D10 path here, no?
Comment 52 Wes Kocher (:KWierso) 2010-11-11 08:31:09 PST
Comment 50's video link works fine for me just fine with D3D10.
Comment 53 Jem 2010-11-11 08:44:59 PST
Ok...now I'm going to show my ignorance (I'm just semi-technical trying to help). What is D3D9 / D3D10...?
Comment 54 Jem 2010-11-11 08:58:09 PST
(In reply to comment #53)
> Ok...now I'm going to show my ignorance (I'm just semi-technical trying to
> help). What is D3D9 / D3D10...?

If it's DirectX - I'm running 11 (Win7)
Comment 55 Michael Lefevre 2010-11-11 09:03:54 PST
(In reply to comment #54)
> (In reply to comment #53)
> > Ok...now I'm going to show my ignorance (I'm just semi-technical trying to
> > help). What is D3D9 / D3D10...?
> 
> If it's DirectX - I'm running 11 (Win7)

It is part of DirectX - if you're running DirectX 11, then your Firefox should be using Direct3D 10 (D3D10). Typing "about:support" into your address bar should tell you.
Comment 56 Jem 2010-11-11 09:13:11 PST
(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #53)
> > > Ok...now I'm going to show my ignorance (I'm just semi-technical trying to
> > > help). What is D3D9 / D3D10...?
> > 
> > If it's DirectX - I'm running 11 (Win7)
> 
> It is part of DirectX - if you're running DirectX 11, then your Firefox should
> be using Direct3D 10 (D3D10). Typing "about:support" into your address bar
> should tell you.

OK...strange...In dxdiag it says I'm using DirectX 11. In about:support it tells me Direct3D 9! Maybe I should download DirectX and re-install + test..?
Comment 57 Csaba Kozák [:WonderCsabo] 2010-11-11 09:21:42 PST
Do you have a Dx10 capable graphics card?

Are you sure that you don't force D3D9 in about:config?
Comment 58 Jem 2010-11-11 09:27:37 PST
(In reply to comment #57)
> Do you have a Dx10 capable graphics card?

I don't know - it's a fairly humble NVidia GeForce 6600

> Are you sure that you don't force D3D9 in about:config?

Not that I have knowingly changed - which setting in about:config?
Comment 59 Csaba Kozák [:WonderCsabo] 2010-11-11 09:32:14 PST
Doesn't matter, 6600 is not a Dx10 capable card, that's why you use D3D9.
Comment 60 [not reading bugmail] 2010-11-11 09:46:26 PST
I'm glad your all willing to help, but this bug is not about debugging your PC's version of support for DirectX or Firefox's D3D level of support to see if you see this bug, that belongs in support forums.  Next time, can you please take that elsewhere as Bugzilla is not a forum for discussion?  

We know Firefox only supports various configurations of rendering, D3D9 is one of them, and the Nvidia 6600 is about the same as the 7xxx series so that makes sense you will see this bug as it is a D3D9 part.

The pieces that we noticed trigger this bug are:

hardware acceleration turned on in Advanced options
layers.prefer-D3D9;true
layers.accelerate-none;false
layers.accelerate-all;true
and some flavors of Nvidia and ATI cards or onboard video devices.

If this bug is reproducible under other configurations, then we want to know about it.
Comment 61 Jem 2010-11-11 10:00:21 PST
(In reply to comment #60)
> I'm glad your all willing to help, but this bug is not about debugging your
> PC's version of support for DirectX or Firefox's D3D level of support to see if
> you see this bug, that belongs in support forums.  Next time, can you please
> take that elsewhere as Bugzilla is not a forum for discussion?  
> 
> We know Firefox only supports various configurations of rendering, D3D9 is one
> of them, and the Nvidia 6600 is about the same as the 7xxx series so that makes
> sense you will see this bug as it is a D3D9 part.
> 
> The pieces that we noticed trigger this bug are:
> 
> hardware acceleration turned on in Advanced options
> layers.prefer-D3D9;true
> layers.accelerate-none;false
> layers.accelerate-all;true
> and some flavors of Nvidia and ATI cards or onboard video devices.
> 
> If this bug is reproducible under other configurations, then we want to know
> about it.

I appreciate all of that, and I only posted here as I could reproduce the bug which Bas said he couldn't, which then led down this road. Infuriating as b6 did not show this problem. b7 onwards does...
Comment 62 Brian Carpenter [:geeknik] 2010-11-11 11:08:15 PST
I can still reproduce this with the video in comment #50 and most other flash videos on the web.

Adapter Description NVIDIA GeForce 7950 GT
Vendor ID 10de 
Device ID 0295
Adapter RAM 256
Adapter Drivers nvd3dumx,nvd3dum
Driver Version 8.17.12.6099
Driver Date 10-16-2010
Direct2D Enabled false
DirectWrite Enabled true
GPU Accelerated Windows 1/1 Direct3D 9

When I had an ATI R5870 in this machine, I was not seeing this issue at all.
Comment 63 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-11 13:05:33 PST
I can reproduce this bug in my VMWare Win7 VM. I'm planning to try to analyze it using record-and-replay, but I had trouble getting record-and-replay debugging going on my laptop and I've been busy with other stuff since. I will get back to this.
Comment 64 Jim Mathies [:jimm] 2010-11-11 19:10:47 PST
*** Bug 599695 has been marked as a duplicate of this bug. ***
Comment 65 Bas Schouten (:bas.schouten) 2010-11-12 08:31:53 PST
(In reply to comment #63)
> I can reproduce this bug in my VMWare Win7 VM. I'm planning to try to analyze
> it using record-and-replay, but I had trouble getting record-and-replay
> debugging going on my laptop and I've been busy with other stuff since. I will
> get back to this.

Hrm, never occurred to me to try this in a Win7 VM, interesting idea, I wonder if it will repro there for me too.
Comment 66 Ed Morley [:emorley] 2010-11-13 07:01:48 PST
I believe both of these are dupes of this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=597955
https://bugzilla.mozilla.org/show_bug.cgi?id=593703

@Baz, comment #65 :
Roc managed to reproduce the issue in a VM, assuming the above two bugs are indeed dupes of this one. For the relevant comment, see: https://bugzilla.mozilla.org/show_bug.cgi?id=593703#c48

Again, assuming the two bugs above are dupes, see here for the reduced test case:
https://bugzilla.mozilla.org/show_bug.cgi?id=593703#c46
Comment 67 Jim Mathies [:jimm] 2010-11-13 08:48:16 PST
*** Bug 612000 has been marked as a duplicate of this bug. ***
Comment 68 Cyberkilla 2010-11-13 09:11:41 PST
I think the following bug is the same as the following one:

https://bugzilla.mozilla.org/show_bug.cgi?id=608533
Comment 69 Cyberkilla 2010-11-13 09:15:11 PST
(In reply to comment #68)
> I think the following bug is the same as the following one:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=608533

Apologies for the nonsensical sentence.

I can confirm this too.

---
Sony VAIO VGN-AR41E
Windows 7
NVidia Geforce 8400M GT (Driver v167.60)
---
Comment 70 fxtech 2010-11-13 14:17:34 PST
with the build 20101113 is fixed for me, the rectangle is painted for just a frame and even for fast scrolling , but it is repainted with the toolbar almost immediatly. Tested here www.autoblog.it www.cineblog.it 

layer accelerate all true 

d2d enabled

and layers.prefer-d3d9 true
Comment 71 Ed Morley [:emorley] 2010-11-13 14:34:47 PST
Not fixed for me using:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101113 Firefox/4.0b8pre

Adapter Description: NVIDIA GeForce 6200 TurboCache(TM)
Vendor ID: 10de
Device ID: 0161
Adapter RAM: 64
Adapter Drivers: nvd3dumx,nvd3dum
Driver Version: 8.17.12.5896
Driver Date: 7-9-2010
Direct2D Enabled: false
DirectWrite Enabled: false
GPU Accelerated Windows: 1/1 Direct3D 9
Comment 72 fxtech 2010-11-13 23:45:54 PST
Sorry , was my fault , i was posting from the computer with a dx10 card , it still NOT FIXED
Comment 73 [not reading bugmail] 2010-11-14 00:12:59 PST
*** Bug 597955 has been marked as a duplicate of this bug. ***
Comment 74 [not reading bugmail] 2010-11-14 00:13:51 PST
*** Bug 608533 has been marked as a duplicate of this bug. ***
Comment 75 [not reading bugmail] 2010-11-14 00:27:25 PST
(In reply to comment #44)
> duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=593839 ?

Thats a different bug.
Comment 76 Jem 2010-11-14 08:14:11 PST
Still showing here at BBC News as before. 20101114. D3D9.
Comment 77 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-14 13:35:41 PST
BTW does everyone see this with with OOPP enabled *and* disabled?

I'm guessing this is a driver bug where the driver incorrectly ignores the WindowRgn of the plugin window. I need to check by writing a D3D test app. If so, then for OOPP we can probably work around this fairly easily by altering the size and position of the plugin HWND to be the bounds of the window clip region. That'll be harder for non-OOPP though.
Comment 78 Stewart Souter 2010-11-14 13:37:49 PST
In my experiments this only happens when "Use hardware
acceleration when available" is checked. If you disable this option then objects
scroll as expected.
Comment 79 [not reading bugmail] 2010-11-14 15:25:32 PST
(In reply to comment #77)
> BTW does everyone see this with with OOPP enabled *and* disabled?

It does for me.  



(In reply to comment #78)
> In my experiments this only happens when "Use hardware
> acceleration when available" is checked. 

Probably because you have a D3D9 card.

> If you disable this option then objects scroll as expected.

This is expected and confirmed already, since this is a D3D9 bug, and D3D9/10 would not show as accelerated windows (in about:support) when you turn off this option because it flips the prefs to this:

layers.accelerate-none;true
layers.accelerate-all;false
Comment 80 lopardo 2010-11-14 19:11:51 PST
(In reply to comment #77)
> BTW does everyone see this with with OOPP enabled *and* disabled?

Yes, it happens with OOPP disabled too (dom.ipc.plugins.enabled;false).
Comment 81 Aakash Desai [:aakashd] 2010-11-15 14:22:13 PST
Some use cases can be found here on the following Input query: http://input.stage.mozilla.com/en-US/search/?q=white+&product=firefox&version=4.0b7&date_start=&date_end=&os=win7
Comment 82 Jem 2010-11-16 09:26:20 PST
(In reply to comment #77)
> BTW does everyone see this with with OOPP enabled *and* disabled?
> 
> I'm guessing this is a driver bug where the driver incorrectly ignores the
> WindowRgn of the plugin window. I need to check by writing a D3D test app. If
> so, then for OOPP we can probably work around this fairly easily by altering
> the size and position of the plugin HWND to be the bounds of the window clip
> region. That'll be harder for non-OOPP though.

Hi, excuse the possibly naive question, but why did this problem only show itself post b6? What changed?
Comment 83 Bas Schouten (:bas.schouten) 2010-11-16 09:33:00 PST
(In reply to comment #82)
> (In reply to comment #77)
> > BTW does everyone see this with with OOPP enabled *and* disabled?
> > 
> > I'm guessing this is a driver bug where the driver incorrectly ignores the
> > WindowRgn of the plugin window. I need to check by writing a D3D test app. If
> > so, then for OOPP we can probably work around this fairly easily by altering
> > the size and position of the plugin HWND to be the bounds of the window clip
> > region. That'll be harder for non-OOPP though.
> 
> Hi, excuse the possibly naive question, but why did this problem only show
> itself post b6? What changed?

We enabled accelerated layers as of b7pre. So the problem would not exist in b6.
Comment 84 Ed Morley [:emorley] 2010-11-16 14:24:38 PST
Believed dupes, can someone with permissions mark them please:
https://bugzilla.mozilla.org/show_bug.cgi?id=593703
https://bugzilla.mozilla.org/show_bug.cgi?id=612061
Comment 85 Joe Drew (not getting mail) 2010-11-16 14:39:06 PST
*** Bug 612061 has been marked as a duplicate of this bug. ***
Comment 86 juan becerra [:juanb] 2010-11-16 16:32:42 PST
Should this block beta?
Comment 87 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-16 17:00:37 PST
I think this has to block. I don't know about Joe's comment about DX10 hardware, but it shows up for a lot of people.
Comment 88 Cyberkilla 2010-11-17 09:50:16 PST
Hello, a few comments here appear claim that the problem is with cards that only support DX9 (at least that's what I got from them ;-))

I'm confused now...

My dxdiag.exe says DirectX 10.
My graphics card is an NVidia GeForce 8400m GT, which claims to support DX10:
- "The NVIDIA GeForce 8400M also enables you to play the hottest new games featuring DirectX 10." (http://www.nvidia.com/object/geforce_8M.html)
- "NVidia GeForce 8400M GT is the DirectX 10 capable successor of the GeForce Go 7400 for laptops" (http://www.notebookcheck.net/NVidia-GeForce-8400M-GT.3708.0.html)

I'm not trying to prove anyone wrong. I probably just misunderstood, however, my card *seems* to be DirectX 10 capable, but I still have the problem (and Firefox reports that its using d3d9).

It's probably not important, but I though it wise to point it out.
Comment 89 Joe Drew (not getting mail) 2010-11-17 10:34:29 PST
Regarding comment 20, this was originally a problem with D2D, and we don't support D2D on D3D9 hardware. However, if people are seeing this using only D3D9 layer compositing, we need to block on this.
Comment 90 [not reading bugmail] 2010-11-17 11:03:44 PST
(In reply to comment #88)
> Hello, a few comments here appear claim that the problem is with cards that
> only support DX9 (at least that's what I got from them ;-))
> 
> I'm confused now...
> 
> My dxdiag.exe says DirectX 10.
> My graphics card is an NVidia GeForce 8400m GT, which claims to support DX10:
> - "The NVIDIA GeForce 8400M also enables you to play the hottest new games
> featuring DirectX 10." (http://www.nvidia.com/object/geforce_8M.html)
> - "NVidia GeForce 8400M GT is the DirectX 10 capable successor of the GeForce
> Go 7400 for laptops"
> (http://www.notebookcheck.net/NVidia-GeForce-8400M-GT.3708.0.html)
> 
> I'm not trying to prove anyone wrong. I probably just misunderstood, however,
> my card *seems* to be DirectX 10 capable, but I still have the problem (and
> Firefox reports that its using d3d9).
> 
> It's probably not important, but I though it wise to point it out.

Support for DX10 tends varies by card, and manufacturers are always updating drivers.  Again, we're not really comparing DX10 dxdiag software install support in Windows here against Firefox's support level, but we're checking Firefox's rendering code path like D3D9.

I would also encourage anyone to also take a look at bug 612186 as Bas had some good info to share there.
Comment 91 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 19:20:12 PST
Created attachment 491431 [details]
simple testcase

I see this in VMWare with D3D9 enabled and D2D disabled. This is about the simplest possible testcase and it reproduces 100%.
Comment 92 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 19:28:36 PST
Created attachment 491434 [details]
slightly more interesting testcase

This testcase shows that the problem (in VMWare at least) is specifically triggered by the nsIWidget->Move() call in ConfigureChildren. Load it -> no problem, then click in the page -> problem.
Comment 93 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 19:39:49 PST
Created attachment 491439 [details]
black background testcase

Load this one and then make the window narrow so that the right window edge overlays the plugin. On my setup, I see some kind of weird highlight effect in the rightmost two columns of pixels in the plugin.
Comment 94 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 19:40:41 PST
Created attachment 491440 [details]
Screenshot

This shows the highlight effect. Note how it doesn't happen above the top edge of the plugin window.
Comment 95 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 19:48:48 PST
Created attachment 491442 [details]
even creepier screenshot

If I make the window vertically small, I get an even creepier screenshot. The plugin makes the whole browser window partially transparent --- or something --- where the plugin window is.

These last two problems I can reproduce on my Nvidia card outside the VM, actually. But only with D3D9.
Comment 96 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 20:37:49 PST
Er, wrong. Actually I see those two problems with no acceleration at all! And with D3D9, and with D3D10 (+D2D).
Comment 97 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 20:41:38 PST
I'll treat those as unrelated and spin off a new bug for them.
Comment 98 Wes Kocher (:KWierso) 2010-11-17 20:49:59 PST
(In reply to comment #93)
> Created attachment 491439 [details]
> black background testcase

What plugin is this supposed to be using? I apparently don't have it, and the plugin finder service isn't finding anything either.
Comment 99 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-17 20:56:21 PST
The test plugin. You need a build which was built with tests enabled, I'm not sure where you would download one.
Comment 100 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-18 01:13:56 PST
(In reply to comment #96)
> Er, wrong. Actually I see those two problems with no acceleration at all! And
> with D3D9, and with D3D10 (+D2D).

They happen with OOPP disabled too.
Comment 101 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-18 01:18:24 PST
This bug also seems to be independent of OOPP.

In my VM, it seems to happen with D3D10 too, although the symptoms are a little different, I only get the white overlay while I'm dragging the scroll button. Although VMWare is pretty broken with D2D so who knows.
Comment 102 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-18 20:14:40 PST
Actually I'll keep analyzing all these bugs here since I think these bugs are likely to be closely related.
Comment 103 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-18 20:19:22 PST
Created attachment 491757 [details]
Simplified XUL testcase

You'll need to whitelist XUL in Bugzilla (or download the testcase and whitelist file:///) to view this testcase.

This gives us a pretty good indication of what's going on. It looks like the DWM does not get along with child windows where we ask it to extend glass margins into the client area.
Comment 104 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-18 20:54:17 PST
Created attachment 491769 [details]
D3DTest.cpp

Here's a standalone D3D9 test app. It shows pretty clearly that when you use DwmExtendFrameIntoClientArea to extend glass into the client area, child windows over those margins do not get composited correctly by the DWM. Even if we draw opaque content over the margins.

Clicking in the app window moves the child window. Interestingly, it does NOT reproduce this bug as originally reported.
Comment 105 [not reading bugmail] 2010-11-18 21:35:22 PST
(In reply to comment #104)
> Created attachment 491769 [details]
> D3DTest.cpp
> 
> Here's a standalone D3D9 test app. Interestingly, it does NOT
> reproduce this bug as originally reported.

I know it seemed to changed since I first spotted this.

(In reply to comment #89)
> Regarding comment 20, this was originally a problem with D2D, and we don't
> support D2D on D3D9 hardware. However, if people are seeing this using only
> D3D9 layer compositing, we need to block on this.

Yup, that's correct as far as I could tell in early comments.  Before I had forced D2D/DW on and used D3D9 in comment 8, and looked like it was changed by another bug, then Bas said it didn't matter to use D2D by comment 29, and then confirmed it with D3D9 only without D2D, so I updated the bug info.

(In reply to comment #20)
> Unless this can be reproduced with DX10 hardware, this doesn't block at all.

Given the bad support of my Nvidia 7050 device :), I can now also reproduce this bug using Direct3D 10 acceleration given the following:

1) Updated to latest drivers since comment 8.  
2) about:config prefs:
   gfx.direct2d.force-enabled;true
   gfx.font_rendering.directwrite.enabled;true
   layers.prefer-d3d9;false
   layers.accelerate-none;false
   layers.accelerate-all;true

as shown here, its trying to use Direct3D 10:

Adapter Description NVIDIA GeForce 7050 / NVIDIA nForce 610i
Vendor ID 10de
Device ID 07e3
Adapter RAM 256
Adapter Drivers nvd3dum
Driver Version 8.17.12.6099
Driver Date 10-16-2010
Direct2D Enabled true
DirectWrite Enabled true
GPU Accelerated Windows 1/1 Direct3D 10
Comment 106 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-19 00:37:36 PST
I changed my mind again and filed bug 613449 on the problems of drawing windowed plugins over the DWM glass margins.
Comment 107 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-22 17:49:57 PST
I verified via debugging that the white rectangle appears the instant we call SetWindowPos from nsWindow::Move from nsWindow::ConfigureChildren.
Comment 108 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-22 18:05:09 PST
If I pass SWP_NOCOPYBITS to SetWindowPos, the problem does not occur.

So as far as I can tell, there is some kind of driver/platform bug with SetWindowPos moving a child window that has a clip region set on it with SetWindowRgn, that as far as we know only manifests when the parent window is using D3D9. The SetWindowPos call tries to copy the bits of the child window from the old to the new location, but incorrectly paints white outside the clip region in the new location.

So I think a reasonable workaround is to pass SWP_NOCOPYBITS to SetWindowPos when we're using D3D9 and the child's clip region is not covering its entire window.
Comment 109 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-22 18:06:17 PST
(It seems that with SWP_NOCOPYBITS, instead of copying bits, SetWindowPos invalidates the affected areas, so normal repainting will redraw everything.)
Comment 110 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-22 18:29:54 PST
Created attachment 492542 [details] [diff] [review]
fix

Seems to work. I can't think of any better workaround at this point. There will be a slight performance hit when scrolling when plugins are partially visible.
Comment 111 Jim Mathies [:jimm] 2010-11-22 19:01:14 PST
Hmm, we want this for D3D9 only right, so shouldn't that be:

(mLayerManager && mLayerManager->GetBackendType() == LayerManager::LAYERS_D3D9)
Comment 112 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-22 19:20:01 PST
If there's somehow no layer manager yet, I'm being conservative and just doing the SWP_NOCOPYBITS. I doubt that will actually happen in practice.
Comment 113 Jim Mathies [:jimm] 2010-11-23 08:12:57 PST
Comment on attachment 492542 [details] [diff] [review]
fix

(In reply to comment #112)
> If there's somehow no layer manager yet, I'm being conservative and just doing
> the SWP_NOCOPYBITS. I doubt that will actually happen in practice.
Comment 114 Jim Mathies [:jimm] 2010-11-29 11:40:31 PST
*** Bug 615204 has been marked as a duplicate of this bug. ***
Comment 115 Jim Mathies [:jimm] 2010-11-29 17:44:17 PST
*** Bug 615370 has been marked as a duplicate of this bug. ***
Comment 116 Jim Mathies [:jimm] 2010-12-01 19:22:58 PST
*** Bug 615821 has been marked as a duplicate of this bug. ***
Comment 117 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2010-12-05 08:06:17 PST
Comment on attachment 492542 [details] [diff] [review]
fix

Pushed this as http://hg.mozilla.org/mozilla-central/rev/a49bc63fe3d0

I didn't notice until afterwards, but the bug number mentioned in the patch is not this one.
Comment 118 Vlad Alexander 2010-12-07 08:27:10 PST
Is the fix supposed to be in the latest nightly? If so, I can still reproduce the problem. See details in duplicate bug report: Bug 599695
Comment 119 Ed Morley [:emorley] 2010-12-07 08:54:22 PST
I can also replicate using latest nightly:
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre ID:20101207030325
- Flash: 10.1.102.64
Comment 120 Marco Bonardo [::mak] 2010-12-09 05:42:13 PST
I cannot reproduce with the testcases in this bug, but I can reproduce easily scrolling the video at the end of this page http://www.engadget.com/2010/12/07/google-nexus-s-preview/
Comment 121 kolubinowicki 2010-12-13 11:48:28 PST
Created attachment 497282 [details]
Change of bug rendering in toolbars from white rectangle to  "Aero" effect in Windows 7

In past nigtly builds the plugin area in toolbars are usually a white rectangle. From few nigtly build the plugin area in toolbars looks like "aero" effect in windows 7. Look into attachement for more info.   

Windows 7 32bit


Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101212 Firefox/4.0b8pre
Adapter Description ATI MOBILITY RADEON X1300
Vendor ID 1002
Device ID714a
Adapter RAM 128MB 
Drivers atiumdag atiumdva atitmmxx 
Driver Version 8.593.100.0 
Driver Date 2-10-2010 
Direct2D Enabled false 
DirectWrite Enabled false 
GPU Accelerated Windows 1/1 Direct3D 9
Comment 122 amitc97 2010-12-13 14:20:36 PST
(In reply to comment #121)
> Created attachment 497282 [details]
> Change of bug rendering in toolbars from white rectangle to  "Aero" effect in
> Windows 7
> 
> In past nigtly builds the plugin area in toolbars are usually a white
> rectangle. From few nigtly build the plugin area in toolbars looks like "aero"
> effect in windows 7. Look into attachement for more info.   

The same thing with me: I also see the Aero effect instead of the white rectangle on most websites. However, using the previously mentioned video, I still see a white rectangle as was the initial problem.

http://www.engadget.com/2010/12/07/google-nexus-s-preview/
(The video is at the bottom of the post.)
Comment 123 zokocx 2010-12-14 14:26:07 PST
(In reply to comment #120)
> I cannot reproduce with the testcases in this bug, but I can reproduce easily
> scrolling the video at the end of this page
> http://www.engadget.com/2010/12/07/google-nexus-s-preview/

Here is some problem. Even on other sites which have some form of player (youtube etc).
Also here > http://www.bbc.co.uk/news/uk-11989216
Small player is on middle of page and when you scroll up page it leaves white rectangle on firefox gui and also when you scroll down.

OS Windows 7 x64
Default FF skin, doesn't matter if personas are place or not.
                     
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

Graphics
Adapter Description NVIDIA GeForce 7900 GT/GTO
Vendor ID 10de
Device ID 0291
Adapter RAM 512
Adapter Drivers nvd3dumx,nvd3dum
Driver Version 8.17.12.6099
Driver Date 10-16-2010
Direct2D Enabled false
DirectWrite Enabled false
GPU Accelerated Windows 1/1 Direct3D 9
Comment 124 kolubinowicki 2010-12-14 15:48:53 PST
Created attachment 497654 [details]
Plugin content is improperly rendered outside the toolbar area.

Plugin content is also improperly rendered outside the toolbar area. Please check attached video (webm) file for more information.
Comment 125 Ed Morley [:emorley] 2010-12-15 18:48:17 PST
*** Bug 619139 has been marked as a duplicate of this bug. ***
Comment 126 Marco Bonardo [::mak] 2010-12-21 09:35:35 PST
Interesting, I cannot reproduce anymore after latest D3D9 changes from yesterday...
Comment 127 Marco Bonardo [::mak] 2010-12-21 09:40:56 PST
Well, not completely true... something changed but not all.
Now it does not clear anymore the toolbars area, but I still see it clearing the locationbar contents and the tabbar gets messed up (content moves to the right)
Comment 128 Marco Bonardo [::mak] 2010-12-21 09:54:01 PST
Created attachment 499054 [details]
situation after recent d3d9 changes

This is what I see... the tabbar is duplicating content that is on the left, the locationbar is white on the plugin area... but now toolbars are correct.
moving mouse over it fixes the glitches.
Comment 129 kolubinowicki 2010-12-21 12:58:24 PST
Created attachment 499119 [details]
Change of bug rendering. Gecko/20101221 Firefox/4.0b9pre

In addition to comment 128. I can also see the shift of the content from the left side of browser. But toolbars are affected by glitches. 
Check the attached screenshot for more info (pay attention that in title bar, menu button appear twice).
Comment 130 [not reading bugmail] 2010-12-21 19:28:54 PST
I'm still seeing this bug the way I reported it, happens a little less often with Normal window mode, and more often in Maximized mode for me.  I don't see any issues from the past few comments, they look different.

(In reply to comment #124)
> Created attachment 497654 [details]
> Plugin content is improperly rendered outside the toolbar area.
> 
> Plugin content is also improperly rendered outside the toolbar area. Please
> check attached video (webm) file for more information.

hmm, this looks like a webpage trying to create a toolbar on the website (not part of Firefox chrome) but doing similar things, I think this bug might be better spun off, unless Roc disagrees.

(In reply to comment #129)
> Created attachment 499119 [details]
> Change of bug rendering. Gecko/20101221 Firefox/4.0b9pre
> 
> In addition to comment 128. I can also see the shift of the content from the
> left side of browser. But toolbars are affected by glitches. 
> Check the attached screenshot for more info (pay attention that in title bar,
> menu button appear twice).

I don't see this mess at all.
Comment 131 [not reading bugmail] 2010-12-21 19:39:33 PST
(In reply to comment #128)
> Created attachment 499054 [details]
> situation after recent d3d9 changes
> 
> This is what I see... the tabbar is duplicating content that is on the left,
> the locationbar is white on the plugin area... but now toolbars are correct.
> moving mouse over it fixes the glitches.

I don't see the duplicate tabbar mess, but I noticed the rest can happen sometimes, but it doesn't happen consistently using the Fx menu with a persona.
Comment 132 dfghjkjhg 2010-12-23 13:19:02 PST
I am using Windows 7 with "Aero-Design".
With "Aero-Design" I can also see the white rectangle in FF's toolbar when scrolling.

But when I switch to e. g. "Windows 7 BASIS Design" (which means Aero is turned off) the here described bug does not occur any more.

Maybe this informaiton helps for fixing the bug
.
Comment 133 kolubinowicki 2010-12-24 05:14:03 PST
Created attachment 499643 [details]
Glitches Gecko/20101223 Firefox/4.0b9pre

Gecko/20101223 Firefox/4.0b9pre

Check the repeatable bug rendering behaviour on attached screencast:

http://www.youtube.com/watch?v=Vi247LAANLY

>Maximized browser window
(after tab closing, nonclickable 'ghost' tab appear, link in address bar is messed)

>Unmaximized browser window
(shifting of toolbar content in plugin area)

>After using system button 'show desktop' and restoring browser window, plugin area is rendered as glass Aero effect.  

But sometimes the plugin area render as:
-white rectangle
-sometimes the only visible glitch is on the bookmark bar, when favicons are missing but text stay in proper position.
Comment 134 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-27 13:17:43 PST
Created attachment 499886 [details] [diff] [review]
Patch 2: try resetting clip region immediately before and after moving/resizing the plugin window, if we're clipped

I thought this workaround might fix the problem, but it's no good, it causes the plugin to flicker in the chrome area sometimes.
Comment 135 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-27 13:44:20 PST
Created attachment 499895 [details] [diff] [review]
Patch 3: repaint under the moved plugin

This patch might be a decent workaround. It just repaints the area under the plugin when we move a clipped plugin. For people that are seeing this bug, they might still see a flicker of white in the chrome area with this patch, but that's all.

I can't reproduce the problem, so people are going to have to try tryserver builds. A build with this patch will appear at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c.

If this solution doesn't work or isn't acceptable, the only other approach I can think of right now would be to inject a parent window for the plugin window and use that parent window to clip the plugin window to a rectangle. I don't know if that would avoid these driver bugs or not.
Comment 136 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-27 15:40:14 PST
(and even if it works, it would be a bit risky)
Comment 137 [not reading bugmail] 2010-12-27 19:14:31 PST
(In reply to comment #135)
> I can't reproduce the problem, so people are going to have to try tryserver
> builds. A build with this patch will appear at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c.

Well, it flickers more with this patch, that's about the only thing I see is different, but its definitely there :(
Comment 138 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-27 20:10:56 PST
By "flickering" I mean something that draws incorrectly but only for a moment, and is then replaced by the correct content.

When I reproduce this bug in my VM, I see stuff drawing incorrectly and it is not replaced by the correct content until something causes the window to redraw, e.g. by moving the mouse over stuff. Let's call that "persistent damage".

So on trunk, are you seeing flickering or persistent damage? How about with the latest patch?
Comment 139 kolubinowicki 2010-12-28 01:56:02 PST
Created attachment 499999 [details]
Screencast with bug behaviour with tryserver-build (fc2bc1ec371c)

The bug rendering behaviour in latest nigtly trunk or tryserver build is still present as described in comment 133.

Except that in tryserver build, plugin area is repainted with very annoying flickering. Check screencast for more info:

http://www.youtube.com/watch?v=kje7lK01Vlk
Comment 140 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-28 02:04:07 PST
Can you answer the questions in comment #138? I can't really tell from your screencast.
Comment 141 kolubinowicki 2010-12-28 02:44:28 PST
Created attachment 500005 [details]
"flickering" + "persistent damage" tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c

As for reply in comment 138.

In tryserver build I can see both of behaviours called "flickering" + "persistent
damage", please check the attachement.
Comment 142 kolubinowicki 2010-12-28 04:17:29 PST
Created attachment 500015 [details]
Screencast "Persistent damage" Minefield Gecko/20101227 Firefox/4.0b9pre

In nigtly trunk I can see only "persistent damage" behaviour.

The rendering of bug is the same as described in comment 133.
Comment 143 kolubinowicki 2010-12-28 05:57:51 PST
Created attachment 500027 [details]
Screencast of glitches outside the toolbar area tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c

In addition to comment 124

Rendering of plugin glitches still occur outside the toolbar area with tryserver (fc2bc1ec371c) or nigtly (Gecko/20101227 Firefox/4.0b9pre) build. 

Link to site with frame/toolbar: 
http://bit.ly/bzcGpO
Comment 144 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-28 16:33:42 PST
This bug is about glitches appearing in the browser chrome. You don't seem to be seeing that, so your bug is quite likely to be something else.
Comment 145 voracity 2010-12-29 02:39:21 PST
It is a fair bit better with the tryserver build, but not perfect. By that I mean that maybe 4 in every 5 "scroll plugin into chrome" cases repaint properly (albeit with flickering), but 1 in 5 don't.* That is, 1 in 5 times chrome messes up and stays messed up until either mouse over or another scroll event. Also, the latter (scrolling causing a proper repaint) is new behaviour because that never happened before. So this looks close to what's needed.

* These numbers aren't exact. :)
Comment 146 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-29 12:59:52 PST
OK, that's helpful, thanks!

Is the 1 in 5 that don't cause proper repaint any obvious special case? E.g., is it always when a plugin changes from "fully visible" to "partially visible"? Or when it changes from "completely invisible" to "partially visible"?

Supposing we fix that 1 in 5 case, how bad is the flickering?
Comment 147 voracity 2010-12-29 17:45:06 PST
Yes, it only happens the first time the plugin needs to be clipped (i.e. "fully visible" to "partially visible"). It didn't seem that way yesterday, but perhaps I wasn't paying close enough attention then.

The flickering is annoying, certainly, but I think liveable given it doesn't occur everywhere. Each scroll event does not result in the same delay before repaint, so sometimes the flicker is very noticeable and other times it's barely noticeable. Maybe the repaint timing could be refined somehow to minimise the delay before scroll event triggers a repaint? Anyway, I'll attach a screencast.
Comment 148 voracity 2010-12-29 18:03:01 PST
Created attachment 500291 [details]
screencast of plugin overwriting chrome on first scroll and flickering

The first part of the screencast shows the plugin area overwriting chrome persistently the first time the plugin needs clipping, but being repainted on subsequent scroll events. (Also, I first scroll with the mouse wheel, then the keyboard.) The last part of the screencast shows the severity of the flickering, particularly noticeable when scrolling quickly.
Comment 149 [not reading bugmail] 2010-12-29 20:37:51 PST
I find this difficult to describe without a screencast also, so I was going to produce one.  I see the flickering on fc2bc1ec371c, but it refreshes the toolbars quickly, its not always there and its noticeable as noted already.   You get the feeling the plugin doesn't clip inside the content area coordinates right away.  It doesn't happen as noted on non Aero Glass (comment 132) 

Some more weirdness I noticed.  Even if you grab the window border and resize with fc2bc1ec371c, its painting the plugin over top of the content area and outside right and bottom edge beyond the scrollbars and addon bar into the glass area.  Like the plugin is painting to the size of the window border as soon as you move the mouse to resize, but the rest of screen (content area, scrollbars, toolbars) does not until you stop moving.  

I see large black boxes as well being painted for areas around the plugin, but not in the toolbar area, then the content area is painted when you stop resizing the window and looks normal again which is fine for playback but the it make resizing quite ugly.
Comment 150 Alexander Zink 2010-12-30 02:32:08 PST
(In reply to comment #147)

Since re-painting isn't carried out only the first time clipping occurs to an object, could it be that the 'fully visible' status of the object is only updated _after_ the decision about re-painting being required was taken?
At least this would explain the described and documented behaviour.
Comment 151 kolubinowicki 2010-12-30 06:05:39 PST
Created attachment 500333 [details]
Screencast resizing window Gecko/20101229 Firefox/4.0b9pre

(In reply to comment #149)

> 
> I see large black boxes as well being painted for areas around the plugin, but
> not in the toolbar area, then the content area is painted when you stop
> resizing the window and looks normal again which is fine for playback but the
> it make resizing quite ugly.
>

Is that kind of behaviour showed on attached screencast?
Comment 152 Timothy Nikkel (:tnikkel) 2010-12-30 16:48:16 PST
I'm pretty sure this will have no effect, but could people try this try server build to see if there is any difference?
http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-bb109b9e0665/try-w32/firefox-4.0b9pre.en-US.win32.zip
Comment 153 [not reading bugmail] 2010-12-30 17:31:06 PST
Tim, that trybuild seems to be working well for me, I don't see the white rectangle at all with that one.
Comment 154 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-30 17:43:41 PST
That makes sense.

The question, then, is whether that build represents a shippable fix for this bug, or whether we should try to fix the flickering as well.
Comment 155 [not reading bugmail] 2010-12-30 20:38:23 PST
I also don't see the glass rectangle either with that build.

I think I could not quite tell if that build introduced other things besides making the rectangle disappear or not like more slowness in smooth scrolling/UI responsiveness issues, choppier plugin playback or if plugin flickering was present.  I'm leaning toward the possibility of a slight perf hit in that build after comparing it to the trunk a few times.  

(In reply to comment #151)
> Created attachment 500333 [details]
> Is that kind of behaviour showed on attached screencast?

Not sure.  It appears to be showing up on the trunk builds as well aside from the bug at hand and I was thinking about filing a separate bug for it.
Comment 156 kolubinowicki 2010-12-30 22:44:46 PST
(In reply to comment #152)
> I'm pretty sure this will have no effect, but could people try this try server
> build to see if there is any difference?
> http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-bb109b9e0665/try-w32/firefox-4.0b9pre.en-US.win32.zip


With that build I can't reproduce any kind of glitches (as showed in any of attached screencast) in toolbar area. 
Glitches outside the toolbar area are also fixed (attachment 500027 [details]). 
The only remaining issue is showed in attachment 500333 [details] but I think It should move to new bug (as stated in comment 155).
Comment 157 Timothy Nikkel (:tnikkel) 2010-12-30 23:03:59 PST
Created attachment 500483 [details] [diff] [review]
patch 4: always update stored window clip region

I'm not really sure why this fixes it, but Dennis and kolubinowicki said that it fixes it for them. You're welcome to debug it to see why. :)

This originally comes from bug 616884 where we decided to not take the extra code complexity since it seemed like there was no way it could cause a problem.
Comment 158 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-31 01:02:11 PST
+  for (PRUint32 i = 0; i < aRects.Length(); ++i) {
+    region.And(region, aRects[i]);

this should be Or.

The reason this patch helps with this bug is that the call to HasClipRegion in my patch is performed after SetWindowClipRegion(aIntersectWithExisting=PR_TRUE) and before SetWindowClipRegion(aIntersectWithExisting=PR_FALSE). So without your patch, HasClipRegion is only looking at the clip region before the plugin is moved. So if the plugin starts off unclipped and becomes clipped, the extra invalidation will not be performed, even though it should be.
Comment 159 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-31 01:02:38 PST
Comment on attachment 500483 [details] [diff] [review]
patch 4: always update stored window clip region

With Or instead of And.
Comment 160 Timothy Nikkel (:tnikkel) 2010-12-31 01:10:23 PST
(In reply to comment #158)
> this should be Or.

Good catch on the Or.

> The reason this patch helps with this bug is that the call to HasClipRegion in
> my patch is performed after SetWindowClipRegion(aIntersectWithExisting=PR_TRUE)
> and before SetWindowClipRegion(aIntersectWithExisting=PR_FALSE). So without
> your patch, HasClipRegion is only looking at the clip region before the plugin
> is moved. So if the plugin starts off unclipped and becomes clipped, the extra
> invalidation will not be performed, even though it should be.

But the try server build I made only has my patch in it, not any of your patches (unless they landed on m-c), there is no HasClipRegion on m-c (yet?).
Comment 161 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-31 01:48:52 PST
Ah. In that case, I have no idea!
Comment 162 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-31 01:54:35 PST
Is it possible that we paint synchronously inside ConfigureChildren? Maybe during SetWindowPos? surely not!
Comment 163 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-31 01:56:12 PST
But let's take your patch and then see where we are. It definitely can't hurt.
Comment 164 Vlad Alexander 2010-12-31 08:08:30 PST
The trybuild in comment #152 fixes the rendering issue with XStandard plug-in reported in comment #118.
Comment 165 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-12-31 11:07:02 PST
OK, let's get this in!

I would love to know why this fixes the problem but without a machine where we can reproduce it, it's going to be difficult to find out.
Comment 166 Timothy Nikkel (:tnikkel) 2010-12-31 11:59:57 PST
Created attachment 500545 [details] [diff] [review]
patch for checkin - always update stored window clip region

This has passed try server without the And -> Or fix, but if it passes with patently wrong code, the correct code should be good!
Comment 167 Timothy Nikkel (:tnikkel) 2010-12-31 12:01:15 PST
I was going to land this, but apparently Canada is playing a hockey game today, so I can't.
Comment 168 Timothy Nikkel (:tnikkel) 2010-12-31 12:20:42 PST
Changed my mind.
Comment 169 Timothy Nikkel (:tnikkel) 2010-12-31 14:37:54 PST
http://hg.mozilla.org/mozilla-central/rev/39db16b78175

Do we want to leave this open or resolve it fixed?
Comment 170 [not reading bugmail] 2010-12-31 17:25:32 PST
Created attachment 500561 [details]
Sample Paint Error latest patch

Well I'm pretty sure there is a performance hit with it especially during scrolling so scrolling feels choppier.  The other thing I noticed is resizing makes the plugin shift alot.  For example, resize the right border to the right, the plugin moves further to the right and back left in a bouncing motion.
Comment 171 [not reading bugmail] 2010-12-31 17:28:53 PST
It seems scrolling up and down also causing the inverse bouncing of the plugin too.  I'm not sure how I got that paint error in the previous comment, but it landed on that after I taxed scrolling and resizing.
Comment 172 [not reading bugmail] 2010-12-31 17:37:39 PST
Er, that bouncing effect seems to also be on the trunk before the patch.  So I guess its just scrolling performance that is the remaining side effect.
Comment 173 kolubinowicki 2011-01-01 12:46:27 PST
Created attachment 500601 [details]
Screencast overlaying of plugin area over site toolbar. Gecko/20110101 Firefox/4.0b9pre

With today Minefield (Gecko/20110101 Firefox/4.0b9pre) which have (?) patches from attachment 500545 [details] [diff] [review].

I can reproduce overlaying of plugin area over site toolbar. Please check attached screencast.

Could anyone check, if these kind of behavior apply just to computer configuration affected with bug 590568?
	

Link to site
http://bit.ly/f34Ejj
Comment 174 Alice0775 White 2011-01-02 06:22:25 PST
(In reply to comment #173)
> Created attachment 500601 [details]
> Screencast overlaying of plugin area over site toolbar. Gecko/20110101
> Firefox/4.0b9pre
> 
> With today Minefield (Gecko/20110101 Firefox/4.0b9pre) which have (?) patches
> from attachment 500545 [details] [diff] [review].
> 
> I can reproduce overlaying of plugin area over site toolbar. Please check
> attached screencast.
> 
> Could anyone check, if these kind of behavior apply just to computer
> configuration affected with bug 590568?
> 
> 
> Link to site
> http://bit.ly/f34Ejj
The above problem is not related to this bug.
I filed a Bug 622417 .
Comment 175 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-02 19:24:48 PST
If this bug is now fixed and scrolling performance is the only remaining issue, I propose we file a new bug for that.
Comment 176 Brian Carpenter [:geeknik] 2011-01-02 19:43:36 PST
Looks fixed here (my config is in comment #62).
Comment 177 [not reading bugmail] 2011-01-02 23:26:08 PST
(In reply to comment #175)
> If this bug is now fixed and scrolling performance is the only remaining issue,
> I propose we file a new bug for that.

I filed bug 622492 for that.
Comment 178 Marco Bonardo [::mak] 2011-01-03 06:39:35 PST
wfm in current nightly and I was able to reproduce easily before
Comment 179 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-03 13:19:39 PST
Marco: oh really? You're the only developer I know of who could reproduce this! Can you help us understand why Timothy's patch fixed this?

Basically, we need a stack trace for any call to nsWindow::GetWindowClipRegion between w->SetWindowClipRegion(configuration.mClipRegion, PR_TRUE) and w->SetWindowClipRegion(configuration.mClipRegion, PR_FALSE) in nsWindow::nsWindow::ConfigureChildren. That should be pretty easy to get by adding a global variable to track whether you're between those calls, and then setting a conditional breakpoint on that variable. Can you do that?
Comment 180 Ted Mielczarek [:ted.mielczarek] 2011-01-03 17:11:19 PST
I could also reliably reproduce this and it looks fixed for me now.
Comment 181 Timothy Nikkel (:tnikkel) 2011-01-03 18:43:08 PST
Ted, see comment 179 :)
Comment 182 Ted Mielczarek [:ted.mielczarek] 2011-01-04 04:39:21 PST
Yeah, just chiming in given roc's comment. I'll try the debugging thing today.
Comment 183 Marco Bonardo [::mak] 2011-01-04 06:44:10 PST
hm, unless I've done something wrong, with or without the patch it doesn't break for me between those 2 calls (excluded).
Should I try including one of the two setWindowClipRegion calls?
I can do any further debugging with or without the patch if you need it.
Comment 184 Timothy Nikkel (:tnikkel) 2011-01-04 09:23:40 PST
Hmm, the first patch in this bug probably had no effect the first time a plugin gets clipped to something other than its full rect (ie the first time it is scrolled partially out of view) because the window Move call happens between the two SetWindowClipRegion calls and so the mClipRects won't be up to date yet.
Comment 185 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-04 11:20:44 PST
Ah, the first patch was affected! Right. Great.

That explains the slowdown too: NOCOPYBITS makes us repaint the plugin when it moves.
Comment 186 Timothy Nikkel (:tnikkel) 2011-01-04 12:49:18 PST
But my patch would only change the behaviour of your patch the very first time it got partially clipped out, right? So my patch could only produce a slow down on that single paint.
Comment 187 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-04 13:05:58 PST
You'd think so.
Comment 188 dfghjkjhg 2011-01-04 13:13:06 PST
Here's a new phenomenon with the latest build (2011-01-04):
When plugin area is scrolled over FF's tab bar, I can see a white line on FF's tab bar.
But only happens in a dinstinct position of the video - I guess it's the video's tool bar (play, pause etc.) that's somehow "overpainting" FF's tab bar.
--> See screenshots.
Comment 189 dfghjkjhg 2011-01-04 13:13:39 PST
Created attachment 501124 [details]
Before Scrolling
Comment 190 dfghjkjhg 2011-01-04 13:14:06 PST
Created attachment 501125 [details]
After Scrolling
Comment 191 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-01-04 13:19:55 PST
That looks like bug 622733. Please retry on the next nightly build.
Comment 192 Matthias Versen [:Matti] 2011-01-06 06:42:42 PST
*** Bug 610445 has been marked as a duplicate of this bug. ***
Comment 193 Matthias Versen [:Matti] 2011-01-06 06:43:02 PST
*** Bug 601419 has been marked as a duplicate of this bug. ***
Comment 194 dfghjkjhg 2011-01-06 06:51:58 PST
Re comment #191:
Tried with the nightly build from 2011-01-06.
White line still occurs.
Comment 195 Timothy Nikkel (:tnikkel) 2011-01-06 11:06:06 PST
Bug 623463 covers the white line still happening.
Comment 196 [not reading bugmail] 2011-01-23 18:34:05 PST
Anymore idea on the analysis of the patch?
Comment 197 Thales 2011-01-23 19:23:47 PST
(In reply to comment #196)
> Anymore idea on the analysis of the patch?

It's alright at the new firefox beta. At least in my PC. Thanks!
Comment 198 Jim Mathies [:jimm] 2011-01-24 06:25:08 PST
Bug 622328 improves on the haze problem a bit. I'll probably file a follow up for any remaining issues. Although it doesn't look like we'll be able to fix it 100% of the time.

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