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

RESOLVED FIXED

Status

()

defect
--
major
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: matjk7, Assigned: bas.schouten)

Tracking

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

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

()

Attachments

(9 attachments, 3 obsolete attachments)

Reporter

Description

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

Updated

9 years ago
Blocks: 569166
blocking2.0: --- → ?
Version: unspecified → Trunk

Comment 1

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

Comment 3

9 years ago
Posted image Screenshot
Assignee

Comment 4

9 years ago
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?
Assignee

Comment 6

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

Comment 9

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

Comment 10

9 years ago
We need to figure out which changeset regressed this.

Comment 11

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

9 years ago
dupe of bug 579921 ?
Duplicate of this bug: 590856
Assignee

Comment 14

9 years ago
Posted 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!
Assignee

Updated

9 years ago
Duplicate of this bug: 591209
Assignee

Updated

9 years ago
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+
Assignee

Comment 19

9 years ago
Posted 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.)
Assignee

Comment 21

9 years ago
Posted 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.
Assignee

Comment 24

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

Comment 25

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

Comment 27

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

Comment 28

9 years ago
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.
Assignee

Comment 31

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

Comment 32

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

Updated

9 years ago
Attachment #471416 - Flags: review?(jmathies) → review+
That's strange, I can't reproduce this with D2D off, but XP doesn't have D2D.

Comment 36

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

Updated

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

Comment 46

9 years ago
i'm confirm. And i'm don't see the video
Assignee

Comment 47

9 years ago
This also works around the problem for non-basic layer managers.
Attachment #478099 - Flags: review?(roc)
Assignee

Updated

9 years ago
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.
Assignee

Comment 53

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

Comment 54

9 years ago
I need this to be blocking beta 7 so we can land the workaround.
blocking2.0: betaN+ → ?
blocking2.0: ? → beta7+
Assignee

Comment 55

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

Filed follow-up 599393.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 598332

Comment 57

9 years ago
Way to go Mozilla!!!

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

Comment 58

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

Comment 59

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

Updated

9 years ago
Duplicate of this bug: 601453
Duplicate of this bug: 601486
Duplicate of this bug: 587442

Updated

8 years ago
Depends on: 636686

Comment 63

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

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

Comment 67

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

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

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

Updated

8 years ago
Duplicate of this bug: 587300

Comment 72

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