Closed Bug 237962 Opened 21 years ago Closed 20 years ago

Mouse wheel stops scrolling after the top of a div with its style set to use "overflow: auto" exits the top.

Categories

(SeaMonkey :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: joha, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 On the page http://fedoranews.org/anewman/shells/myforecast/ there is a large area that contains a shell script. The area is formatted with <code>-tag. When I scroll the page with mouse wheel, the scrolling stops after the top of the area exits from view. The same happens when I scroll from down: the scrolling stops when the area is not fully visible. Reproducible: Always Steps to Reproduce: 1. Open page http://fedoranews.org/anewman/shells/myforecast/ 2. Scroll down and keep the mouse cursor on the formatted area. 3. Scrolling stops after the top of the area is no longer visible. Actual Results: The scrolling stops. Expected Results: Scrolling should continue. My mouse wheel settings are at the OS-defaults. I've verified this also with mozilla 1.6 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040119). Similar thing happens on the page http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser. Now the source of this problem is the list containing the most-frequently-reported bugs. The case is different becaus now there is a scrollbar on the list an the list is inside an iframe.
WFM Mozilla 1.7a under WinXP.
I tried again with firefox on a new user with a clean profile and the latest gtk2 nightly and the basic nightly and suprisingly they don't behave equally: The basic gtk works as should, but the gtk2-build doesn't. So this bug seems to be gtk2 build only, since windows version has been reported to work and now I've tested that the non-gtk2 build works. Well there are the mac-builds still to be tested gtk build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040327 Firefox/0.8.0+ gtk2 build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040326 Firefox/0.8.0+
Narrowing things down a little, it's actually a problem with the overflow: auto CSS property with the GTK2 builds, not the <code> tag. I've got a simple demonstration page here: http://devrandom.com/test/overflow_auto.html The title of this bug should probably be changed to reflect this.
Changed the description according to the comment #3
Summary: Mouse wheel stops scrolling after the top of an <CODE>-formatted area exits the top. → Mouse wheel stops scrolling after the top of a div with its style set to use "overflow: auto" exits the top.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
I found another bug that is similar to this. The mouse wheel gets stuck after clicking on a link inside a div with overflow=hidden. Example here: http://server1.conquer-space.net/~ulf/list.html I can reproduce both bugs with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040521 Firefox/0.8.0+ Steps: 1. Open the page (http://server1.conquer-space.net/~ulf/list.html) 2. Click on the link 3. try scrolling with your mouse wheel
I can reproduce this (with an overflow: auto div) on Firefox 0.8/WinXP
This only happens is the mouse cursor is inside the area with the atribute overflow: auto when the top of this area hits the top of the windows. Try it with the sample submited by Adrian Yee. First put your browser window large enougth to fit the entire div, then scroll with the mouse pointer near the top of the window and it will stop scrolling, then try again with the mouse near the bottom of the window and everything will work fine.
I also noticed this bug on my weblog, in this post: http://nanobe.blogspot.com/2004/07/photoshop-on-linux.html The code blocks have overflow:auto, and it's the same symptoms. The mouse wheel doesn't scroll when the element with overflow:auto touches the top of the viewable portion of the page and the mouse cursor is over it, whether the element displays scrollbars or not. I'm seeing it in Firefox 0.9.1 on Linux, and also back on Mozilla 1.6.
WFM, 2004-08-14-05 trunk Linux
(In reply to comment #3) > Narrowing things down a little, it's actually a problem with the overflow: > auto CSS property with the GTK2 builds, not the <code> tag. The problem also affects elements with 'overflow: scroll'. In both cases it only happens if the mouse is over the element with this overflow property. Try scrolling the example page in comment #3 and keeping the mouse cursor in the narrow marigin by the side of the offending <div>. Could it be that the scrolling stops because the wheel should then start scrolling the element currently under the cursor? This might even be the expected behavior if the element actually has enough content so that it needs to be scrollable, and if scrolling these elements with the wheel actually worked (it doesn't, unfortunately). I think that scrolling over an element with scrollbars created by the overflow property would probably be most intuitive if it worked like scrolling over a <textarea> with a scrollbar. I mean that the element would only be scrolled if it was first given focus by clicking on it.
Product: Browser → Seamonkey
Experiencing this also in Firefox 1.0
WFM with latest trunk (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050303 Firefox/1.0+)
Works for me Firefox/1.0+Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050604 Firefox/1.0
Probably related to bug 97283 and is WFM now with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050713 Firefox/1.0+ I'm pretty sure this bug can be closed now.
Please reopen if this bug still can be seen in current trunk build.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
WFM with the latest nightly (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050906 Firefox/1.6a1). May be closed now .
You need to log in before you can comment on or make changes to this bug.