Closed Bug 292914 Opened 18 years ago Closed 18 years ago
No repaint after scrolling 32768 pixels
131.57 KB, image/png
249 bytes, text/html
3.02 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050504 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050504 Well I scroll to the bottom of the document using the <end> key, I sometime see other parts of the document. It is a repaint problem, because the links are still active, and the mouse pointer change when I hover them (even if I can't see them because they are not drawn) Scrolling with page down or the scroll bar doesn't show the bug. Reproducible: Sometimes Steps to Reproduce: 1. Open a long page, see URL for example 2. Scroll to bottom using the <end> key 3. If the bug doesn't show, go to the top again, and scroll with the <Page down> key one time and repeat step 2 Actual Results: Parts of the top of the page is displayed instead of the bottom. Expected Results: Display the good part of the page Tested with Mozilla and Firefox
Is this Mac only? I don't see other reports. WHen did this regress?
I think it is Mac only, but I can't be sure. I'm testing the 2005042110 build now, and the bug is present. In fact, the bug is not really easy to reproduce in normal browsing, so it can stay unnoticed. I have seen the bug only with the bug page in the URL, and the steps have changed a little. I need to <page down> x5, then <end> to trigger the bug now. It seems that to trigger the bug, the page must be long enough, and you need to scroll with a certain amount of pixel in one time (but not too much).
I ran into a similar bug while using Find on a Bonsai page and made a testcase. Comment 4 makes me believe my bug is the same as this one.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Repaint problem when scrolling to bottom of page → No repaint after scrolling 32768 pixels
To reproduce, load this testcase and press End and then Home. Another way to reproduce is to load the testcase, use Find for the string 'o', and Find Again until it wraps. I've seen this problem while scrolling down similar distances, but this testcase only shows the problem while scrolling up.
Btw, I'm testing with trunk: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050715 Firefox/1.0+
QuickDraw uses 16-bit coordinates which max out at 32767.
Assignee: roc → sfraser_bugs
Target Milestone: --- → mozilla1.8beta4
This patch bypasses ScrollWindowRect if we're scrolling by an amount that is equal to or more than the height or width of the rect to be scrolled; in this case, we just invalidate the rect. This seems to work around a bug where ScrollWindowRect() fails to invalidate when the amount scrolled approaches the signed 16-bit limit.
diff is -w; I detabbed the method.
Attachment #189643 - Flags: superreview?(jhpedemonte) → review+
Attachment #189643 - Flags: approval1.8b4?
Attachment #189643 - Flags: approval1.8b4? → approval1.8b4+
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
(In reply to comment #12) > Checked in. There is still a repaint bug present if you view an applet and then hit back the area under the applet frame is not repainted.
(In reply to comment #13) > There is still a repaint bug present if you view an applet and then hit back the > area under the applet frame is not repainted. Does that have anything to do with scrolling? Sounds like bug 277067.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.