[OOPP] Tearing/Repainting issues with flash videos, their controls and other page content during/after scrolling

VERIFIED FIXED

Status

()

VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: u88484, Assigned: jimm)

Tracking

({regression, testcase, verified1.9.2})

Trunk
x86_64
Windows 7
regression, testcase, verified1.9.2
Points:
---

Firefox Tracking Flags

(blocking1.9.2 .4+, status1.9.2 .4-fixed)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

9 years ago
Created attachment 417941 [details]
Screenshot

There are a lot of tearing/repainting issues with flash videos, their controls and other page content during/after scrolling.  See attachment for one instance I captured.  Other times the controls disappear and I have to scroll up or down with the video out of view for the controls to reappear.

Comment 1

9 years ago
Jim, can you take a look? This is probably similar to bug 518506 (GTK), but I'm not certain of that.
Assignee: nobody → jmathies
Component: IPC → Plug-ins
QA Contact: ipc → plugins

Updated

9 years ago
Blocks: 478976
(Assignee)

Comment 2

9 years ago
Some sort of windowed flash invalidation problem. Might be ipc, might just be related to some of the child scrolling problems we've had recently. Will see if I can track it down.

Comment 3

9 years ago
This may be bug 534561, which roc landed last night. Can somebody retest with today's m-c nightly?
(Reporter)

Comment 4

9 years ago
Created attachment 418178 [details]
Still repainting and tearing issues

Using the 20091217 trunk nightly
I saw this pretty badly on a page today, so I made a testcase:
http://mavra.perilith.com/~luser/flash-redraw.html

That page contains a 1200px high red div followed by a 200px high green flash object. The onload simply scrolls the <embed> into view (in a setTimeout, which seems to be important).

If you scroll back to the top of the page and then scroll down using the keyboard or scrollbar, you can see the correct rendering.

The underlying issue here seems to be that the plugin window is being scrolled to the wrong place. If you load this testcase, then right click on the bottom of the red area (which should be the div), you get the flash context menu.

I didn't test this on Linux yet, only Windows.
Keywords: testcase
I tested on Linux and this doesn't show up. Appears to be Windows-only.

For completeness, I also flipped the plugin IPC pref and verified that this doesn't happen on Windows with in-process plugins.

Also, my conclusion in the previous comment was flawed. The plugin window appears to be in the correct spot, it's just not redrawing the area that it occupies, so it's still red from displaying the div that was previously there.
Seems to be Flash-specific, I can't reproduce with the same testcase with the test plugin swapped in for the Flash object:
http://mavra.perilith.com/~luser/plugin-redraw.html
Also of note, I can't reproduce this on a self-built Win32 build from today (Built with VC9, no PGO)
(Assignee)

Comment 9

9 years ago
Still there in an m-c build from today. Appears it's just windowed, windowless doesn't seem to have a problem.
(Assignee)

Comment 10

9 years ago
Created attachment 421566 [details]
simple test case
Jim: it's nearly 100% reproducible on nightlies in my testcase in comment 5.
Seems scrolling/tearing is either paint/invalidate issues or it seems to be position of the plugin is incorrect, would bz's info from bug 545514 comment 16 apply at all here?  He mentioned a trick in reference to the new plugin-ui positioned incorrectly also so it should display properly in the plugin area.
I'm pretty sure that the plugin is located correctly, just not drawing correctly. Using my testcase from comment 5, if you right click where the plugin should be, even though it's not drawn in green, you still get the flash context menu.
I noticed the biggest problem with this when the plugin goes in and out (scrolled in and out) of the visible window area and is still partially visible.
Maybe we should have roc take a look at this?
(Assignee)

Comment 16

9 years ago
I'm working on this this week actually.
(Assignee)

Comment 17

9 years ago
Created attachment 435956 [details] [diff] [review]
fix

grab the invalidated area from the parent, and set it on the child before painting.
Attachment #435956 - Flags: review?(roc)
I don't really know the PluginInstanceChild code. Why is this needed? Are we sure that mPluginWindowHWND is at 0,0 in the parent?

BTW I'm a bit sad that this new plugin code is gather platform #ifdefs :-(.
(Assignee)

Comment 19

9 years ago
(In reply to comment #18)
> I don't really know the PluginInstanceChild code. Why is this needed? Are we
> sure that mPluginWindowHWND is at 0,0 in the parent?

We invalidate the parts of the gecko plugin window (parent) in widget during scrolling, which sits underneath the OOPP plugin window created by PluginInstanceChild. The two have the same size, and the same position. To avoid race conditions with paints though, we disconnected the two by removing the WS_CLIPCHILDREN style from the parent, so paints don't cascade down to the child.

http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsPluginNativeWindowWin.cpp#549

When the paint on the parent comes to widget, we forward it across to this call in the child.

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

I checked the values of the GetUpdateRect and they matched up perfectly to the areas that needed repainting for the scroll. 

> 
> BTW I'm a bit sad that this new plugin code is gather platform #ifdefs :-(.

Yeah, that's the way it came together. Most of the oopp plugin code though is cross but the instances ended up with heavy ifdef'ing. At some point we'll probably need to split them up into separate files.
(Assignee)

Comment 20

9 years ago
http://hg.mozilla.org/mozilla-central/rev/3549ea4a9bd9
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 21

9 years ago
Verified fixed using hourly Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100405 Minefield/3.7a4pre

cset: 67f4c546d403

Is there a bug for the video jumping around while scrolling?  I thought this fix would have also fixed that.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 22

9 years ago
(In reply to comment #21)
> Is there a bug for the video jumping around while scrolling?  I thought this
> fix would have also fixed that.

Uh ohh. Kurt, can you provide more detail on what you're seeing or STR?
(Assignee)

Comment 23

9 years ago
(In reply to comment #22)
> (In reply to comment #21)
> > Is there a bug for the video jumping around while scrolling?  I thought this
> > fix would have also fixed that.
> 
> Uh ohh. Kurt, can you provide more detail on what you're seeing or STR?

bug 557533 was filed.
(Assignee)

Updated

9 years ago
Attachment #435956 - Flags: approval1.9.2.4?

Updated

9 years ago
blocking1.9.2: --- → ?
Comment on attachment 435956 [details] [diff] [review]
fix

a=beltzner for 1.9.2.4
Attachment #435956 - Flags: approval1.9.2.4? → approval1.9.2.4+
blocking1.9.2: ? → .4+
Keywords: checkin-needed
Keywords: checkin-needed
Verified fixed for 1.9.2 in the nightly build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4pre) Gecko/20100412 Namoroka/3.6.4pre (.NET CLR 3.5.30729)
Keywords: verified1.9.2

Comment 27

6 years ago
It's seems the fix still haven't made its way into production. I'm using Firefox 13.0.1 on Windows 7 x64 and still experiencing this issue. When can we expect the fix to be included into the release?

Comment 28

6 years ago
Created attachment 640535 [details]
Tearing after scroll

Tearing of flash image after scrolling on page http://www.ixbt.com/cpu/intel-ci5i7-ivy.shtml.
Firefox version: 13.0.1
Flash player plugin version: 11.3.300.262
OS: Windows 7 Professional x64

Comment 29

6 years ago
The new issue is caused by Flash 11.3 and is covered by bug 762948.
You need to log in before you can comment on or make changes to this bug.