Closed Bug 587508 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: Graphics, defect)

All
Windows 7
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: matjk7, Assigned: bas.schouten)

References

()

Details

Attachments

(9 files, 3 obsolete files)

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.
Blocks: 569166
blocking2.0: --- → ?
Version: unspecified → Trunk
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
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.
Attached image Screenshot
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.
Maybe D2D isn't clipping out the child window areas correctly?
(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?
I don't know. It probably shouldn't, but I'm not sure if Windows guarantees to honour WS_CLIPCHILDREN when drawing with D2D.
blocking2.0: ? → betaN+
Happens to me also. Just like in screenshots provided.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
We need to figure out which changeset regressed this.
(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
dupe of bug 579921 ?
Duplicate of this bug: 590856
Attached patch Workaround for problem (obsolete) — Splinter Review
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.
Assignee: nobody → bas.schouten
Status: NEW → ASSIGNED
Attachment #469638 - Flags: feedback?(roc)
I'll try to look into this today. We definitely should not ever be drawing into the plugin's widget on Windows!
Duplicate of this bug: 591209
Duplicate of this bug: 589410
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
Attachment #469638 - Flags: feedback?(roc) → feedback+
Attached patch Workaround for problem v2 (obsolete) — Splinter Review
This invalidates only the part of the plugin that's required.
Attachment #469638 - Attachment is obsolete: true
Attachment #470028 - Flags: review?(roc)
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.)
Attached patch Workaround for problem v3 (obsolete) — Splinter Review
Improved largely as per roc's suggestion.
Attachment #470028 - Attachment is obsolete: true
Attachment #470082 - Flags: review?(roc)
Attachment #470028 - Flags: review?(roc)
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?
(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.
(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.
(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.
Bas, you might want to check that PrintWindow is not being called. See bug 579262.
(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.
This affects plugin usage fairly badly, any suggestions on what to do here rather than the workaround?
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.
Attachment #471416 - Flags: review?(jmathies)
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.
(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.
(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.
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.
Attachment #471416 - Flags: review?(jmathies) → review+
That's strange, I can't reproduce this with D2D off, but XP doesn't have D2D.
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.
Duplicate of this bug: 595164
Duplicate of this bug: 579921
Duplicate of this bug: 594216
Duplicate of this bug: 596550
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
I forgot to mention: Step 4: go back to the Mibbit tab, and then back to the PDF tab.
Sorry, this seems to be an unrelated issue, filing a new bug.
I have this problem for a long long time. Since 3.5, i guess.
i'm confirm. And i'm don't see the video
This also works around the problem for non-basic layer managers.
Attachment #478099 - Flags: review?(roc)
Attachment #470082 - Attachment is obsolete: true
Attachment #470082 - Flags: review?(roc)
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.
(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 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.
Attachment #478099 - Flags: review?(roc) → review+
This might be affected --- perhaps fixed --- by bug 596451.
Oh I guess not, since this is only windowed plugins.
(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.
I need this to be blocking beta 7 so we can land the workaround.
blocking2.0: betaN+ → ?
blocking2.0: ? → beta7+
http://hg.mozilla.org/mozilla-central/rev/933f8ff80777

Filed follow-up 599393.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Duplicate of this bug: 598332
Way to go Mozilla!!!

This annoying bug is finally fixed in the latest Minefield build (25-Sept-2010).
Indeed fixed, applies to Seamonkey build 2010-09-25 too.
(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.
Duplicate of this bug: 601453
Duplicate of this bug: 601486
Duplicate of this bug: 587442
Depends on: 636686
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.
Both the web content is seen over the plugin area, as well as plugin content seen inside the web page area (!).
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?
(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.
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).
(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!
Duplicate of this bug: 587300
> 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)
You need to log in before you can comment on or make changes to this bug.