The default bug view has changed. See this FAQ.

[D3D9] plugin area is shown in toolbars when scrolled off the screen as a rectangle about the size of plugin area being scrolled

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: [not reading bugmail], Assigned: roc)

Tracking

(Depends on: 1 bug, {regression})

Trunk
All
Windows 7
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [Input], URL)

Attachments

(28 attachments, 1 obsolete attachment)

557.93 KB, image/png
Details
175.46 KB, image/jpeg
Details
87 bytes, text/html
Details
198 bytes, text/html
Details
131 bytes, text/html
Details
11.64 KB, image/png
Details
52.29 KB, image/png
Details
542 bytes, application/vnd.mozilla.xul+xml
Details
7.57 KB, text/plain
Details
fix
1.88 KB, patch
jimm
: review+
Details | Diff | Splinter Review
227.32 KB, image/png
Details
1008.06 KB, video/webm
Details
33.96 KB, image/jpeg
Details
428.05 KB, image/png
Details
175 bytes, text/html
Details
6.14 KB, patch
Details | Diff | Splinter Review
4.87 KB, patch
Details | Diff | Splinter Review
175 bytes, text/html
Details
784.51 KB, video/webm
Details
1.33 MB, video/webm
Details
1.46 MB, video/webm
Details
1.35 MB, video/webm
Details
416.74 KB, video/webm
Details
3.66 KB, patch
tnikkel
: review+
Details | Diff | Splinter Review
80.11 KB, image/jpeg
Details
784.60 KB, video/webm
Details
84.27 KB, image/jpeg
Details
95.21 KB, image/jpeg
Details
(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Blocks: 549116
Component: General → Graphics
Product: Firefox → Core
Version: unspecified → Trunk
(Reporter)

Comment 1

7 years ago
Created attachment 469081 [details]
plugin area scrolled off content area shown as rectangle in chrome area
(Reporter)

Updated

7 years ago
Blocks: 564991
(Reporter)

Updated

7 years ago
Keywords: regression
blocking2.0: --- → beta5+
QA Contact: general → thebes
This is blocking B5+ and still marked Uncomfirmed? Setting status to New since I can confirm this behavior.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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?
(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?
(Reporter)

Comment 5

7 years ago
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.
(Reporter)

Comment 6

7 years ago
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.
(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.
(Reporter)

Comment 8

7 years ago
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

7 years ago
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
(Reporter)

Comment 10

7 years ago
Updated URL with YouTube screencast of this bug.
I believe that Rob wanted to look into this.
Assignee: nobody → roc
(Reporter)

Comment 12

7 years ago
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.
(Reporter)

Comment 13

7 years ago
(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.
(Reporter)

Comment 14

7 years ago
Filed bug 591570 for the new behavior and didn't know if we should morph this bug.
(Reporter)

Comment 15

7 years ago
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
(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.
(Reporter)

Comment 17

7 years ago
This bug is still reproduceable in the nightly.
(In reply to comment #17)
> This bug is still reproduceable in the nightly.

Neat. Might be a D3D9 issue I suppose.

Comment 19

7 years ago
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.
Unless this can be reproduced with DX10 hardware, this doesn't block at all.
blocking2.0: beta5+ → -
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.
(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.
(Reporter)

Comment 23

7 years ago
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.
Summary: [D2D] plugin area shown in toolbars when scrolled off the screen as a blue/white box → [D2D] plugin area is shown in toolbars when scrolled off the screen as a rectangle about the size of plugin area being scrolled

Comment 24

7 years ago
Should bug 585912 or this one be duped to each other?

Comment 25

7 years ago
Since D2D is on by default now, shouldn't this be blocking?
Not unless this can be reproduced with DX10 hardware. See comment 20.

Comment 27

7 years ago
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

7 years ago
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...
This is being reported by people with no D2D, but just D3D9.
Summary: [D2D] 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 rectangle about the size of plugin area being scrolled

Comment 30

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
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)
I wonder if this and bug 593703 are the same?
(Reporter)

Comment 35

7 years ago
(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

7 years ago
yes it is the same, could we move to the other bug ?

Comment 37

7 years ago
Time to mark this bug as dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=593703 ?

Comment 38

7 years ago
Other way around.

Comment 39

7 years ago
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

7 years ago
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)
(Reporter)

Comment 41

7 years ago
(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.
(Reporter)

Comment 42

7 years ago
(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

7 years ago
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

7 years ago
duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=593839 ?

Comment 45

7 years ago
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

7 years ago
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
That's odd, I thought this would've been fixed by all the work we've done on plugins.

Comment 48

7 years ago
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?
Hrm, well, mainly I wish I had a clue about what's going on. I can't reproduce it anywhere either.

Comment 50

7 years ago
Reproducible here: http://www.bbc.co.uk/news/uk-politics-11728546

Play the vid and scroll up.

(b8 pre Win32 20101111)
(Reporter)

Comment 51

7 years ago
So there must be some code in D3D9 that is different then the D3D10 path here, no?
Comment 50's video link works fine for me just fine with D3D10.

Comment 53

7 years ago
Ok...now I'm going to show my ignorance (I'm just semi-technical trying to help). What is D3D9 / D3D10...?

Comment 54

7 years ago
(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

7 years ago
(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

7 years ago
(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..?
Do you have a Dx10 capable graphics card?

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

Comment 58

7 years ago
(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?
Doesn't matter, 6600 is not a Dx10 capable card, that's why you use D3D9.
(Reporter)

Comment 60

7 years ago
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

7 years ago
(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...
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.
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.

Updated

7 years ago
Duplicate of this bug: 599695
(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.
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

Updated

7 years ago
Duplicate of this bug: 612000

Comment 68

7 years ago
I think the following bug is the same as the following one:

https://bugzilla.mozilla.org/show_bug.cgi?id=608533

Comment 69

7 years ago
(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

7 years ago
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
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

7 years ago
Sorry , was my fault , i was posting from the computer with a dx10 card , it still NOT FIXED
(Reporter)

Updated

7 years ago
Attachment #470158 - Attachment description: [D2D] Another version of the plugin resized → [D3D9] Another version of the plugin resized
(Reporter)

Updated

7 years ago
Duplicate of this bug: 597955
(Reporter)

Updated

7 years ago
Duplicate of this bug: 608533
(Reporter)

Comment 75

7 years ago
(In reply to comment #44)
> duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=593839 ?

Thats a different bug.

Comment 76

7 years ago
Still showing here at BBC News as before. 20101114. D3D9.
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

7 years ago
In my experiments this only happens when "Use hardware
acceleration when available" is checked. If you disable this option then objects
scroll as expected.
(Reporter)

Comment 79

7 years ago
(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

7 years ago
(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).
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
Whiteboard: [Input]

Comment 82

7 years ago
(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?
(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.
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
Duplicate of this bug: 612061
Should this block beta?
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.
blocking2.0: - → ?

Comment 88

7 years ago
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.
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.
blocking2.0: ? → betaN+
(Reporter)

Comment 90

7 years ago
(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.
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%.
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.
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.
Created attachment 491440 [details]
Screenshot

This shows the highlight effect. Note how it doesn't happen above the top edge of the plugin window.
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.
Er, wrong. Actually I see those two problems with no acceleration at all! And with D3D9, and with D3D10 (+D2D).
I'll treat those as unrelated and spin off a new bug for them.
(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.
The test plugin. You need a build which was built with tests enabled, I'm not sure where you would download one.
(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.
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.
Actually I'll keep analyzing all these bugs here since I think these bugs are likely to be closely related.
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.
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.
(Reporter)

Comment 105

6 years ago
(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
I changed my mind again and filed bug 613449 on the problems of drawing windowed plugins over the DWM glass margins.
Depends on: 613449
I verified via debugging that the white rectangle appears the instant we call SetWindowPos from nsWindow::Move from nsWindow::ConfigureChildren.
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.
(It seems that with SWP_NOCOPYBITS, instead of copying bits, SetWindowPos invalidates the affected areas, so normal repainting will redraw everything.)
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.
Attachment #492542 - Flags: review?(jmathies)
Whiteboard: [Input] → [Input][needs review]
Hmm, we want this for D3D9 only right, so shouldn't that be:

(mLayerManager && mLayerManager->GetBackendType() == LayerManager::LAYERS_D3D9)
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 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.
Attachment #492542 - Flags: review?(jmathies) → review+
Whiteboard: [Input][needs review] → [Input][needs landing]

Updated

6 years ago
Duplicate of this bug: 615204

Updated

6 years ago
Duplicate of this bug: 615370

Updated

6 years ago
Duplicate of this bug: 615821
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.

Updated

6 years ago
Whiteboard: [Input][needs landing] → [Input]
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 118

6 years ago
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
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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/
(Reporter)

Updated

6 years ago
Blocks: 581212

Comment 121

6 years ago
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

6 years ago
(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

6 years ago
(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

6 years ago
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.
Duplicate of this bug: 619139
Interesting, I cannot reproduce anymore after latest D3D9 changes from yesterday...
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)
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

6 years ago
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).
(Reporter)

Comment 130

6 years ago
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.
(Reporter)

Comment 131

6 years ago
(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

6 years ago
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

6 years ago
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.
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.
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.
(and even if it works, it would be a bit risky)
(Reporter)

Comment 137

6 years ago
(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 :(
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

6 years ago
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
Can you answer the questions in comment #138? I can't really tell from your screencast.

Comment 141

6 years ago
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

6 years ago
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

6 years ago
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
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

6 years ago
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. :)
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

6 years ago
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

6 years ago
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.
(Reporter)

Comment 149

6 years ago
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

6 years ago
(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

6 years ago
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?
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
(Reporter)

Comment 153

6 years ago
Tim, that trybuild seems to be working well for me, I don't see the white rectangle at all with that one.
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.
(Reporter)

Comment 155

6 years ago
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

6 years ago
(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).
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.
Attachment #500483 - Flags: review?(roc)
+  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 on attachment 500483 [details] [diff] [review]
patch 4: always update stored window clip region

With Or instead of And.
Attachment #500483 - Flags: review?(roc) → review+
(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?).
Ah. In that case, I have no idea!
Is it possible that we paint synchronously inside ConfigureChildren? Maybe during SetWindowPos? surely not!
But let's take your patch and then see where we are. It definitely can't hurt.

Comment 164

6 years ago
The trybuild in comment #152 fixes the rendering issue with XStandard plug-in reported in comment #118.
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.
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!
Attachment #500545 - Flags: review+
Attachment #500483 - Attachment is obsolete: true
I was going to land this, but apparently Canada is playing a hockey game today, so I can't.
Keywords: checkin-needed
Whiteboard: [Input] → [Input][needs landing]
Changed my mind.
Keywords: checkin-needed
Whiteboard: [Input][needs landing] → [Input]
http://hg.mozilla.org/mozilla-central/rev/39db16b78175

Do we want to leave this open or resolve it fixed?
(Reporter)

Comment 170

6 years ago
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.
(Reporter)

Comment 171

6 years ago
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.
(Reporter)

Comment 172

6 years ago
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

6 years ago
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

6 years ago
(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 .
If this bug is now fixed and scrolling performance is the only remaining issue, I propose we file a new bug for that.
Looks fixed here (my config is in comment #62).
(Reporter)

Comment 177

6 years ago
(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.
wfm in current nightly and I was able to reproduce easily before
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
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?
Depends on: 622492
I could also reliably reproduce this and it looks fixed for me now.
Ted, see comment 179 :)
Yeah, just chiming in given roc's comment. I'll try the debugging thing today.
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.
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.
Ah, the first patch was affected! Right. Great.

That explains the slowdown too: NOCOPYBITS makes us repaint the plugin when it moves.
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.
You'd think so.

Comment 188

6 years ago
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

6 years ago
Created attachment 501124 [details]
Before Scrolling

Comment 190

6 years ago
Created attachment 501125 [details]
After Scrolling
That looks like bug 622733. Please retry on the next nightly build.
Duplicate of this bug: 610445
Duplicate of this bug: 601419

Comment 194

6 years ago
Re comment #191:
Tried with the nightly build from 2011-01-06.
White line still occurs.
Bug 623463 covers the white line still happening.
(Reporter)

Comment 196

6 years ago
Anymore idea on the analysis of the patch?

Comment 197

6 years ago
(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!
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.
You need to log in before you can comment on or make changes to this bug.