Closed Bug 269840 Opened 17 years ago Closed 15 years ago
lines appear when scrolling <hr> offscreen and then back on
743 bytes, text/html
37.69 KB, image/png
455 bytes, text/html
673 bytes, text/html
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 On my homepage, whenever I scroll down, then back up with the mouse wheel, gray lines strike through the news section. My CSS is valid, my homepage is valid, so it's not that. Reproducible: Always Steps to Reproduce: 1.Go to http://turkeybot.info/ 2.Scroll all the way down, then back up, and look at the news section (DO NOT CLICK ANYTHING WHILE SCROLLING, OR THE LINES WILL DISAPPEAR) 3. Actual Results: A lot of lines struck through the news section Expected Results: Not rendered the lines Here's what I see: http://turkeybot.info/glitch.png Copy/paste the URL in the url bar, because referrers are refused with images.
This is kinda odd...the glitch would not reproduce for me without all of the following conditions: A) Overflow:auto (kinda infamous) with the div B) Font-size set in the html class C) Form tag (and an input button for validity) in a div before the mess occurs Maybe someone knows what's going on :S
Oh, and an <hr> had to be included as well to reproduce the glitch.
Confirmed on fresh install with new profile of `Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0' (from official installer) with NVIDIA GeForce 2 MX graphics card. See http://forums.mozillazine.org/viewtopic.php?t=163514&postorder=asc&postsperpage=99 for further info. What seems to be happening is that when the browser window is of sufficient width (>~900/1000 px), as one scrolls up or down (using any method*), for every given constant period, a grey 1 px thick horizontal line "appears" on the "rendered page" across the entire news section of the page (only) where the upper edge of the displayable rendered area is in that time point being touched by the "rendered page". The "rendered page" is the whole page in memory that you are able to scroll and which the displayable rendered area is a relatively movable window on. By "appears" I mean if you are scrolling up they are shown on the display or they are on the rendered display if that makes any sense. (I'm very tired, but may look at this again tommorrow and look at the CSS that is causing it.) Refreshing the display by changing the window size, covering and then uncovering the window with another window or the edge of the desktop, highlighting the affected area, switching to another tab or minimising and restoring the window causes the grey lines to be "forgotton" again so they are no longer displayable (even if they were not displayed when this action was taken). * Methods tested: [PG-UP] & [PG-DOWN], [SPACE], dragging scroll bar up and down with pointing device, moving mouse wheel up or down, highlighting past the displayable rendered area. Could someone test this in SeaMonkey and recent trunk builds?
This bug is very similar to (though is not the same bug as) bug 212213. Also shows similarities to bug 111176 and bug 15942 (and dupes of those). (Someone on MZ forum also pointed to horizontal line problem with Firefox on NetBSD <http://mail-index.netbsd.org/port-macppc/2004/09/22/0001.html> but I don't think it is related.)
Fresh install with new profile of `Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0' (from official installer) with NVIDIA GeForce 2 MX graphics card.
This is an even simpler testcase. Here is the salient code from it: <html style="font-size: .85em"> <hr><div style="width: 75%; float: right; overflow: auto"> <form></form> <div style="overflow: auto">
Shouldn't test cases be valid code?
Also seeing this on Mozilla Suite Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041108
I would just like to point out to everyone the following thing: On the testcase, middle click so you see those two arrows that let you scroll up and down with the mouse. Once you middle click, touch your mouse so it crawls down the page, slowly. Once it reaches the bottom, touch it up so it crawls slowly up the page. Watch what it does...
Sorry I can't create a new attachment because this problem occurs on a sensitive application on production. 80 users, Mozilla 1.6 > 1.7.3 or Firefox 0.8 > 1.0 On this application, pages are generated by servlets .jsp I was recently informed by several users about lines appearing at the bottom of the screen when scrolling... (did it occurs before Mozilla 1.7.3 ?) I changed my Mozilla 1.7.3 for Firefox 1.0 and the problem remains. Some precisions : lines does NOT appear when 2 tabs (or more) are oppened lines does NOT appear when full screen (F11) lines does NOT appear when window smaller than screen and this, on the same page, without reloading. Ask me for more details if it can help !
If this is also showing up on mozilla suite, then there's a great shot this happens on other platforms, so I will adjust it as such.
OS: Windows XP → All
Hardware: PC → All
Does anyone care if I change my homepage since we have testcases to reproduce the bug?
In case this is remotely useful to anyone, I just happened to notice this WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 . Also, in reply to comment #12: >>Does anyone care if I change my homepage since we have testcases to reproduce the bug?<< I guess not.
it's a dupe of bug 274521 *** This bug has been marked as a duplicate of 274521 ***
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
How is this a dup when that bug is specific to framesets?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
yes, sorry for mess. WFM Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.7.5) Gecko/20041108 Firefox/1.0
How was it a dupe when I filed this bug well before that other one was filed? >_> (In reply to comment #16) > yes, sorry for mess. > > WFM Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.7.5) Gecko/20041108 Firefox/1.0 I'm still getting the problem -> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050204 Firefox/1.0+
Requesting a block for 1.1 since afaik it's aimed to clean up gecko bugs.
I can reproduce in 1.0, but this works fine for me in the latest nightly.
Version: Trunk → unspecified
It still reproduces for me Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050219 Firefox/1.0+
Removing URL to avoid confusion Gavin, were you going to the URL, or using the "Simpler Testcase"? That's what still reproduces for me: the testcase that is.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050219 Firefox/1.0+ Confirming testcase 2 , using the guidelines in comment 10 ->New
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reproducible in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050219
Assignee: firefox → nobody
Severity: major → normal
Component: General → Layout: Block and Inline
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Version: unspecified → Trunk
Still reproducible in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050302 Firefox/1.0+ However, unlike in comment #10, the lines appear no matter how many tabs are opened, and the lines do appear if the window is not maximized.
Is this still present in recent builds? http://ftp.uni-erlangen.de/pub/mozilla.org/firefox/nightly/latest-trunk/ I believe bug 173051 may have fixed this issue.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050401 Firefox/1.0+ Apologies for the spam. Yes it is still present in the latest nightly builds. Fingers were in motion before brain was engaged.
FYI my testcase seems to WFM in Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.6) Gecko/20050328 Firefox/1.0
(In reply to comment #27) > FYI my testcase seems to WFM in Mozilla/5.0 (X11; U; Linux i686; en-GB; > rv:1.7.6) Gecko/20050328 Firefox/1.0 Downloaded latest zip nightly w/clean profile, and I still see the bug.
The bug is still there in the firefox nightly build of April 4th (used with a clean profile and a clean installation directory). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050404 Firefox/1.0+ I have attached an even simpler testcase that triggers the bug. it is XHTML 1.0-compliant, but it could be reduced to this : <html style="font-size: .85em"> <hr /><div style="overflow:auto;"> <p></p><div style="overflow:auto;">
Not sure if it is related, but sometimes pages seem to not scroll as one. What I mean is that it is almost like a page is divided into 3 or 4 sections, and one is slow to follow the other back up.
Sasquatch Bigfoot, that commet isn't really helpful since you provide no testcase. Don't think this will make it into 1.8b2 so: -> Requesting blocking for 1.1
Anyone notice a change in where the lines appear? With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+ and scrolling up & down, I get lines appear at the top of the page. But with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050418 Firefox/1.0+ and scrolling up & down, I get the lines at the bottom of the page.
Ignore comment 32 please, I had hit CTRL++ to make the font bigger and this changes where the erroneous lines are drawn. CTRL+- makes the testcase fail in the same way as it always has for me. No difference between 20050417 & 20050418.
the same thing here http://www.mikeindustries.com/blog/archive/2005/05/ipod-winner-1#comments
*** Bug 294829 has been marked as a duplicate of this bug. ***
The first testcase is now WFM. The last two, however, still show the bug. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050722 Firefox/1.0+ ID:2005072212
Is there a resolution for this bug (apart from not using iframes)
Summary: Strange lines appear when scrolling down, then back up → When page scrolled down andn <hr> near the top leaves the viewport, <hr> is redrawn on each line scrolled down and visible when scrolled up
I had no idea what this bug was until I read the "bug activity". For the record, or those searching comments it used to be "Strange lines appear when scrolling down, then back up". Not sure why the cryptic name, or how that would help. If anything, it might lead to more duplicate bugs. Sorry for the extra message.
I was making the summary clearer (I thought), but you do make sense. Sorry for the name change.
Summary: When page scrolled down andn <hr> near the top leaves the viewport, <hr> is redrawn on each line scrolled down and visible when scrolled up → Strange lines appear when scrolling
Summary: Strange lines appear when scrolling → Strange lines appear when scrolling down, then back up
Summary: Strange lines appear when scrolling down, then back up → lines appear when scrolling <hr> offscreen and then back on
not seeing this with suite, but does fail on firefox DP alpha 2 suite Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050810 SeaMonkey/1.0a FF Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050816 Firefox/1.0+
I'm seeing this bug with a position:fixed element that has a border-right: 2px solid #000 and a border-bottom: 1px solid #000. The bottom border is renderred as 2px, but when the page scrolls, it goes back to 1px, leaving the line artifact behind. I tested this with position:absolute, but that worked perfectly.
Fixed in 1.5b1? WFM here.
Nix that. Testcase 1: WFM Testcase 2: Bug Testcase 3: Bug Latest 1.5b1 (via patching)
All three testcases work. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051120 Firefox/1.6a1 ID:2005112004
Testcase 1 WFM. Testcase 2 and Testcase 3 many hr’s and right-click produces a scrollbar inside the window... http://img62.imageshack.us/img62/1917/strangefxbehaviour8mq.gif
(In reply to comment #45) > right-click produces a scrollbar inside the window... That's bug 286368.
Testcase 1, WFM. Testcase 2 and 3, still see the bug. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060205 Firefox/1.5 ID:2006020505
works for me on the trunk
Status: NEW → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.