526797 - painting issues with windowless Flash plugin while scrolling or with multiple animations

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Karl Tomlinson (:karlt)]

painting issues with windowless Flash plugin while scrolling

STR:
1) View a page using Flash with wmode!=window e.g. http://www.miniusa.com/
2) Make the viewport small enough to enable scrolling.
3) Scroll around

Results:
Plugin paints the wrong portions of its content.

Problem exists on 1.9.2.
Regression from 1.9.1.

Comment 1

[Johnny Stenback (:jst)]

Karl, would you be able to look into this? If not, please reassign appropriately.

Comment 2

[Karl Tomlinson (:karlt)]

I would but I'm pressed for time on other 1.9.2 issues.
Could someone find the regression-window, please?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I will check.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Regression started between the builds 09100603 and 09100703:

Pass: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fab82463c585
Fail: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/491684dbfd7f

Checkins: http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=fab82463c585&tochange=491684dbfd7f

There are a couple of interesting fixes in that range. I should try a trunk build to narrow it down a bit more because I don't have a build environment on Linux.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

On trunk it regressed between 09100103 and 09100206:

Checkins:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=51710e0ba8a3&tochange=a80414164888

Possible candidates are bug 510856, bug 513082, bug 508495, and bug 508945.

Comment 6

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

Changeset b540248e3163 seems to be the one that caused the regression.

Comment 7

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

Attachment: testcase

This testcase shows a bug in windowless Flash on X going at least as far back as Firefox 3.5. If you load it up and then drag a window over it, you see various kinds of bogus repainting.

This seems to be causing the problem reported in this bug. This bug appears to be a regression only because we started being smarter about limiting areas we repaint, which means we trigger this Flash bug more often.

Comment 8

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

The testcase seems to work fine on Windows and Mac, so I think it's a problem with Flash's X windowless support.

CCing msintov, I think we need to kick this over to Adobe for further analysis.

I think we should reexamine blocking status. We could work around it, but I'm reluctant to do that.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Roc, I don't see any problems in drawing the content on Windows and OS X when using the testcase. It's only present on Linux. Do we need another regression range?

Comment 10

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

Thanks for confirming that it's Linux-only.

I don't think we need another regression range. Most likely this bug has been present ever since Flash implemented windowless mode for X.

Comment 11

[Mike Melanson]

I can't reproduce this issue on Linux. I am using the latest public Flash Player (10.0.r32.018) and I have tried the latest Firefox 3.0.x and 3.5.x browsers.

Comment 12

[Karl Tomlinson (:karlt)]

Thanks for looking at this, Mike.  For the testcase in comment 7, you may well need to switch off compositing by the window manager.

Comment 13

[Mike Melanson]

This is in a VM. No compositing or advanced graphical features in play.

Actually, I do see momentary bits of strange repainting when hovering another window over a windowless SWF. But the SWF is quickly repainted when I stop moving the window. Is that what you are referring to?

Comment 14

[Karl Tomlinson (:karlt)]

Yes, the strange repainting after partial covering of the window is the issue.  I don't see it being repainted when I stop moving the window.  It would be more obvious when the video is not playing.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think this blocks, based on comment 8, comment 10 and comment 11

Comment 16

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

Yes, if the video is playing it will usually repaint itself correctly. But with the video not playing, the bug should be obvious.

Comment 17

[Mike Melanson]

Reproduced. We're tracking this internally at Adobe with issue 2482349.

Comment 18

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

Great, thanks!

Comment 19

[Karl Tomlinson (:karlt)]

I'm seeing similar issues related to the UPS Flash ad here
http://www.marketwatch.com/story/eric-schmidt-google-and-privacy-2009-12-11
not when scrolling, just from invalidations from the plugin, I assume.
Firefox trunk build from da011e555c7a, Shockwave Flash 10.0 r32.

Hopefully it's the same issue, though the strange thing here is that even some content outside the plugin ends up drawn in slightly the wrong place.

Comment 20

[Carsten Book [:Tomcat]]

(In reply to comment #19)
> I'm seeing similar issues related to the UPS Flash ad here
> http://www.marketwatch.com/story/eric-schmidt-google-and-privacy-2009-12-11
> not when scrolling, just from invalidations from the plugin, I assume.
> Firefox trunk build from da011e555c7a, Shockwave Flash 10.0 r32.
> 
> Hopefully it's the same issue, though the strange thing here is that even some
> content outside the plugin ends up drawn in slightly the wrong place.

hm or maybe we should spin off this into a new bug :)

Comment 21

[Karl Tomlinson (:karlt)]

(In reply to comment #19)
> Hopefully it's the same issue, though the strange thing here is that even some
> content outside the plugin ends up drawn in slightly the wrong place.

That content was actually another windowless plugin.
This bug shows up when there are multiple animations in a page.

Comment 22

[Karl Tomlinson (:karlt)]

Attachment: animation testcase

Like attachment 412126 [details], this testcase also causes the x and y coordinates of the GraphicsExpose event to be (sometimes) non-zero with Gecko 1.9.2.

Comment 24

[Karl Tomlinson (:karlt)]

Attachment: semi-workaround: move expose event origin when possible

Moving the expose event origin either to 0,0 or to the origin of the plugin rect seems to workaround this.  This patch chooses the plugin rect.

This avoids the problems in attachment 419372 [details], on http://www.louvre.fr/, and scrolling on http://www.miniusa.com/.

It doesn't seem right to request drawing outside the clip rect though so this doesn't fix the problem in attachment.cgi 412126, which existed with older Gecko.

Comment 25

[Karl Tomlinson (:karlt)]

Comment on attachment 419373 [details] [diff] [review]
semi-workaround: move expose event origin when possible

BTW, clipping expose event rectangles to the clip rect seems to have been reverted accidentally in bug 422221.

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

Roc: I initially denied blocking status here; should we reconsider based on the duplicate report? Is the patch here safe for mozilla1.9.2?

Comment 27

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

Patch is safe. We should take it on 1.9.2 IMHO

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

Marked as blocking. Karl - please land on 1.9.2.

Comment 29

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/711e70540270
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/626297fc4959

Also added a mochitest for clipping expose event rectangles (bug 445707).
I haven't added an automated test for this bug.  I'm guessing we won't need the workaround by the time we do the next release.

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Another testcase, where the problems are really obvious (especially when hovering over the list of states):
http://articles.moneycentral.msn.com/Taxes/best-and-worst-taxes-by-state.aspx