Painting problems when scrolling page with Java applet

VERIFIED FIXED in mozilla1.9beta2

Status

()

Core
Layout: View Rendering
VERIFIED FIXED
10 years ago
3 years ago

People

(Reporter: Adam Guthrie, Assigned: cpearce)

Tracking

({regression})

Trunk
mozilla1.9beta2
x86
Windows XP
regression
Points:
---
Bug Flags:
blocking1.9 +
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:RwCo])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

10 years ago
This is happening on all Java applets I've tested. Requesting blocking.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+

Comment 2

10 years ago
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.
Assignee: roc → chris
Whiteboard: [dbaron-1.9:CwRo]
(Assignee)

Comment 4

10 years ago
Created attachment 285282 [details]
Testcase 1 - Applet background smears when scrolling
(Assignee)

Comment 5

10 years ago
Eli is correct in that the bug only occurs with a fixed background image.
Whiteboard: [dbaron-1.9:CwRo] → [dbaron-1.9:RwCo]
Chris, can you take this? I'll help you with it.
(Assignee)

Comment 7

10 years ago
Sure, taking.
Status: NEW → ASSIGNED
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.
(Assignee)

Comment 9

10 years ago
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.
(Assignee)

Comment 10

10 years ago
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.
(Assignee)

Comment 11

10 years ago
This regressed between firefox-3.0a5pre.en-US.win32-2007-05-27 and firefox-3.0a5pre.en-US.win32-2007-05-28.
(Assignee)

Comment 12

10 years ago
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.
(Assignee)

Comment 14

10 years ago
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.
(Assignee)

Comment 15

10 years ago
(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.
(Assignee)

Comment 17

10 years ago
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.
Attachment #285800 - Flags: review?(roc)
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+
Attachment #285800 - Flags: review?(roc) → review+
(Assignee)

Comment 19

10 years ago
Created attachment 285811 [details] [diff] [review]
Patch v2 - Patch v1 with comment changed
Attachment #285800 - Attachment is obsolete: true
Attachment #285811 - Flags: review+
Remind me to land this for you when the tree opens after M9
Keywords: checkin-needed
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M10
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
Status: RESOLVED → VERIFIED
Flags: in-litmus?

Comment 23

3 years ago
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
You need to log in before you can comment on or make changes to this bug.