Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070904 Minefield/3.0a7pre Steps to reproduce: 1. Go to http://www.java.com/en/download/help/testvm.xml. 2. Wait for the applet to load. 3. Scroll up and down the page. Actual results: Applet contents get "smeared" around in the plug-in window. Expected results: Applet contents stay where they are normally. This regressed between 2007-05-27-04 and 2007-05-28-04, making it a regression from bug 343430. I'm guessing this is probably Windows-only.
This is happening on all Java applets I've tested. Requesting blocking.
My theory here is that Java is creating a child window; because UpdateWidgetArea doesn't know about it, it never gets invalidated. (Note that the page in question has a fixed background, which is why we're triggering this code in the first place.)
Chris, it would be good if you could investigate this and at least get a reduced testcase.
Eli is correct in that the bug only occurs with a fixed background image.
Chris, can you take this? I'll help you with it.
Scrolling the fixed-background page repaints the entire window every step, because it has to. That doesn't repaint the applet's widget, but that should be OK, because we're moving the applet's widget and the applet's widget should not be transparent. What seems to be happening is that we are moving the widget as we scroll, but Windows is not blitting the widget contents as the widget moves. I have no idea why not. Need to investigate what window style bits are set on the plugin's window and what API calls we're using in ways that changed between FF2 and FF3.
Both FF3 and FF2 have the same window styles for the SunAwtFrame window that they create. Window Styles: 52000000 WS_CHILDWINDOW WS_VISIBLE WS_CLIPCHILDREN Extended Styles: 00000004 WS_EX_LEFT WS_EX_LTRREADING WS_EX_RIGHTSCROLLBAR WS_EX_NOPARENTNOTIFY In both FF2 and FF3, the SunAwtFrame has a SunAwtCanvas (which has more children of the same type) which has the same styles as the SunAwtFrame, but it also has the WS_CLIPSIBLINGS. Note that the bug does not occur in FF2.
I wrote a small program to add WS_CLIPSIBLINGS to the SunAwtFrame in FF3, and doing so does not solve the problem. So it's unrelated to that.
This regressed between firefox-3.0a5pre.en-US.win32-2007-05-27 and firefox-3.0a5pre.en-US.win32-2007-05-28.
The reggression happened in the patch from bug 343430: https://bugzilla.mozilla.org/attachment.cgi?id=265542 I unrolled the patch, and the bug goes away, though some flicker does come back, and it does occasionally miss repainting some of the text in the middle of the applet if I rapidly resize the window. So... What's wrong with this patch then...
(In reply to comment #11) > This regressed between firefox-3.0a5pre.en-US.win32-2007-05-27 and > firefox-3.0a5pre.en-US.win32-2007-05-28. Off-topic: Adam already mentioned this in comment 0.
Ok, so what's happening is that the code introduced to nsScrollPortView::Scroll() is restricting the clip rect passed to nsWindow::Scroll() to be a short bar near the top of the window. Then when ::ScrollWindowEx() is called with the SW_SCROLLCHILDREN flag, only the region of the JVM's child window which intersects with the clip rect is being updated. Usually there isn't any intersection, so no part of the applet gets updated. The only way to get part of the applet redrawn is to make the window short, and scroll the applet area to the top of the window - a thin bar at the top will be updated as you scroll.
(In reply to comment #2) > My theory here is that Java is creating a child window; because > UpdateWidgetArea doesn't know about it, it never gets invalidated. > > (Note that the page in question has a fixed background, which is why we're > triggering this code in the first place.) > Would this then indicate a bug in AccumulateIntersectionsIntoDirtyRegion()? Or does the JVM's win32 window not have a child widget/view which was associated with the scroll pane?
I get it now. Hmm. Let's talk about this on Tuesday.
Created attachment 285800 [details] [diff] [review] Patch v1 - Invalidate foreign child windows before update Invalidates all child windows that are not "ours" upon scroll. This ensure that they're repainted.
Comment on attachment 285800 [details] [diff] [review] Patch v1 - Invalidate foreign child windows before update + // Invalidate all child windows that aren't ours. This ensures + // that things like Applet windows get redrawn upon scroll. See bug 387701. A better comment, something like // Invalidate all child windows that aren't ours; we're moving them, and we // expect them to be painted at the new location even if they're outside the // region we're bit-blit scrolling. just post a new patch and carry forward the r+
Created attachment 285811 [details] [diff] [review] Patch v2 - Patch v1 with comment changed
Remind me to land this for you when the tree opens after M9
Checking in widget/src/windows/nsWindow.cpp; /cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v <-- nsWindow.cpp new revision: 3.714; previous revision: 3.713 done Checking in widget/src/windows/nsWindow.h; /cvsroot/mozilla/widget/src/windows/nsWindow.h,v <-- nsWindow.h new revision: 3.245; previous revision: 3.244 done
It's still a bit slow with updating when dragging with the scrollbar thumb, but I think it's good enough (you don't get any "smearing" anyway). Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110705 Minefield/3.0a9pre
I'm seeing this behavior in FF30 in Windows 7, so I think a regression as occurred: https://bugzilla.mozilla.org/show_bug.cgi?id=730640