557823 - Windowed plugins don't fire NS_AFTERPAINT ("MozAfterPaint") events after rendering

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Jim Mathies [:jimm]]

Spin off from bug 313462. There are a couple issues here -

1) Various platform specific implementations of nsPluginNativeWindow often know about paints but fail to fire off an NS_AFTERPAINT event. 

I did a little experimenting on this by firing the event off on windows after a WM_PAINT event is handled by the plugin. Unfortunately the event ended up getting dumped in nsEventStateManager's PreHandleEvent. Looks like pres content fires this off normally and tracks the invalidate rects that need to sent with the event. Still need to do some investigating to figure out how we can fire this off from the plugin content.

2) Flash on windows doesn't use WM_PAINT to paint.

This is flash bug, and should probably be filed separately after this bug is fixed.

The docs on MozAfterPaint currently state windowed plugins don't fire these event, so this is currently documented behavior. However internally, we use MozAfterPaint listeners to handle refreshing tab previews for the win7 taskbar. Currently windowed plugins remain static.

https://developer.mozilla.org/en/Gecko-Specific_DOM_Events#MozAfterPaint

Comment 1

[Jim Mathies [:jimm]]

(In reply to comment #0)
> I did a little experimenting on this by firing the event off on windows after a
> WM_PAINT event is handled by the plugin. Unfortunately the event ended up
> getting dumped in nsEventStateManager's PreHandleEvent. Looks like pres content
> fires this off normally and tracks the invalidate rects that need to sent with
> the event.

That should have been "pres context", the event is fired from here - 
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#2039

Comment 2

[Jim Mathies [:jimm]]

Attachment: fix

Comment 3

[Jim Mathies [:jimm]]

Attachment: plugin invalidation fix v.1

r? -> Roc for changes in layout/generic.

Comment 4

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

Comment on attachment 439033 [details] [diff] [review]
plugin invalidation fix v.1

+  virtual void NotifyOwnerPluginInvalidated(nsIntRect *aRect) = 0;

Make this a const nsRect& so it can never be null. Otherwise, this looks pretty cool!

Comment 5

[Jim Mathies [:jimm]]

Before we land this, we really need to do something about memory usage in previews. This patch exacerbates the problems I described with my STR in bug 559326.

Comment 6

[Rob Arnold [:robarnold]]

(In reply to comment #5)
> Before we land this, we really need to do something about memory usage in
> previews. This patch exacerbates the problems I described with my STR in bug
> 559326.

I don't think that's the right bug to depend on since it's dealing with a leak that now no longer occurs in stock firefox (and no addons use the APIs afaik). Can you file a new bug on excessive memory usage in aero peek? I thought we were pretty good about keeping it down.

Comment 7

[Rob Arnold [:robarnold]]

Jim, any status update on this? Looks like it fell off the radar.

Comment 8

[Jim Mathies [:jimm]]

(In reply to comment #7)
> Jim, any status update on this? Looks like it fell off the radar.

From what I remember, performance for oopp plugins was horrible due to the use of PrintWindow. Tried addressing the problem in bug 542656 but didn't find a suitable fix.

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.