Open Bug 557823 Opened 12 years ago Updated 4 years ago
Windowed plugins don't fire NS
_AFTERPAINT ("Moz After Paint") events after rendering
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
(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
Assignee: nobody → jmathies
r? -> Roc for changes in layout/generic.
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!
Attachment #439033 - Flags: review?(roc) → review+
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.
Depends on: 559326
(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.
Jim, any status update on this? Looks like it fell off the radar.
(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.
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.