Closed Bug 93526 Opened 24 years ago Closed 22 years ago

Scrolling position:fixed element leaves detritus [FIX POS]

Categories

(Core Graveyard :: GFX, defect, P1)

Product:
Core Graveyard
Component:
GFX
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: btiffany, Assigned: dcone)

References

(
URL
)

Details

(Keywords: platform-parity, Whiteboard: [Hixie-P1])

Attachments

(8 files)

Simplified version of offending page.
4.54 KB, text/html
Details
testcase, with background image
1.27 KB, text/html
Details
testcase, without background image
1.18 KB, text/html
Details
Another testcase with borders as well
5.15 KB, text/html
Details
New testcase (requires download/editing for full effect)
7.84 KB, text/html
Details
Testcase: DOM, no graphics
6.63 KB, text/html
Details
http://www.w3.org/Style in 2002083017 on OS X 10.2
56.56 KB, image/png
Details
Test case showing "flicker" issues with position: fixed and pure CSS menus
1.78 KB, text/html
Details
Seen with build 2001080304 on MacOS 8.6. Go to http://www.w3.org/Style/CSS/ and note the fixed position menu in the upper-right corner of the page. Drag the vertical scrollbar thumb slowly and notice that the menu smears, leaving behind bits of the background. This worked on the 2001070508 build (and likely later--that build was recent enough to rule out the possible dups that I found; modem speed prevented further investigation). I have a largely reduced test page that I'll attach. Curiously, the image at the end of the page is necessary to trigger the bug.
Confirmed under Mac/2001080214/9.1. Scrolling by dragging the elevator ("live" scrolling) results in the display anomalies described in this bug. Scrolling by clicking the scrollbar background refreshes to the nominal state.
Status: UNCONFIRMED → NEW
Ever confirmed: true
FWIW, I've noticed a great slowdown with position:fixed when there are large images on a page, with very slow repainting, even on my very fast system.
This seems to be Mac only. On Windows 2000 it works fine for me. Adding pp.
Keywords: pp
Whiteboard: [Hixie-P1]
I disagree, I had the same problem on Windows 2000. I'm attaching two testcases, one with a background image for the fixed position element and one without. Notice the significant "stuttering" when scrolling the document when there is a background image.
The slowness is a different problem which is described in bug 96088. Note that the last 2 testcases don't show the original problem (detritus when scrolling). Only the first testcase shows it (attachment 44613 [details] - "Simplified version of offending page"). I also confirm that it seems to only happen on the Mac. Win98 is fine and hixie declared Win2000 fine too. Kevin: you can test on unix and maybe reassign to me if it is indeed Mac-only.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
*** Bug 102935 has been marked as a duplicate of this bug. ***
I cannot reproduce the w3.org/Style/CSS problem (well, I can reproduce the slowness, not the detritus). However, I do have a test where it leaves detritus if you use a fixed position menu with a border (see attached test case).
I can not reproduce with cvs trunk builds from on WINNT and Linux. If there is still a problem it must be Mac only.
Target Milestone: mozilla0.9.7 → mozilla1.0.1
Reassigning to Pierre since the problem is Mac only.
Assignee: kmcclusk → pierre
Status: ASSIGNED → NEW
I can reproduce in Mac OS 9.2.1 using the Nov 6 build (2001-11-06-08) with attachment http://bugzilla.mozilla.org/showattachment.cgi?attach_id=44613. Moving the scroll bar down then up will cause the paint issue with red square.
win32 build 2001111903, win98se Are the effects I saw at http://cyberfuddle.com/infinitebabble/writing/webdesign_standards.html this same problem? This page has a fixed div at the top and another on the right. The scrolling effects below happened repeatedly, then suddenly stopped just when I was about to get some screen shots. Maybe someone will see this on a Win build. Scroll down the page by clicking on the scrollbar. A bit of the fixed divs flash at the top of the screen, then disappear. Scroll down the page by dragging the scrollbar thumb. Detritus is noticable on the right div. Scroll up the page by clicking on the scrollbar. The top div paints at the bottom of the screen as well as the top. Scroll up the page by dragging the scrollbar thumb. Ack! The whole page is littered with parts of the top div.
I can only reproduce it on the Mac and with the first testcase (attachment 44613 [details]). Interestingly enough, if I visit a page like http://www.mozilla.org/ then paste the URL of the testcase and type Return, scrolling the page doesn't leave detritus. Then if I reload the page, the detritus come back. I noticed that when the page loads after typing its URL, the vertical scrollbar doesn't flash at the end of the page load and the scrolling goes smoothly. However when doing a Reload, the vertical scrollbar flashes at the end of the page load and the scrolling leaves detritus. K Chayka: Is it what you are seeing on your Win98 machine?
Status: NEW → ASSIGNED
Priority: -- → P3
Currently on win32 build 2001112408. I am not able to reproduce the detritus effects using attachment 44613 [details] as you describe. However, with attachment 55817 [details] I do see effects very similar to what I saw at cyberfuddle.com: Scroll down by clicking the scrollbar - the top border on the div disappears. Scroll up by clicking the scrollbar - the top (or bottom?) border paints at the bottom of the screen as well as the top. Scroll up by dragging the thumb - the border is painted repeatedly. The faster the scrolling, the more ill the effects.
Just to clarify a little bit, with the test case that I uploaded (55817), some scrolling methods don't reproduce the problem. For instance, if I use the arrow keys or the up/down buttons on the scroll bar, I get no detritus. If I use the mouse wheel, click on the empty part of the scroll bar or click and drag the scroll bar, I do get detritus.
Using Moz build 011008 (0.9.7+) for OS X, this bug is still visible: the w3c page is whacked. However, the first testcase on this page does NOT produce the same effect. So, in short, the bug still exists, but its cause my not be completely understood.
Problem still exists in 2002011408/Mac, although not all the time. You can even see it if you install the HTML4 sidebar tabs (http://developer.netscape.com/evangelism/sidebar/) and pick the "Attr" subtab. Click on "align..." a couple of times to expand and collapse it. After that, scroll down, then up; the little tabs across the top will leave detritus. The little tabs are in a fixed-position DIV and are pure styled text, if that makes a difference. Interestingly, on the "Elem" subtab I can scroll up and down with no detritus left behind. The only difference between the two subtabs would seem to be that the "Attr" subtab has images in it, and also some DOM scripting. I'll be happy to attach screenshots of the sidebar tabs evincing this problem on my Mac if someone indicates that would be helpful.
See following comments for instructions.
I've gathered some interesting new data, and indications of a small raft of problems. First, download attachment 68548 [details] and get ready for minimal editing. Okay, try scrolling the document up and down. In 2002020405, there should be detritus left behind by the fixed-position element on the right. Now, comment out the image in the "normal flow" and reload the page. The fixed element should not leave detritus behind when scrolling. Basically, it would seem that the drawing of an image in the normal flow triggers this problem. See attachment 44613 [details], where the problem doesn't happen until you scroll far enough to make the normal-flow image appear. It doesn't matter if the image comes before or after the fixed element in the source-- it simply nees to be painted for the bug to kick in. Okay, back to the downloaded attachment. Restore the image, and insert a copy of it next to the paragraph that says "INSERT IMAGE HERE." In NS6.2.1, inserting the image here and reloading the document will cause the detritus problem to go away. In Moz2002020405/Mac, the problem persists, so it would seem we're actually regressing in this area. Furthermore, when the image is inserted, it makes the fixed element wider for no good reason. This has a fascinating effect: If you grab-drag the left side of the scroller box for the document, you instead select text for as far as you're willing to drag. If you grab the right side of the scroller box, the document will scroll as normal. If the fixed element is set to have 'right: 0' then none of the scroller box will work at all. It would seem that the fixed element, when it expands, does so by a constant amount, and wherever it intersects with the scrollbar it prevents it from working. Also notice that the right-aligned text in the fixed element does not align with the right edge of the element, despite the fact there is no padding at all. The image, when inserted, does right-align to the incorrectly expanded right edge of the fixed element, but the text remains where it was. So, in summary: the detritus problem appears to be caused by the painting of an image in the normal flow. It can be "fixed" in NS6.2.1 by inserting an image into the fixed element, but this fix doesn't hold true in recent builds. The internal formatting of the fixed element is broken, and inserting an image makes it worse and can interfere with the UI.
Bulk moving Mozilla1.01 bugs to future-P1
Priority: P3 → P1
Target Milestone: mozilla1.0.1 → Future
Blocks: 122193
Blocks: 131486
Pierre is out of the picture for the near term (next year or so). Reassigning so this will get some attention. Resetting milestone to request retriage.
Assignee: pierre → kmcclusk
Status: ASSIGNED → NEW
Target Milestone: Future → ---
*** Bug 122193 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0.1
minusing for mozilla1.0.1. will re-consider if a patch emerges.
Keywords: mozilla1.0.1 → mozilla1.0.1-
Severity: normal → major
*** Bug 149933 has been marked as a duplicate of this bug. ***
In relation to comment 20: I've installed the CSS2 and HTML4.01 Quick Reference tabs, and I get garbage when I scroll. See http://www.vinc17.org/download/snapshot2.png for instance. Machine: PowerBook G4 (PowerPC). OS: Linux (Woody Debian distribution), using the XFree86 X server (no VNC). Mozilla build ID: 2002061523 and 2002061723. position:fixed elements don't work correctly (bug 90270), but they do not leave garbage.
*** Bug 153282 has been marked as a duplicate of this bug. ***
*** Bug 131486 has been marked as a duplicate of this bug. ***
Summary: Scrolling position:fixed element leaves detritus → Scrolling position:fixed element leaves detritus [FIX POS]
Keywords: mozilla1.1
-> dcone
Assignee: kmcclusk → dcone
*** Bug 154573 has been marked as a duplicate of this bug. ***
*** Bug 156553 has been marked as a duplicate of this bug. ***
I have two URLs to offer as test cases. http://www.cadenceweb.com:8080/newsletter/sheerin/test/Prototype6a.html doesn't usually (or ever?) exhibit the bug. It is a modified version of the following URL, lacking all of the <object> tags and SVG insertions--any or all of which appears to trigger the same behavior noted earlier. I've found the detritus on Netscape 7.0 pr1 running under Windows XP on an old 500MHz Dell laptop and under Me on my old ~200MHz HP Pavilion. http://www.cadenceweb.com:8080/newsletter/sheerin/test/Prototype6b.html Trying that page under Windows XP on a Dell Precision 530 exposes a difference tha may assist in tracking down the cause. I'm running the display at 1280x1024, and when the "b" version of the page is displayed less than full screen, the detritus appears while scrolling, but with the page maximized, the problem disappears entirely.
Reagrding comment 34, I tested both URLs in 2002071603/Mac (trunk), and the first (6a) gave me no problems. The second (6b) didn't leave behind detritus, but all of the fixed-position elements flickered as I scrolled up and down the document. I also saw some odd flickering in the scrollbars themselves. However, I'm still seeing detritus left behind in several of the testcases, so the bug still exists on Mac. It just seems to have spread to other platforms. If the effect can be reproduced under non-Mac OSes, we need to flip this to All/All. (A few more votes for the bug wouldn't hurt, either!)
win32 build 2002071404, win98se On http://www.cadenceweb.com:8080/newsletter/sheerin/test/Prototype6b.html the fixed-position graphic covering the right side of the page header does flicker when scrolling, plus I see the detritis regardless of the window size. Reproducible for me: 1. load the page 2. use the Page Down key until the page bottom is reached 3. use the Page Up key to go back to the page top Once the page bottom has been reached, the detritus is at the bottom of the page until reaching the top again, then it appears mid-page. All appears normal on http://www.cadenceweb.com:8080/newsletter/sheerin/test/Prototype6a.html. No flickering, no detritus.
I ran into this bug when taking position: fixed elements in and out of the flow using DOM to alter display: from block to none and back again. I found something interesting: using the 1.0 release on Mac OS X the attached testcase (also at http://reprocessed.org/testcases/mozilla-pos_fixed_repaint.html) does not show detritus, but using 1.1b (2002072203) it does. We've got some regression here... I'm on Mac OS X 10.1.5, with a ATI Rage mobility 128 graphics chipset.
I'm flipping this to All/All, since similar problems have been reported with some pages in Win2K builds (see comment 34). Sorry if I'm unfairly tarring Linux et. al. with this brush, but this bug isn't just for Macintosh any more...
OS: Mac System 8.6 → All
Hardware: Macintosh → All
I'm still getting detritus scrolling around Netscape's CSS2 and HTML4 quick refernce sidebars, on Linux, build 2002072021 from the trunk. So this bug most probably should be set to All/All.
*** Bug 166247 has been marked as a duplicate of this bug. ***
I can't reproduce any of these problems on Linux with the latest trunk build. Can anyone give me a testcase which will show a problem on Linux?
I've noticed fewer problems in recent Mac builds-- for example, the detritus hasn't affected the HTML4.01 sidebar's "Attr" tab. However, I have still been seeing the detritus in attachment 44613 [details], up through at least 2002090408/MacOS9.1 (haven't downloaded today's build yet to check). I get the impression that things are being fixed elsehwere that affect this bug, but don't completely clear it up. Perhaps the fix in bug 152373 had something to do with the improvements.
The "Testcase: DOM, no graphics" testcase fails consistently for me (after toggling the display) using FizzillaCFM/2002083017.
Just scrolling up and down doesn't show any problems on those testcases for me. Perhaps this is a Mac-only problem now. Can you attach a screenshot? Ccing Mac guys.
What exact steps did you take to generate that?
I can still reproduce the problem on <http://perceco2.chem.upenn.edu/~percec/member.html> with Mac OS9. Scroll down and hit the UP arrow.
I'm guessing this is a Mac toolkit bug. When we scroll the root widget it should be issuing repaints for the areas which were under other widgets but have been uncovered by the scroll.
roc+moz: To reproduce on Linux, install Netscape's CSS2 Sidebar panel from <http://devedge.netscape.com/toolbox/sidebars/>. Scroll it down, then scroll back up. Note that the tabs along the top are never repainted over.
I see that in my 8/17 build, but not in my 8/25 build. Perhaps I fixed the Linux problem with my checkin for bug 152373...
Actually my 8/25 build is a development build that contains patches including the patch for bug 152373 that I checked in on 9/3. So you all may want to recheck with a build from today or yesterday.
PS, those devedge sidebars are really awesome!
Bug still evident using FizzillaCFM/2002090508 to access the first testcase.
> What exact steps did you take to generate that? I loaded http://www.w3.org/Style, scrolled down using the mouse wheel, scrolled up using the mouse wheel and took a screenshot.
win32 trunk build 2002090604, win98se I can't reproduce detritus on any of the test cases, the NS sidebar tabs, or at the W3C Styles page. The first url listed in comment #34, which had detritus I could consistently reproduce, is gone now. Would it be a bold assumption to think that whatever caused the detritus on that page is now fixed, too?
Having tried all the testcases bar the one which requires editing with Mac OS X 2002090603 I can only reproduce detritus in the first testcase ('simplified version of offending page'). To do this visit the page, scroll and detritus appears. Reload (reload button on toolbar or apple-R) and the detritus goes away and doesn't come back. Full reload (or whatever this is actually called - it's shift-apple-reload on Mac) and the detritus reappears on scrolling again. This seems to be a reliable reoccurence, having tried it several (a dozen or so) times. I'm running 10.1.5 still.
Matt, what happens with the page I mentioned in comment #48? I downloaded the current nightly for Mac OS9, but it crashed immediately after startup. Right now, I am running 1.1 (20020826) back again and still find the problem.
I don't get detritus when viewing the page you refer to in comment #48. I'm using Mac OS X 10.1.5, not OS 9.
Sorry, folks, for removing the URL mentioned in #34--that page has undergone some extensive modifications and now has a new address: http://www.cadenceweb.com:8080/newsletter/test/ Some, but not all of the detritus is gone. That created from the top banner is indeed gone, and things are working much better in both Windows and Macintosh builds, but there are still some significant problems with the Mac build that may have some relationship with the previous behavior (they don't show up on Windows builds). My test platform is Mac OS 9.1 with Moz 1.1 (20020826) 1) Many elements on the page flash when scrolled. Drag the thumbbar on the main section and the banner, scrollbars, and the other two text areas flash. 2) In the main content section (subhead "Lots of Images") the captions beneath the images will disappear or be painted out of the correct area as you scroll the page. The boxes holding the captions also leave detritus on lower sections of the page. Also, if you click on the first image (may have to do it twice), the pop-up takes far longer to display than on a Windows system. 3) Hold your mouse over any of the external links with a globe, and watch as the link blinks while the animated GIF is displayed. 4) In the section "Printing Support" an entire section of sample code (inside a <pre> element with overflow:auto) disappears at times, also leaving behind detritus (a big gray rectangle). If you scroll it just right, you can find a wee bit of detritus coming from the top banner. 5) I'm mentioning this only in passing, because it really belongs in a text-rendering bug, but the sample dictionary pronounciations are being displayed with gaps that aren't there on Windows builds. I doubt there's any relationship to the other problems, but on the chance there is, that's another data point.
Sounds like this bug is now Mac-specific. Someone with a Mac is going to have to do some debugging.
#59: I can't reproduce this bug on the page mentioned in comment #48 either, using the current nightly (2002090908) on MacOS9.2. Looks like the problem here is fixed.
Doh! How could I forget that my name was part of that URL? http://www.cadenceweb.com:8080/newsletter/sheerin/test/ I've also restored the two original test pages: http://www.cadenceweb.com:8080/newsletter/sheerin/test/Prototype6a.html http://www.cadenceweb.com:8080/newsletter/sheerin/test/Prototype6b.html and modified their css to restore the original detritus behavior in older builds (known to be broken in Netscape 6.2). In doing so I tracked down what caused the problem. The page uses position:fixed to layout the various divs and the <body> without any overlap. Without specifying z-index on any of the sections, the detritus appears in earlier builds of Moz. But if you add a z-index to the top banner that raises it above the rest (defaulting to 0), the detritus disappears. The latest builds of Mozilla have corrected this behavior, though the Mac version still flashes while any section is being scrolled.
Using FizzillaCFM/2002090903, I retested all the testcases on this bug, and they all appeared to work. I didn't find that too surprising, since sometimes this bug doesn't manifest. Indeed, I returned to my own testcase, the URL reported in bug 122193, and the problem was again evident. I then tried the recommendation in comment 63, adding z-index:0 to my testcase's fixed-position div, with no success. The detritus was still painted.
*** Bug 166247 has been marked as a duplicate of this bug. ***
I'm adding another test case at the suggestion of a fellow css-discuss listmember. If you open the test case in Moz (tested with the 1.1 Windows release and "a week-old nightly build of Moz 1.2." (according to my correspondent)), and hover over one of the menu items in the top left, the entire left bar "flickers" a few pixels right and then returns to the expected state. There is no Javascript in this example, it's all pure HTML and CSS. Changing line 31 to read position: absolute instead of position: fixed fixes the problem (but loses the fixed functionality).
Nice testcase! It may not be the same bug as the rest of the comments here but it's definitely a bug that I can reproduce on Linux. I'll look into a fix.
Er, Eric, your testcase is almost certainly bug 131475, not this problem here.
Robert, are you sure? I'm having some trouble following what exactly the bug you reference is about, but I'm not sure it directly relates (not that I have any deep knowledge of the codebase). If you're certain, I can go ahead and cross-reference the attachment into that bug.
No, I'm not sure. But we have a lot of bugs with 'position:relative' and absolutely positioned children so that makes me wonder.
Bulk moving P1-P5 un-milestoned bugs to future.
Target Milestone: --- → Future
Using FizzillaCFM/2002103011 on 10.1.5, this problem appears to possibly be no longer evident. That is, I couldn't reproduce it using any of the testcases on this bug or my own on bug 122193. While this is great for Mozilla, it's unfortunate for Chimera. Unless we know what patch fixed Mozilla, it can't get applied to the Chimera branch.
Is there a Bugzilla item for "use the trunk engine in Chimera" yet?
FWIW, in Chimera 1102 - OS X 10.2.1 the test in comment 33 (reprocessed.org...) is also covering the scroll bar if you reduce the size of the window enough to make appear the vertical scroll bar (and the thumb in front of the blue div). Half of the width of the scroll bar area at the end of the div and on the div height is painted in white. It's correctly redraw if you hide/show the window, but if you scroll down or resize the window that blank area reappear, and of course the garbage if you scroll.
It would be easier to figure out which patch fixed the bug if someone could say between which builds the bug was fixed.
That will prove difficult, since this bug was always intermittent anyway.
It's unlikely you could backport the fix to the 1.0 branch even if you found it since a lot has changed in the scrolling and clipping code. Just yell at the Chimera people to get back onto the trunk :-).
*** Bug 178446 has been marked as a duplicate of this bug. ***
My initial testing suggests this was fixed between trunk builds 2002091014 and 2002100308. Unfortunately, I have no builds between those two dates. Anyone that has trunk OS X builds between those dates, please let me know.
is attachment 44613 [details] (1st test case) still valid for this bug? if so, i still got the smearing effect when using an os x trunk build (on 10.2.1) from 2002080610.
ignore my last comment, i've been looking at this backwards. looking at my builds again...
okay, using comm mac os x trunk builds and the 1st test case, this was fixed sometime btwn the 2002.09.19.08 (broken) and 2002.10.02.08 (fixed) builds. will see if the intervening builds are still available for me to download, to narrow this down more...
narrowed it down to a seven-hour period: this was fixed in 2002.09.30.10, but broken in 2002.09.30.03.
er, make that a five-hour period: the 2002.09.30.08 build looks fine. so sometime btwn 3am and 8am on 9/30.
Sounds like it's related to bug 113083 -- probably a view flag (..._DONT_BITBLT) not being set correctly? roc?
That patch shouldn't have had any effect on this, but it's still the most likely candidate.
*** Bug 165271 has been marked as a duplicate of this bug. ***
Can that patch be applied to the Chimera branch? (Or 1.0 branch?)
The whole patch is huge and should not be applied to the 1.0 branch. Someone might try taking the patch apart to find the change that actually fixed this bug. But I don't think this is really worth fixing on the 1.0 branch. Chimera might take it I suppose. But Chimera should really just be brought up to the trunk.
*** Bug 166247 has been marked as a duplicate of this bug. ***
*** Bug 189122 has been marked as a duplicate of this bug. ***
This is worksforme on the trunk, as well as for everyone else, apparently. Marking so. The chimera issue should get a separate, chimera-specific, bug (or just disappear as chimera moves to the trunk).
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Oh, the chimera bug already exists -- bug 190383
No longer blocks: 122193
Blocks: 190383
*** Bug 100536 has been marked as a duplicate of this bug. ***
This has raised its head again on OS X (with a twist: you need to change the font size first). See bug 262369.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: