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

RESOLVED INACTIVE

Status

()

Core
DOM: Events
RESOLVED INACTIVE
8 years ago
9 hours ago

People

(Reporter: jimm, Unassigned)

Tracking

Trunk
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
(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
(Reporter)

Comment 2

8 years ago
Created attachment 438143 [details] [diff] [review]
fix
Assignee: nobody → jmathies
(Reporter)

Comment 3

8 years ago
Created attachment 439033 [details] [diff] [review]
plugin invalidation fix v.1

r? -> Roc for changes in layout/generic.
Attachment #438143 - Attachment is obsolete: true
Attachment #439033 - Flags: review?(roc)
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+
(Reporter)

Comment 5

8 years ago
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.
(Reporter)

Updated

8 years ago
No longer depends on: 559326
(Reporter)

Updated

8 years ago
Depends on: 559613
(Reporter)

Updated

8 years ago
No longer blocks: 474056
Jim, any status update on this? Looks like it fell off the radar.
(Reporter)

Comment 8

8 years ago
(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.

Updated

7 years ago
Duplicate of this bug: 587447
(Reporter)

Updated

5 years ago
Assignee: jmathies → nobody

Comment 10

9 hours ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 9 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.