Deal with spurious WM_PAINT messages on plugin parent windows

RESOLVED DUPLICATE of bug 1095754

Status

()

defect
RESOLVED DUPLICATE of bug 1095754
5 years ago
5 years ago

People

(Reporter: jimm, Assigned: jimm)

Tracking

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

Firefox Tracking Flags

(e10sm5+)

Details

Follow up for part 8 in bug 669200. There's a dump statement there, so we'll see how bad the problem is. In the original oopp work, this bug caused invalidation problems in flash.
Blocks: 1095930
We have a situation here where Windows is acting oddly. We receive a WM_PAINT on the top level plugin window in the chrome process after the window gets updated. This top level window though is completely obscured by the child window we manage in PluginInstanceChild. If we don't respond to this paint by invalidating the parent window, we get stuck in an infinite loop of paint messages which drags down the parent process.

Currently the code in nsWindow just validates the area and exits in e10s. This produces invalidation problems in flash for the child window. In non-e10s, we dealt with this in an odd way, we sent a sync message to the plugin instance, which called UpdateWindow on the child window and invalidated our window [1].

I'm currently looking for a way to get this same thing working, but from chrome. It would have to be async, but i think that will still work.
  
[1] http://mxr.mozilla.org/mozilla-central/source/dom/plugins/ipc/PluginInstanceChild.cpp#2180
rolling this fix in with other work.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1095754
You need to log in before you can comment on or make changes to this bug.