Install the test files attached to bug 109041 and open the html page. Then make the window small enough so that scroll bars appear. Then scroll down the page. The windowless plugin moves down as you scroll down. It should stay in the the same place relative to the page. The seems to be a similar problem to bug 93056, which occured with XPCOM windowless plugins. I haven't tested to see whether this is a regression for all windowless plugins or is just a problem with NS4.x windowless. I'll try to look at the cause of this later in the week.

This isn't a regression, it looks like the patch in bug 93056 only worked because the div tag containing the plugin was moving. This causes nsObjectFrame::DidReflow which recalculates the coordinates that are passed to the plugin. However, if the content in bug 93056 is not moving then it exhibits the same problem as in this bug where it doesn't redraw properly when scrolled. Where should we update the coordinates that are passed to the plugin in the case of scrolling? We could apply a similar patch to the one in 93056 to the draw method, so that before passing the paint message on to the the plugin we recalculate the offset and origin, and call setwindow if anything has changed. Is there a better place though - e.g. something that gets called whenever a scroll happens?

Patrick Beard is working on adding NPEventType_ScrollingBeginsEvent and NPEventType_ScrollingEndsEvent. See bug 104445 for details.

Nominating for Mozilla 1.0, without this being fixed windowless plugins can only be used on pages where no scrolling can happen.

This could be a dup of bug 117793 . If so, I'm nominating it as such.

*** Bug 117793 has been marked as a duplicate of this bug. ***

I had exepcted this bug to be fixed by the patch checked in as a fix to bug 116093. As SetWindow is now called in the Paint method, the plugin should be passed the correct coordinates then. The test case that is pointed to by this bug no longer works properly when there are no scroll bars either. I think this is something that has been introduced by the recent group of checkins. I'd guess that the special thing about the test content is that it is in a div tag. Should I open a new bug for this, or re-open bug 116093?

If you feel that the bug has been fixed by the original patch but reappeared later as a regression due to some other check in, then I think it would be better to file a new bug rather than reopen the existing one.

I've filed bug 118721 for the problem with the current test case which is unrelated to scrolling. Maybe we need another test case, perhaps the one from 117793.

Ari, Can you post an updated testcase in this bug showing the problem with scrolling? Thanks.

Here is a test case: http://cole.viewpoint.com/~aberger/setwindowbug/index.html I have been able to reproduce it on the current .9.4 branch. If you don't have our plugin installed, see http://cole.viewpoint.com/~aberger/readme.txt for instructions. I've traced down the problem to the following: In setWindow, you give us an NPWindow *. We look at the window->x and window->y when we want to draw. In NS4x, those window->y changes as you scroll the plugin to indicate that the origin of the plugin window has moved relative to the visible page. In NS6, the value never seems to change. Let me know if you have problems reproducing.

This patch takes into account scrolled view position when preparing to |NPP_SetWindow| call in |nsObjectFrame::Paint| method. Ari, David, occasionally I see some painting problems after I scroll the original test case back and forth in both x and y directions, but those problems do not occur with the two test cases I've just posted above. We need to decide if this is our or plugin's problem asap. Could you please look at it?

Looks great! I can't reproduce any drawing errors. Scrolling horizontally and vertically works. We'll have our QA bang on this.

Just a minor clean up -- got rid of unnecessary variables.

Comment on attachment 64745 [details] [diff] [review] patch v.2 sr=attinasi

Comment on attachment 64745 [details] [diff] [review] patch v.2 One minor nit, please change if(parentFrame) { to if (parentFrame) { r=bnesse. I assume this will go onto the trunk as well?

marking it edt0.9.4+. Please get this into the 0.9.4 branch and trunk also. Thanks.

we would like this bug into 0.9.4 by 11:59pm PST on 15-jan

The fix is now in both trunk and the branch. Marking fixed.

this is fixed, tested on rbanch 0114 and trunk 0115. However, I still see a crasher bug (http://bugscape.mcom.com/show_bug.cgi?id=11566) when I reload + resize+scroll the window . This happens 'only on the TRUNK'. 0.9.4 BRANCH is ok. Marking this bug VERIF.

Can a bug be put in Bugzilla to match the one in bugscape?