587508 - [d2d]Web content is drawn on top of plugin area

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Matheus Kerschbaum]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100815 Minefield/4.0b4pre
Build Identifier: 

Similar to bug 579262, but this time it only happens with d2d turned on.

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.youtube.com/watch?v=uKJeLG8-M5I with D2D enabled
2.Scroll to the bottom then back to the top quickly
Actual Results:  
Some web content is drawn on top of the non-active plugin area.

Expected Results:  
Plugin area should not be overlapped by web content.

See https://bugzilla.mozilla.org/show_bug.cgi?id=579262#c29 and https://bugzilla.mozilla.org/show_bug.cgi?id=579262#c42. Should block beta4.

Comment 1

[Alex]

Old issue for me - easy to reproduce.

To avoid scrolling lagg, I use pg up & down keys instead,
the issue is also reproducible then.

HP Mini 311, Win 7

Comment 2

[Steve Scott (pxbugz)]

Attachment: Screenshot to illustrate the corruption

This is the same corruption as seen in Bug 579262, but with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100815 Minefield/4.0b4pre I only see the corruption with D2D/DW on.

Comment 3

[Matheus Kerschbaum]

Attachment: Screenshot

Comment 4

[Bas Schouten (:bas.schouten)]

Roc seems to have done some extensive research on the other bug. Bringing him into the loop, maybe this is something obvious D2D isn't doing.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Maybe D2D isn't clipping out the child window areas correctly?

Comment 6

[Bas Schouten (:bas.schouten)]

(In reply to comment #5)
> Maybe D2D isn't clipping out the child window areas correctly?

It shouldn't be able to draw over a child window, right?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't know. It probably shouldn't, but I'm not sure if Windows guarantees to honour WS_CLIPCHILDREN when drawing with D2D.

Comment 8

[Oskar Ivanić (:icecold)]

Happens to me also. Just like in screenshots provided.

Comment 9

[Myzar]

With today nightly this regressed badly, now scrolling youtube looks like a flickering and repaint mess , see https://bugzilla.mozilla.org/show_bug.cgi?id=589437

Comment 10

[Bas Schouten (:bas.schouten)]

We need to figure out which changeset regressed this.

Comment 11

[Alice0775 White]

(In reply to comment #10)
> We need to figure out which changeset regressed this.
See https://bugzilla.mozilla.org/show_bug.cgi?id=589437#c1

Comment 12

[pal-moz]

dupe of bug 579921 ?

Comment 14

[Bas Schouten (:bas.schouten)]

Attachment: Workaround for problem

So, this appears to occur when a plugin is moved. Retained layer contents of a moved basic layer buffer seems to be copied onto the plugin area, which never gets invalidated. I'm unsure why this happens only right after a move and other than it's all fine. The attached patch seems to work around the issue, it could be refined a little by only invalidating the area that is expected to be overwritten by scrolled content. This obviously isn't a fix, but could function as a workaround for beta 5.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll try to look into this today. We definitely should not ever be drawing into the plugin's widget on Windows!

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 469638 [details] [diff] [review]
Workaround for problem

OK as a workaround, but will hurt performance when scrolling plugins, so it's not a great workaround. If we can come up with something better in the next two days, I hope we can get it into beta5

Comment 19

[Bas Schouten (:bas.schouten)]

Attachment: Workaround for problem v2

This invalidates only the part of the plugin that's required.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think it would be simpler and much clearer to use nsIntRegion here.

nsIntRegion r;
r.Sub(oldpluginarea, newpluginarea);
Invalidate(r.GetBounds());
(You could even invalidate the individual region rects if it mattered; it probably doesn't.)

Comment 21

[Bas Schouten (:bas.schouten)]

Attachment: Workaround for problem v3

Improved largely as per roc's suggestion.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 470082 [details] [diff] [review]
Workaround for problem v3

I don't understand this at all, actually. Why do we need to invalidate the plugin just because it moved? Have you verified that we're drawing into or over the plugin? If so, that's the bug that must be fixed here. If we are drawing into the plugin and then we're trying to fix it up with this patch, I presume the plugin would flicker as it gets scrolled. Does it?

Comment 23

[[not reading bugmail]]

(In reply to comment #3)
> Created attachment 466179 [details]
> Screenshot

Hmm, I don't see this bug, this screenshot looks like the resize plugin bug actually that was fixed under retain layers before.

Comment 24

[Bas Schouten (:bas.schouten)]

(In reply to comment #22)
> Comment on attachment 470082 [details] [diff] [review]
> Workaround for problem v3
> 
> I don't understand this at all, actually. Why do we need to invalidate the
> plugin just because it moved? Have you verified that we're drawing into or over
> the plugin? If so, that's the bug that must be fixed here. If we are drawing
> into the plugin and then we're trying to fix it up with this patch, I presume
> the plugin would flicker as it gets scrolled. Does it?

We seem to be drawing over the plugin. This is a fix up, and it's not a long term solution. It does not make the plugin flicker when scrolled.

Comment 25

[Bas Schouten (:bas.schouten)]

(In reply to comment #23)
> (In reply to comment #3)
> > Created attachment 466179 [details] [details]
> > Screenshot
> 
> Hmm, I don't see this bug, this screenshot looks like the resize plugin bug
> actually that was fixed under retain layers before.

Just load a youtube video, pause it, and then press down/up arrow rapidly to scroll up/down small bits.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bas, you might want to check that PrintWindow is not being called. See bug 579262.

Comment 27

[Bas Schouten (:bas.schouten)]

(In reply to comment #26)
> Bas, you might want to check that PrintWindow is not being called. See bug
> 579262.

If this means nsObjectFrame.cpp:1822. This is not being called.

Comment 28

[Bas Schouten (:bas.schouten)]

This affects plugin usage fairly badly, any suggestions on what to do here rather than the workaround?

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Cleanup SetWindowClipRegion

This helps see what's going on, and it's a good small change in its own right. If the new region is identical to the current region then whether we're intersecting or not, we can ignore it.

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If you apply that patch, then set a breakpoint after the early exit, you can clearly see visual problems occuring even when that breakpoint is not hit. So changing the window region is a non-issue here, the problem occurs even when we don't call SetWindowRgn.

I see the problem most clearly if I scroll down so the plugin is near the top of the window. Then I use the mousewheel to scroll up one unit. Interestingly, the Youtube logo is rendered above the plugin *and* in the plugin window! That is very weird, since the Youtube logo wasn't visible before.

Also interesting, the problem doesn't occur all the time. It almost always occurs after you've scrolled the window a bit. If you just switch tabs to the Youtube tab and then scroll one unit, you usually don't see the problem.

I have a bad feeling that D2D and OOPP is confusing Windows somehow. I need to check if it happens with OOPP disabled, but I can't do that right now.

We might need to try to reproduce this in record+replay. I don't have Windows 7 in a record+replay VM though, someone probably needs to set that up.

Comment 31

[Bas Schouten (:bas.schouten)]

(In reply to comment #29)
> Created attachment 471416 [details] [diff] [review]
> Cleanup SetWindowClipRegion
> 
> This helps see what's going on, and it's a good small change in its own right.
> If the new region is identical to the current region then whether we're
> intersecting or not, we can ignore it.

Just as a small note, this patch causes the memory comparison to occur twice when aIntersectWithExisting is false and the clip region is different change.

Comment 32

[Bas Schouten (:bas.schouten)]

(In reply to comment #30)
> If you apply that patch, then set a breakpoint after the early exit, you can
> clearly see visual problems occuring even when that breakpoint is not hit. So
> changing the window region is a non-issue here, the problem occurs even when we
> don't call SetWindowRgn.
> 
> I see the problem most clearly if I scroll down so the plugin is near the top
> of the window. Then I use the mousewheel to scroll up one unit. Interestingly,
> the Youtube logo is rendered above the plugin *and* in the plugin window! That
> is very weird, since the Youtube logo wasn't visible before.
> 
> Also interesting, the problem doesn't occur all the time. It almost always
> occurs after you've scrolled the window a bit. If you just switch tabs to the
> Youtube tab and then scroll one unit, you usually don't see the problem.
> 
> I have a bad feeling that D2D and OOPP is confusing Windows somehow. I need to
> check if it happens with OOPP disabled, but I can't do that right now.
> 
> We might need to try to reproduce this in record+replay. I don't have Windows 7
> in a record+replay VM though, someone probably needs to set that up.

SetWindowClipRegion is definitely not related, try positioning the plugin in the middle of your screen, and then press the up and down arrows alternating, you can see clearly what appears to be happening there. It looks like when the ThebesLayers are composited in their new position they just get rudely drawn into the area occupied by the plugin window.

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Have you tried logging event.region in nsWindowGfx::OnPaint, to see whether the region is correct?

We explicitly clip to that region in OnPaint, so if the region is correct it's hard to see how we could draw Web page content over the plugin window area there.

Comment 34

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

confirming this also on Windows XP

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That's strange, I can't reproduce this with D2D off, but XP doesn't have D2D.

Comment 36

[redsign]

I see this without D2D when the accelerated layers are activated. Only way to not have this is to deactivate D2D AND accelerated layers. Using a Geforce 8600 GTS here.

Comment 41

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Glitch with Direct2D disabled

I get this glich (screenshot attached) with Direct2D disabled (and get glitches too with Direct2D enabled).

Steps:
 1. Set gfx.direct2d.disabled = true (not necessary, but I thought you'd find it intersting to know this happens not only with Direct2D)
 2. Restart firefox, go to mibbit.com in the first tab,
 3. open a new tab, go to:
  http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.24.pdf
 Using the Adobe PDF Reader plugin.

Result: attached screenshot.

I have windows 7, UA string:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100921 Firefox/4.0b7pre

Comment 42

[Benoit Jacob [:bjacob] (mostly away)]

I forgot to mention: Step 4: go back to the Mibbit tab, and then back to the PDF tab.

Comment 43

[Benoit Jacob [:bjacob] (mostly away)]

Sorry, this seems to be an unrelated issue, filing a new bug.

Comment 44

[Csaba Kozák [:WonderCsabo]]

I have this problem for a long long time. Since 3.5, i guess.

Comment 45

[Benoit Jacob [:bjacob] (mostly away)]

Filed Bug 598754.

Comment 46

[John]

i'm confirm. And i'm don't see the video

Comment 47

[Bas Schouten (:bas.schouten)]

Attachment: Workaround for problem v4

This also works around the problem for non-basic layer managers.

Comment 48

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bas, are you testing this with OOPP? Because it would be surprising if this does anything with OOPP, since there the actual plugin window is a child of 'w' that covers w.

Comment 49

[Jim Mathies [:jimm]]

(In reply to comment #48)
> Bas, are you testing this with OOPP? Because it would be surprising if this
> does anything with OOPP, since there the actual plugin window is a child of 'w'
> that covers w.

I think it would, the invalidate would trigger a paint, and that would get forwarded over -

http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindowGfx.cpp#327

http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginInstanceChild.cpp#1750

Comment 50

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 478099 [details] [diff] [review]
Workaround for problem v4

This needs a big comment explaining that this is a workaround for an unknown bug.

Comment 51

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This might be affected --- perhaps fixed --- by bug 596451.

Comment 52

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oh I guess not, since this is only windowed plugins.

Comment 53

[Bas Schouten (:bas.schouten)]

(In reply to comment #48)
> Bas, are you testing this with OOPP? Because it would be surprising if this
> does anything with OOPP, since there the actual plugin window is a child of 'w'
> that covers w.

I ran/tested it with OOPP to answer the question. Although I'm not sure what causes us to so rudely draw into the plugin area, (considering as you say, it should be clipped out in our drawing), this definitely fixes all issues I was having. Sadly my birch build earlier had a big fail on windows, I resubmitted it. Once it comes back successful I'll land this with the big comment you requested.

Comment 54

[Bas Schouten (:bas.schouten)]

I need this to be blocking beta 7 so we can land the workaround.

Comment 55

[Bas Schouten (:bas.schouten)]

http://hg.mozilla.org/mozilla-central/rev/933f8ff80777

Filed follow-up 599393.

Comment 57

[Chris B.]

Way to go Mozilla!!!

This annoying bug is finally fixed in the latest Minefield build (25-Sept-2010).

Comment 58

[Joachim Otahal]

Indeed fixed, applies to Seamonkey build 2010-09-25 too.

Comment 59

[imradyurrad]

(In reply to comment #57)
> Way to go Mozilla!!!
> 
> This annoying bug is finally fixed in the latest Minefield build
> (25-Sept-2010).

It was fixed for me about 10+ hourly builds ago. And then it reappeared this morning when I updated. =? 

At least it's fixed now.

Comment 63

[Acrodesm]

I can still (unreliably) reproduce this bug on RC2:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

Chance occurrence is between 2-10%, but for day-long YouTube users, this can happen a couple of times per day.

For me, there seems to be an increase in likelihood of the bug occurring, say on http://www.youtube.com/watch?v=vfQq7vmFesQ, if the mouse quickly moves in and out of the plugin area while scrolling when the video is playing.

Comment 64

[Acrodesm]

Attachment: Reproduced example on a different video (web content over plugin area)

Comment 65

[Acrodesm]

Attachment: Creepier version of the bug on a different video (plugin content over web area too)

Both the web content is seen over the plugin area, as well as plugin content seen inside the web page area (!).

Comment 66

[Acrodesm]

Attachment: Bug as on original video

For http://www.youtube.com/watch?v=uKJeLG8-M5I

Comment 67

[George Carstoiu]

Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Everything seems to be working fine - issue no longer present.

acrodesm, do you have other steps to reproduce than the one presented in the Description for reproducing this issue?

Comment 68

[Acrodesm]

(In reply to comment #67)
> Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
> Everything seems to be working fine - issue no longer present.
> 
> acrodesm, do you have other steps to reproduce than the one presented in the
> Description for reproducing this issue?

No, but the frequency of this happening on YouTube jumped to about 30%-50% ever since installing the public release of Firefox 4.0.  Now, it happens by simply scrolling regardless of the location of the mouse.

I can now reliably reproduce it on almost any YouTube video that does not redraw the whole plugin canvas during playback, such as http://www.youtube.com/watch?v=b6oAFlPLGA8 and http://www.youtube.com/watch?v=0XgKmyTg0Qc.  Scrolling up and down less than 20 times on average is usually enough for the bug to appear, regardless of the zoom level.  However, having the page zoomed in more may increase the chance of noticing the bug, due to the canvas having to move a greater distance while scrolling.

This occurs regardless of whether smooth scrolling is enabled, and all extensions have been disabled prior to testing, but to no avail.

The effects of this bug is just like the Java one I reported recently as Bug 640843, except that one seems to be much more easily reproducible by anyone running Windows 7, and a lot more noticeable.

Comment 69

[Acrodesm]

Attachment: Playback control bar artifact

Another possibly easier way to reproduce this on the mentioned type of YouTube videos is to play the video, then drag the vertical scroll bar up and down extremely slowly.  A very small artifact from this bug appears on the bottom left of the red control playback bar (screenshot).

Comment 70

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #68)
> The effects of this bug is just like the Java one I reported recently as Bug
> 640843, except that one seems to be much more easily reproducible by anyone
> running Windows 7, and a lot more noticeable.

Anyone, really? It seems to me that most Windows 7 users are not seeing this anymore.

Please file a new bug and report your about:support video configuration. Thanks!

Comment 72

[ibatterb]

> I can now reliably reproduce it on almost any YouTube video that does not
> redraw the whole plugin canvas during playback, such as
> http://www.youtube.com/watch?v=b6oAFlPLGA8 and
> http://www.youtube.com/watch?v=0XgKmyTg0Qc.  Scrolling up and down less than

I used to see this bug all the time, however I updated my video driver about a month ago and haven't seen it since, and am now unable to reproduce it on the youtube links above.

Currently running ATI Radeon HD 4800 Series with ATI Driver Version 8.970.100.3000, dated 7-3-2012 (not sure if that's 7th March or 3rd July)