Closed Bug 2258 Opened 26 years ago Closed 26 years ago

[PP] Messed up drawing after scrolling

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
PowerPC
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: davidm)

References

(
URL
)

Details

Load the URL above in viewer. Scroll the page down. Note how now multiple copies of the page are drawn, overlaying eachother at different locations. This is not just a refresh problem; if you collapse the window and expand it again, it still draws with multiple overlaid copies. Eli notes that something similar occurs when you view an FTP directory, and resize the window. But then, a refresh of the window fixes the drawing problems. This works fine on Windows.
A little more info: if you turn off double-buffering, the problem goes away (or at least looks different). I guess we're drawing twice into a GWorld somewhere without clearing it first.
[This happens with a huge number of URLs; I've seen at least 7 or 8. For one grotesque example, see http://pds.jpl.nasa.gov/planets.]
Assignee: sdagley → mcmullen
Throwing to mcmullen since it is scrolling related. Eli, can you try and isolate what might be the common HTML element causing this problem? pink mentioned that it seemed to eb related to form elements but he has seen pages w/form elements that do not exhibit this behavior.
Absolutely. Will investigate tomorrow morning.
Status: NEW → ASSIGNED
Accepting bug
I see this on pages with just <HR>s and text, perhaps with some <FONT> tags.
Simon, could you provide these URLs? Simpler cases may help a lot to track down the bug.
<Am currently working on providing a simplified test case.>
Perhaps I'm stoned, but the following is a simplified test case that reproduces this behavior (if you shrink the Viewer window and then scroll) will invoked the messed up behavior. I don't understand why a simple <HTML><BODY> (lots of foo) </HTML></BODY> will invoke this behavior, but most pages don't exhibit it. ----SNIP---- <HTML> <BODY> foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foofoo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foofoo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo </BODY></HTML> ----S
<also, note that I was using the 1.12.98 build of Viewer to try to simplify the behavior.
I don't think this has anything to do with scrollbars. Using Eli's example, the overdrawing occurs even before the scrollbar is invoked. Just start resizing the window smaller.
<Also please note that if you take the same test case --- but put a background image on the page --- the problem does not occur. This probably explains in part why so few pages exhibit this problem.>
Likewise, if you put a BGCOLOR in the BODY tag, the problem also doesn't take place.
Pierre, any suggestions based on these experiments?
No... I'm even more confused because the problem only happens in the simplest case! I'll ask the layout gurus what they think about it.
Assignee: mcmullen → davidm
Status: ASSIGNED → NEW
reassign
Simon also noted an excellent scenario that may be related to this bug. Specifically, if you view a page (i.e. Sample 1 from the Sample menu), and then select "View Source", you'll see a new window with the source code superimposed onto the rendered page content. Didn't reproduce on Dagley's Mac, but I've seen it reproducibly with the 1.14.99 build of Viewer.
In nsCSSRendering.cpp there is a function called PaintBackground. If you specify either a background color or image, then a routine is called to draw the background. In the default case however, there is a color but it has a flag value of 3 which is defined as NS_STYLE_BG_COLOR_TRANSPARENT & NS_STYLE_BG_IMAGE_NONE. Since for a transparent background no drawing is done, the code just draws the new html over the old. I am guessing that the default background color should not be transparent but I don't know where the color comes from. Do we have a preference file where default browser prefs ( or where does the default background color get set) get read in from?
How about changing ::TextMode(srcOr) to ::TextMode(srcCopy) in nsRenderingContextMac::SetQuickDrawEnvironment()? If it solves the problem, please do a little bit of testing on various pages with and without background image/color, with/without form controls, etc...
I really don't think thats the problem. I think we should be drawing a background rect filled in with whatever the background color is. There shouldn't be a difference between a web page with a BGCOLOR set to white ( or whatever the netscape default background color is ) and one without the tag. I would like to change the default background color to grey and see if windows still works properly.
You're right, srcCopy is not the solution: when drawing a string, it erases whatever background there is. I asked some Layout folks to have a look at the problem.
more info. if you edit the root tag in ua.css and change the background color from inherit to blue it doesn't work. On windows it does. I am guessing that there is something wrong with drawing the root frame.
OS: All
The problem was in nsDocumentViewer which contained some XP_MAC code which made the assumption that the Root view would never be drawn.
Your fix is fine: you can remove my hack...
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
fix checked in
Status: RESOLVED → VERIFIED
Verified fixed using 1.22.99 build of Seamonkey. Specifically verified that: - the URL that Simon cited in the bug report displays correctly after scrolling - viewing page source works properly - a sampling of other web pages lacking backgrounds (www.yahoo.com & pds.jpl.nasa.gov/planets) also display scroll correctly
Inserting Milestone info.
You need to log in before you can comment on or make changes to this bug.