Closed
Bug 269840
Opened 20 years ago
Closed 19 years ago
lines appear when scrolling <hr> offscreen and then back on
Categories
(Core :: Layout: Block and Inline, defect)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: tonglebeak, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(4 files)
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.
Reporter | ||
Comment 1•20 years ago
|
||
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
Reporter | ||
Comment 2•20 years ago
|
||
Oh, and an <hr> had to be included as well to reproduce the glitch.
Comment 3•20 years ago
|
||
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?
Comment 4•20 years ago
|
||
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.)
Comment 5•20 years ago
|
||
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.
Comment 6•20 years ago
|
||
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">
Reporter | ||
Comment 7•20 years ago
|
||
Shouldn't test cases be valid code?
Comment 8•20 years ago
|
||
Also seeing this on Mozilla Suite
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041108
Reporter | ||
Comment 9•20 years ago
|
||
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...
Comment 10•20 years ago
|
||
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 !
Reporter | ||
Comment 11•20 years ago
|
||
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
Reporter | ||
Comment 12•20 years ago
|
||
Does anyone care if I change my homepage since we have testcases to reproduce
the bug?
Comment 13•20 years ago
|
||
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.
Comment 14•20 years ago
|
||
it's a dupe of bug 274521
*** This bug has been marked as a duplicate of 274521 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
![]() |
||
Comment 15•20 years ago
|
||
How is this a dup when that bug is specific to framesets?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 16•20 years ago
|
||
yes, sorry for mess.
WFM Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.7.5) Gecko/20041108 Firefox/1.0
Reporter | ||
Comment 17•20 years ago
|
||
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+
Reporter | ||
Comment 18•20 years ago
|
||
Requesting a block for 1.1 since afaik it's aimed to clean up gecko bugs.
Flags: blocking-aviary1.1?
Reporter | ||
Updated•20 years ago
|
Version: unspecified → Trunk
Comment 19•20 years ago
|
||
I can reproduce in 1.0, but this works fine for me in the latest nightly.
Version: Trunk → unspecified
Reporter | ||
Comment 20•20 years ago
|
||
It still reproduces for me
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050219
Firefox/1.0+
Reporter | ||
Comment 21•20 years ago
|
||
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.
Comment 22•20 years ago
|
||
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
Comment 23•20 years ago
|
||
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
Reporter | ||
Updated•20 years ago
|
Flags: blocking-aviary1.1? → blocking1.8b2?
Reporter | ||
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 24•20 years ago
|
||
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.
Comment 25•20 years ago
|
||
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.
Comment 26•20 years ago
|
||
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.
Comment 27•20 years ago
|
||
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
Reporter | ||
Comment 28•20 years ago
|
||
(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.
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 29•20 years ago
|
||
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;">
Comment 30•20 years ago
|
||
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.
Comment 31•20 years ago
|
||
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
Flags: blocking-aviary1.1?
Comment 32•20 years ago
|
||
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.
Comment 33•20 years ago
|
||
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.
Comment 34•20 years ago
|
||
the same thing here
http://www.mikeindustries.com/blog/archive/2005/05/ipod-winner-1#comments
Updated•20 years ago
|
Flags: blocking1.8b2? → blocking1.8b2-
Comment 35•20 years ago
|
||
*** Bug 294829 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.8b3?
Updated•20 years ago
|
Flags: blocking1.8b3? → blocking1.8b3-
Updated•20 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Reporter | ||
Comment 36•20 years ago
|
||
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
Comment 37•20 years ago
|
||
Is there a resolution for this bug (apart from not using iframes)
Reporter | ||
Updated•20 years ago
|
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
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.9a1?
Comment 38•20 years ago
|
||
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.
Reporter | ||
Comment 39•20 years ago
|
||
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
Reporter | ||
Updated•20 years ago
|
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
Comment 40•20 years ago
|
||
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+
Comment 41•20 years ago
|
||
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.
Comment 42•19 years ago
|
||
Fixed in 1.5b1? WFM here.
Comment 43•19 years ago
|
||
Nix that.
Testcase 1: WFM
Testcase 2: Bug
Testcase 3: Bug
Latest 1.5b1 (via patching)
Comment 44•19 years ago
|
||
All three testcases work.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051120 Firefox/1.6a1 ID:2005112004
Comment 45•19 years ago
|
||
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
Comment 46•19 years ago
|
||
(In reply to comment #45)
> right-click produces a scrollbar inside the window...
That's bug 286368.
Comment 47•19 years ago
|
||
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
Comment 48•19 years ago
|
||
works for me on the trunk
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Flags: blocking1.9a1?
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•