It's at least also used for X11.
Fixing this just entails a minor edit or deletion of this comment in npapi.h.
Created attachment 403518 [details] [diff] [review]
The comment also needs deleting from https://developer.mozilla.org/en/NPWindow, though the description of the argument there seems right.
https://developer.mozilla.org/en/Gecko_Plugin_API_Reference:Drawing_and_Event_Handling is also ok.
In Mozilla code, clipRect is set correctly for X11 plugins (though only really needed for windowless plugins). For windowless win32 plugins, its not small enough to be effective, so the plugin actually needs to confine drawing to the dirty rect.
clipRect seems to be set correctly for Mac plugins (though there are too many different code paths for me to really know). Looks like plugins with NPEventModelCocoa and NPDrawingModelCoreGraphics also get a dirty rect.
The story seems too difficult to tell in npapi.h, and I'm not really sure whether the windowless win32 issue is a bug in Mozilla or plugins are just expected to confine drawing to the "update area" in the WM_PAINT message, so removing the comment seems best.
Thanks, Josh for updating https://developer.mozilla.org/en/NPWindow.
Reopening to back this change out. 'clipRect' isn't needed on other platforms, so there's no need to indicate it's valid other platforms. Also, it's not supported in our current ipc shim code for win32.
clipRect is needed on X11.
(In reply to comment #4)
> clipRect is needed on X11.
Ok, so I pulled the old patch -
I guess we should update again to state that this is valid on X11 and OSX?
(In reply to comment #5)
Why you are asking that question?
Why did you add a comment that is wrong?
(In reply to comment #6)
> (In reply to comment #5)
> Why you are asking that question?
> Why did you add a comment that is wrong?
I just pulled the original patch. We can touch it up or reland or whatever, we just need to figure out what we're going to do here.
There's a patch in bug 568219 that makes this work on win32 with oopp. W/out oopp the values were already set in nsObjectFrame.
I really don't feel strongly one way or another.
I would add that when I did the oopp work, I did a bit of searching and came across a lot of docs/code/whatever that had that "mac only" comment in them, hence the reason why oopp on win32 doesn't support clipRect currently. So I doubt any plugins on win32 are currently using this, and I don't believe they need it either. (it's always 0,0,width,height afaict.)
I have verified that Flash does in fact use the NPWindow.clipRect on Windows, because when I put in incorrect values, it only painted part of the screen.
This was fixed again in bug 571538