Last Comment Bug 97283 - Mouse wheel scrolling does not work for elements such as div using overflow - auto or scroll
: Mouse wheel scrolling does not work for elements such as div using overflow -...
Status: VERIFIED FIXED
: access, testcase
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: P3 major with 70 votes (vote)
: mozilla1.8alpha3
Assigned To: Mats Palmgren (vacation)
: John Morrison
Mentors:
: 135491 135906 137839 148536 152513 155296 169267 170012 172318 176029 182536 188535 193171 204597 209673 210878 213540 215113 216671 223890 228150 228656 229175 230148 234236 235833 237019 240684 241418 241923 246703 248591 251014 251477 251569 251667 254408 254808 256517 258186 259010 259310 261807 262271 263372 263507 263929 264039 264826 266404 268004 268638 271830 271937 272214 272231 272592 272832 273792 274207 275128 275261 276524 277517 280213 282456 282815 284401 285279 285420 285522 288034 288035 288372 289213 290621 290934 291041 291942 291976 292070 294985 296805 298146 299264 302488 302613 302965 306676 306823 308847 (view as bug list)
Depends on:
Blocks: 63663 78786 atfmeta 176538 233381 268003 295977
  Show dependency treegraph
 
Reported: 2001-08-28 05:53 PDT by Jason Tackaberry
Modified: 2015-10-18 05:59 PDT (History)
142 users (show)
asa: blocking1.7-
asa: blocking‑aviary1.0PR-
asa: blocking‑aviary1.0-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case -- a small div with overflow:auto (236 bytes, text/html)
2001-09-28 16:35 PDT, Jason Tackaberry
no flags Details
Testcase - Comparison of iframe and div scrolling (4.34 KB, text/html)
2002-05-07 08:28 PDT, Phil Housley
no flags Details
Testcase - including overflow:scroll (5.49 KB, text/html)
2003-02-20 14:03 PST, Markus Schmaus
no flags Details
Same as testcase 3, but with links to test tab focus (6.04 KB, text/html)
2003-03-11 10:26 PST, Dennis Kehrig
no flags Details
:hover & :focus behaviour test & <textarea> added to example (6.52 KB, text/html)
2003-03-11 13:21 PST, Maarten Brouwers
no flags Details
Improved workaround (1.01 KB, text/html)
2003-10-28 08:26 PST, Morten Nilsen
no flags Details
rendering of bkg image in overflow:auto div (1.42 KB, text/html)
2004-01-19 22:00 PST, james
no flags Details
This seems to work for me (1.40 KB, patch)
2004-06-30 16:09 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details | Diff | Splinter Review
Testcase - complex 1 (11.50 KB, text/html)
2004-07-16 19:35 PDT, Mats Palmgren (vacation)
no flags Details
Testcase - complex 1 in IFRAME (430 bytes, text/html)
2004-07-16 19:39 PDT, Mats Palmgren (vacation)
no flags Details
Testcase - complex 1 in FRAMEs (632 bytes, text/html)
2004-07-16 19:43 PDT, Mats Palmgren (vacation)
no flags Details
Patch B rev. 1 (8.11 KB, patch)
2004-07-16 20:00 PDT, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
Patch B rev. 1 (diff -uw) (6.87 KB, patch)
2004-07-16 20:02 PDT, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
Patch B rev. 2 (10.44 KB, patch)
2004-07-18 16:14 PDT, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
Patch B rev. 2 (diff -uw) (9.92 KB, patch)
2004-07-18 16:16 PDT, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
Frame hierarchy with scrolling aspects (8.22 KB, text/plain)
2004-07-23 00:08 PDT, Mats Palmgren (vacation)
no flags Details
Patch B rev. 3 (8.18 KB, patch)
2004-07-23 02:56 PDT, Mats Palmgren (vacation)
roc: review+
dbaron: superreview+
asa: approval‑aviary-
Details | Diff | Splinter Review
Patch B rev. 3 (diff -uw) (7.71 KB, patch)
2004-07-23 02:58 PDT, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review

Description Jason Tackaberry 2001-08-28 05:53:44 PDT
Given the following test:

<div style="width:100px; height:50px; overflow:auto; border: inset 2px white">
Line 1<br>Line 2<br> Line 3<br> Line 4<br> Line 5<br> Line 6<br>:Line 7<br>
</div>

Using the scrollwheel while the mouse is inside the div should scroll it.
Comment 1 Doron Rosenberg (IBM) 2001-09-01 12:30:34 PDT
what build are you using?
Comment 2 Jason Tackaberry 2001-09-01 12:33:01 PDT
Right now I'm using 2001083108.  It also didn't work using a build from 3 or 4
days ago.
Comment 3 basic 2001-09-04 23:03:03 PDT
mind giving us a testcase?? :)
Comment 4 basic 2001-09-04 23:17:33 PDT
XP Toolkit
Comment 5 Peter Trudelle 2001-09-16 11:59:07 PDT
->bryner for triage
Comment 6 Brian Ryner (not reading) 2001-09-18 13:30:25 PDT
confirmed
Comment 7 Jason Tackaberry 2001-09-28 16:35:45 PDT
Created attachment 51338 [details]
Test case -- a small div with overflow:auto
Comment 8 Peter Trudelle 2001-11-02 15:06:29 PST
->moz101
Comment 9 Vadim Berezniker 2002-04-04 18:31:30 PST
*** Bug 135491 has been marked as a duplicate of this bug. ***
Comment 10 bugs 2002-04-04 23:58:27 PST
I'm not sure if it should (it would be nice), but keyboard scrolling doesn't
work either (up, down, pgup, pgdown, home, end).

Build id: 2002031008 (0.9.9), Linux

Got here from bug 135491, with the HP ( http://pixel.recoil.org/ ) of Lord Pixel
(who seems to be on the CC list)
Comment 11 Vadim Berezniker 2002-04-06 03:07:03 PST
*** Bug 135906 has been marked as a duplicate of this bug. ***
Comment 12 Vadim Berezniker 2002-04-06 03:11:18 PST
he's right. scrolling is totally non-functional, not just with wheel.
try the testcase for example.

clarifying summary
Comment 13 Vadim Berezniker 2002-04-16 16:35:46 PDT
*** Bug 137839 has been marked as a duplicate of this bug. ***
Comment 14 Daniel 2002-04-19 01:51:42 PDT
in build 2002041711 it still doesnt work though CSS as improved a great lot.

Since it is an important bug, which will hinder to make Mozilla the best browser
ever and so letting commercial companies consider to bundle it, my suggest is to
let it be fixed for 1.0 and not 1.0.1.
Comment 15 Phil Housley 2002-05-07 08:28:48 PDT
Created attachment 82644 [details]
Testcase - Comparison of iframe and div scrolling

Should the behaviour here not be exactly the same as for an iframe (which works
perfectly)?  I would be the first to admit to have never even seen a line of
the mozilla code, but is it really that much to change?

c.f. Attachment.
Comment 16 Andrew Donkin 2002-05-16 14:22:49 PDT
A test case that works for me:

Debug -> Viewer Demos -> #12 More Fixed Pos

Resize small enough that "main" div needs scrollbars.  Keys and mouse wheel
won't scroll it, but scrollbar will.

Build 2002051009, Linux XFree 4.1.0.

However yesterday I had the DIV scrolling properly.  I did it with Ctrl-N, visit
a site in the new window, Ctrl-W (revealing Viewer demo #12), scrolling worked.
 Click in the DIV and scrolling stopped working.

Only I can't reproduce that now, so treat that how you will.
Comment 17 Kai Lahmann (is there, where MNG is) 2002-06-01 11:29:48 PDT
*** Bug 148536 has been marked as a duplicate of this bug. ***
Comment 18 Jesse Ruderman 2002-07-02 11:14:41 PDT
*** Bug 155296 has been marked as a duplicate of this bug. ***
Comment 19 Jesse Ruderman 2002-08-07 10:47:56 PDT
*** Bug 152513 has been marked as a duplicate of this bug. ***
Comment 20 Michal 'hramrach' Suchanek 2002-09-12 02:16:36 PDT
Looks like the div does not get focus -> no keyboard/wheel input.
Comment 21 Matthias Versen [:Matti] 2002-09-17 15:34:42 PDT
*** Bug 169267 has been marked as a duplicate of this bug. ***
Comment 22 Matthias Versen [:Matti] 2002-10-22 16:42:36 PDT
*** Bug 176029 has been marked as a duplicate of this bug. ***
Comment 23 Peter Mularien 2002-11-12 09:20:54 PST
Bug still occurs in mainline build 2002110704... will it ever be fixed?
Comment 24 Rick Smorawski 2002-11-24 15:29:47 PST
Still in 2002111508 Win32 

Any word on this one?
Comment 25 R.K.Aa. 2002-11-28 17:23:26 PST
*** Bug 170012 has been marked as a duplicate of this bug. ***
Comment 26 R.K.Aa. 2002-11-28 18:20:26 PST
*** Bug 182536 has been marked as a duplicate of this bug. ***
Comment 27 John Keiser (jkeiser) 2002-12-10 18:26:49 PST
*** Bug 172318 has been marked as a duplicate of this bug. ***
Comment 28 Daniel Wang 2003-01-10 11:34:10 PST
*** Bug 188535 has been marked as a duplicate of this bug. ***
Comment 29 Olivier Cahagne 2003-02-13 13:52:50 PST
*** Bug 193171 has been marked as a duplicate of this bug. ***
Comment 30 Jason Tackaberry 2003-02-16 15:48:45 PST
This isn't specific to div elements either.  The problem is with overflow:auto
in general.  For example <body style="height:50px; overflow:auto"> will exhibit
the same behaviour too.

Clarifying summary.
Comment 31 Markus Schmaus 2003-02-20 14:03:13 PST
Created attachment 115049 [details]
Testcase - including overflow:scroll

The bug isn't restricted to overflow:auto but occurs also in the case of
overflow:scroll.
I modified the existing testcase to show this behaviour.
Comment 32 Dennis Kehrig 2003-03-09 09:00:44 PST
Confirmed for Mozilla 1.2.1 on Windows XP, and Phoenix 0.5 on Windows XP.
Would be REALLY nice to see this one fixed.
Comment 33 Max Spicer 2003-03-11 09:46:17 PST
Browsing with caret (F7) does allow more navigation.  You can then click in the
textarea and move around it with the cursor keys.
Comment 34 Dennis Kehrig 2003-03-11 10:26:03 PST
Created attachment 116862 [details]
Same as testcase 3, but with links to test tab focus

Press tab to see the focus of the overflow-are change to show the links.
Comment 35 Rick DeBay 2003-03-11 11:44:50 PST
Any chance of this making 1.3?  It breaks our site, requiring Yet Another
workaround based on the user-agent string.
Comment 36 Maarten Brouwers 2003-03-11 13:21:25 PST
Created attachment 116880 [details]
:hover & :focus behaviour test & <textarea> added to example

I've added the pseudo-class :hover to all element. Compare the hover behaviour
(border turns red) of the not scrolling on wheelmouse elements in comparance to
the IFRAME and the TEXTAREA when it gets focus (when an object gets focus the
backgroundcolor should turn grey). Note that IFRAME doesn't even have to get
focus! (you can give it focus by clicking on the border)
Comment 37 Rick DeBay 2003-03-12 18:44:39 PST
Re comment 34:  There is no workaround so we have to fall back to NS 4.x
behavior, which means the whole page must scroll.  Which is really ugly.  And we
use this everywhere.  Which means we'll have to tell customers to use IE.  Which
sucks.  Nominating for blocker.
Comment 38 Dennis Kehrig 2003-03-13 00:46:45 PST
Blocking 1.3 because of this bug? Cooool. :)
Comment 39 Jacek Piskozub 2003-03-13 01:31:46 PST
Lemming: I do not think you are a mozilla.org driver. 
Comment 40 Dennis Kehrig 2003-03-13 01:41:47 PST
"Lemming: I do not think you are a mozilla.org driver."

Right, I'm not. I'm sorry, I saw this blocking feature for the first time and
thought you could vote with it or something. The help site did not seem to cover
this feature (I checked again afterwards and, well, I do now know that + is
"Granted").

But there are some things I cannot do with my account, and Bugzilla tells me so.
Why is this different? I should not have seen a select box there in the first place.

Setting it back to "?", sorry. Nevertheless, I think that this is a major
usability problem, especially since normal users cannot distinguish between
iframe and overflow. It should be fixed before 1.3 comes out. Hell, it should
have been fixed by 1.0 IMHO...
Comment 41 Dennis Kehrig 2003-03-13 09:58:43 PST
Interesting: a friend of mine uses overflow:auto for a gallery.
Once you click on an image, scrolling with the mouse wheel works!
Here's the URL:
http://gedankenfreiraum.hausundhof.com/index.php?album=trash&sub=denis_witt

After I saw this, I tried the latest test case. Focus a link with tab and
immediately you can use your mouse wheel!

Sadly this is not the case with keyboard navigation.
Comment 42 Jacek Piskozub 2003-03-13 10:12:31 PST
Actually to enable mouse scrolling in an overflow:auto box, it is enough to
*right-click* on a link inside the box and then left-click on the title bar (to
make the context menu vanish wihout giving focus back to any element of the page). 
Comment 43 Rick DeBay 2003-03-13 10:36:23 PST
I withdraw my blocking nomination.  I shouldn't play with those flags after
getting chewed out by a client.  Heck, they don't know or care if IE or Moz or
little elves are behind a turnkey solution.
This bug has been sitting with a major severity with no action.  Any chance of
it getting a little loving for 1.4?
Comment 44 José Jeria 2003-05-06 06:59:06 PDT
*** Bug 204597 has been marked as a duplicate of this bug. ***
Comment 45 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-06-17 10:56:15 PDT
*** Bug 209673 has been marked as a duplicate of this bug. ***
Comment 46 Aaron Leventhal 2003-07-08 09:40:54 PDT
*** Bug 210878 has been marked as a duplicate of this bug. ***
Comment 47 Aaron Leventhal 2003-07-08 09:47:28 PDT
I don't know if this is really a focus bug or what. It keeps showing up in dups
and has 35 votes.

We should really fix this. Bryner, roc+moz, bz, dbaron? Any ideas?
Comment 48 Aaron Leventhal 2003-07-08 11:15:42 PDT
This is suspciously similar to bug 63663 (Can't scroll using kbd/mousewheel in
fixed position layout) - not sure if the root cause is the same.
Comment 49 Robert Kaiser 2003-07-08 11:54:24 PDT
bug 63663 seems to be a dupe of this, or being at least blocked by this one
(setting as blocked for now, as it has many people, keywords and wording on it -
both are assigned to bryner, so it's best for him to decide about duping).

It really seems to be a focus thingy, because of what Comment #42 tells (and I
can reproduce this behavior here with http://jvp.kairo.at/).
I consider this to be increasingly important as modern websites arise which use
<frame>less layout, replacing this with <div>s and CSS, using overflow handling
where needed...
Comment 50 Aaron Leventhal 2003-07-08 14:11:25 PDT
Notes from IRC discussion with bryner:

1) Need to make blocks with overflow: auto, overflow: scroll and position: fixed
focusable
2) For keyboard scrolling, the keybindings currently exist on the domwindow and
scroll the main content area. The keybindings don't know about scrollable divs
3) Mousewheel code needs to walk up the frame tree a bit differently

My thoughts: up/down arrow work to scroll when a link is focused. The first
thing to do might be to try to get the CSS scrollable area to scroll when a link
within it is focused.
Comment 51 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-07-08 15:30:28 PDT
I don't think we need to make 'overflow' blocks truly focusable. We already
track the caret position when the user clicks in such blocks (or any blocks). We
just need the keyboard scroll handlers to work outward from the current caret
position when they look for a scrollport to scroll.
Comment 52 José Jeria 2003-07-23 08:02:33 PDT
*** Bug 213540 has been marked as a duplicate of this bug. ***
Comment 53 Jason Bassford 2003-07-23 08:26:34 PDT
Tweaking summary for better b.m.o. queries.  (A search on "mouse scroll div"
should include this bug.)
Comment 54 Jesse Ruderman 2003-08-05 23:49:34 PDT
I think the blocks do need to be focusable, at least when they have scrollbars.
 You should be able to tab to them and you should be able to see that they have
focus.
Comment 55 Jesse Ruderman 2003-08-05 23:50:38 PDT
*** Bug 215113 has been marked as a duplicate of this bug. ***
Comment 56 Andrey Novikov 2003-08-12 09:44:00 PDT
> you should be able to see that they have focus
Oh now, please! No more these ugly dotted borders. It breaks all the
presentation layer (visual perception) of a document.
Comment 57 José Jeria 2003-08-19 14:16:26 PDT
*** Bug 216671 has been marked as a duplicate of this bug. ***
Comment 58 Andre 2003-09-16 07:28:37 PDT
This bug two years old, and very annoying. Any plans to fix it?
Comment 59 Anne (:annevk) 2003-09-28 11:15:42 PDT
Added myself to the CC list.

The milestone for this bug _should_ be changed. The current one is out of date.
Comment 60 Jason Keirstead 2003-10-02 07:26:03 PDT
This bug seems to have been around forever. I can confirm it still exists in
Firebird 20030822, and its VERY annoying.
Comment 61 Shawn Walker 2003-10-15 07:17:22 PDT
What's the status on this bug?
Comment 62 Morten Nilsen 2003-10-17 01:35:10 PDT
Nominating this bug for blocking 1.5
Comment 63 Jacek Piskozub 2003-10-17 01:41:21 PDT
mozilla1.5 is already out so blocking it is a futile action. 

However, I wonder when "blocking1.6a" flag will be available.
Comment 64 Klaus Jørgensen 2003-10-28 08:05:41 PST
I have created a little workaround for this bug
http://kla.usj.dk/mozilla/scroll.html - it's not that nice but it works... 
Comment 65 Morten Nilsen 2003-10-28 08:26:04 PST
Created attachment 134324 [details]
Improved workaround

This workaround improves on the one posted in comment 64
Comment 66 Dan 2003-10-28 09:38:43 PST
Very nice workaround.  

One problem I see is that the scrolling get temporarily screwed up when you
click in the div or highlight text in the div.  If you click in the div,
scrolling stops working until the mouse is moved.  If you highlight text in the
div, scrolling stops working until you try to scroll unsuccessfully then move
the mouse.  Unfortunately the text that you highlight is lost at that point.  If
you add the fixScroll function to the onClick event of the div, it will remedy
these problems.  Unfortunately it is impossible to highlight anything whatsoever
after that change.

Is there any way to implement a similar workaround without setting the focus?  I
assume no.  
Comment 67 Morten Nilsen 2003-10-28 09:47:30 PST
I must admit I didn't consider those problems, but seeing as this is purely a
workaround for a *bug* in mozilla, I suppose we can live with those issues..
It will work a little better with this than without, after all.

One thing I didn't do, but I realize now I should have, is to implement browser
sniffing so as to not use this function on browsers other than ones known to be
buggy. That would be trivial to implement for anyone who'd like to use this
workaround, so I don't see a point in adding that code to this bug.
The workaround is only meant to be an example of how to fix this, after all.

I'll look into your last question after tonights meeting and post my findings...

While I'm here, I'll try nominating again for 1.6a/b ... sorry about the 1.5
nomination, I wasn't paying attention to release schedules back there.
Comment 68 Morten Nilsen 2003-10-28 13:18:18 PST
After some experimenting, I found a hackish way of fixing selections...
Adding onclick="this.onmouseover='';" to the div gives you this behaviour:

- On first attempt at making a selection, select from the start of the div to
where one clicked.
- On second attempt, the select works as expected
- Scrolling will no longer work in this div, until page is reloaded.

I tried finding a way to get rid of the first issue above, but my attempts were
unsucessful. If anyone knows how to unfocus in javascript, please give word.
Comment 69 Pham 2003-10-29 15:03:56 PST
*** Bug 223890 has been marked as a duplicate of this bug. ***
Comment 70 Asa Dotzler [:asa] 2003-11-25 12:36:50 PST
Bryner, can you look at these workaround patches and see if they're appropriate?
Comment 71 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-11-25 13:06:32 PST
I don't see any patches on the bug -- I see HTML that supposedly works around
the bug, but it doesn't seem to me to do anything.  Attaching such things to the
bug only makes it less likely that the bug will be fixed, since it makes the bug
more confusing.
Comment 72 Asa Dotzler [:asa] 2003-12-01 15:10:32 PST
no patch, not likely for 1.6.
Comment 73 Anne (:annevk) 2003-12-16 07:08:12 PST
*** Bug 228656 has been marked as a duplicate of this bug. ***
Comment 74 Oleg Sidletskiy 2003-12-17 11:16:20 PST
*** Bug 228150 has been marked as a duplicate of this bug. ***
Comment 75 Mike Connor [:mconnor] 2004-01-05 19:39:02 PST
*** Bug 230148 has been marked as a duplicate of this bug. ***
Comment 76 james 2004-01-19 22:00:15 PST
Created attachment 139476 [details]
rendering of bkg image in overflow:auto div

I have an additional bug, that is probably related to this one. Should I post
it as new? or is here fine enough? 

When scrolling manually (ie by clicking on the scrollbar) in a semi-transparent
div-layer with overflow:auto the rendering of the background image is dodgy.

Note: the javascript workaround posted above allows you to scroll, but still
gives a dodgy rendering of any background images.

Running: Moz 1.6/WIndows 98

james
Comment 77 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-01-19 22:15:37 PST
Comment on attachment 139476 [details]
rendering of bkg image in overflow:auto div

Not related to this bug.  Please file another.
Comment 78 Robert Kaiser 2004-02-08 12:43:43 PST
I did some investigation on our behaviour again, as I ran into a similar
situation on a new site I made:

The fun thing is, tabbing (with the keyboard) until a link in an overflow area
has focus makes mouse wheel scroll that area (wherever the mouse is in the
document, it srolls that area), but keyboard still scrolls the document scroll
bar... looks really broken...

(seeing this on a gtk2 trunk cvs Seamonkey build from today, 2004-02-08)
Comment 79 StevenRoy 2004-02-08 16:19:49 PST
Is everyone absolutely sure this is a focus problem, and not a problem
determining which element (a DIV, an IFRAME, a window, a link, or even plain
text) is to be scrolled? The way I see it, if the mouse is on an element when
the scrollwheel is used, or if an element has focus when the keyboard is used to
scroll, the element should scroll if it has a scroll bar (a visible and enabled
one), otherwise its container should if it has a (visible and enabled) scroll
bar, otherwise, so on. I don't know what Mozilla's current approach to scrolling
is, but if it's more complicated than this, I have to ask: Why?

Fixing this will probably also fix the opposite problem that I've been having:
DIVs that scroll when I don't want them to! (I intend to create a new bug report
after further experimentation with this problem.)
Comment 80 shadytrees 2004-02-14 19:28:54 PST
As I mentioned in Bug 229175, which might've been a dupe of this bug, scrolling
seems to now be fixed. However, I don't know the exact workings of this bug
(seems to vary a little bit from Bug 229175), but I can't experience the bug in
testcases (unless I'm testing them wrong). Using the official Firefox 0.8 release:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Comment 81 shadytrees 2004-02-14 19:31:38 PST
Continuing from previous comment (sorry for the spam): my mistake, Bug 229175
depends on this bug, and is not a dupe. However, I can't get the bug, as far as
I can tell, to reproduce itself on the testcases using the build mentioned.
Comment 82 Kevin Newman 2004-02-14 23:01:29 PST
It still does not work for me (test case 1 through 4) in FireFox 0.8. The IFrame
boxes work, but the div boxes with overflow: auto do not work.
Comment 83 Lino Tinoco 2004-02-26 08:10:58 PST
Still doesn't work on Mozilla 1.6, 1.7a (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7a) Gecko/20040219 MultiZilla/1.6.2.1d) and Firebird 0.7
Comment 84 José Jeria 2004-02-27 10:25:55 PST
*** Bug 235833 has been marked as a duplicate of this bug. ***
Comment 85 Radley Smith 2004-03-01 17:00:00 PST
Doesn't work for me either (Firefox 0.8 Mac.)
Comment 86 p.kretek 2004-03-05 10:56:56 PST
Please finally fix this. None of the workarounds work with Firefox on Mac.
...all other **** gets implemented... how abaut fixing this in the next ten years?
Comment 87 José Jeria 2004-03-10 08:59:44 PST
*** Bug 237019 has been marked as a duplicate of this bug. ***
Comment 88 José Jeria 2004-04-16 03:47:45 PDT
*** Bug 240684 has been marked as a duplicate of this bug. ***
Comment 89 5thaxis 2004-04-22 03:02:25 PDT
If you don't know already: The SmoothWheel extension seems to fix this
partially. At least on my configuration (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7b) Gecko/20040406 Firefox/0.8.0+).
As it seems, the extension uses an own method for finding scrollable targets
(function 'sw_findTargetObject'; lent from the AiO extension). However,
keyboard-scrolling (without Caret Browsing turned on) doesn't work with this either.
This is not meant as a workaround, but as a hint on how to resolve this problem
for those who are (hopefully) working on this bug.
IMHO this bug needs to be fixed ASAP. We can't blame IE for his buggy
CSS-rendering while such an issue, which keeps web-developers away from
switching to frameless layouts is still pending. As I have read, Mozilla 1.7
final is targetted for somewhere in May and will be the base for Firefox 1.0. I
fear that if this bug isn't fixed 'til then, we can wait another 2 years...
Comment 90 Robert Kaiser 2004-04-22 08:23:30 PDT
5thaxis:
This will never be fixed in 1.7, as there might be a risky patch neccessary. And
the IE argument doesn't count here, as IE has the same problem in that case.

Anyways, you're right that it's a good pointer, eventually, it will lead
developers to the problem.
If you want it fixed soon, you can always try to work on a patch though...
Comment 91 José Jeria 2004-04-28 03:15:23 PDT
*** Bug 241923 has been marked as a duplicate of this bug. ***
Comment 92 Jeremy Rand 2004-04-30 12:19:02 PDT
This bug has 90 votes; doesn't that qualify it for some attention?  We've waited
over 30 months for a fix, and it affects a lot of real-life pages.  End users,
which are the target audience of Firefox, will be very annoyed by this.  The
fact that Internet Explorer is even worse is no excuse.  Let's give this bug
some attention before Firefox 1.0.
Comment 93 Johannes Almiala 2004-05-01 14:56:38 PDT
I have filed <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=237962">a
bug</a>, that seems is related to, or is a duplicate of this one. The difference
is that it affects only linux-gtk2 builds and only mouse wheel.

Can anyone wiser here check if it is a duplicate or should it be on the blocks list.
Comment 94 José Jeria 2004-06-14 23:24:10 PDT
*** Bug 246703 has been marked as a duplicate of this bug. ***
Comment 95 chlamydia 2004-06-16 03:59:53 PDT
(In reply to comment #64)
> I have created a little workaround for this bug
> http://kla.usj.dk/mozilla/scroll.html - it's not that nice but it works... 

Thanks, this is what I'm looking for as long as the bug (still in in FF and MOZ 
1.6) is solved

Comment 96 Zach Spoelstra 2004-06-25 05:44:35 PDT
*** Bug 248591 has been marked as a duplicate of this bug. ***
Comment 97 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-06-30 16:09:56 PDT
Created attachment 152067 [details] [diff] [review]
This seems to work for me

Well, this seems to work for me, at least for the testcases it is.
Comment 98 Josh Nisly 2004-07-07 15:19:12 PDT
(In reply to comment #97)
> Created an attachment (id=152067)
> This seems to work for me
> 
> Well, this seems to work for me, at least for the testcases it is.

In my test case, this only fixed it for the mousewheel.  Did you get the arrow
keys and page up/page down to work?
Comment 99 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-07-08 09:56:36 PDT
Yes, sorry for the confusion. The patch only works for the mousewheel. I'm not a
programmer, but I succeeded with the patch because it is mostly removing code.

I think in order for to get the keyboard to work, there has to be done some work
in nsPresShell.cpp: PresShell::ScrollLine.
Instead of this:
 result = viewManager->GetRootScrollableView(&scrollView);
result has to become the first scrollable view of the frame that was last
clicked on, I think. (on the other hand, what I just wrote could just as easily
be rubbish)

Comment 100 Jesse Ruderman 2004-07-12 12:21:03 PDT
*** Bug 251014 has been marked as a duplicate of this bug. ***
Comment 101 Ed Lee :Mardak 2004-07-12 20:10:48 PDT
Just to point something out.. perhaps not too useful as a workaround though, but
it's strange/interesting.

I noticed on my page http://tdzk.agadak.net/planets.php, the bottom-most div let
me use the mousescroll from time to time. The way I got it to work was to select
the input field (at the bottom of that div) and tab to the submit button. When
that has focus, I could use the mousescroll (but not the up/down keys).

I didn't look too much into it, but maybe a minor workaround.. check when a div
gets focus and pass the focus to some submit button. (Sorry that I didn't make a
quick simple separate page to show a div and an submit button)
Comment 102 Mats Palmgren (vacation) 2004-07-14 19:33:32 PDT
*** Bug 251477 has been marked as a duplicate of this bug. ***
Comment 103 Ted Mielczarek [:ted.mielczarek] 2004-07-15 08:41:29 PDT
*** Bug 251569 has been marked as a duplicate of this bug. ***
Comment 104 José Jeria 2004-07-16 00:40:54 PDT
*** Bug 251667 has been marked as a duplicate of this bug. ***
Comment 105 John A. Bilicki III 2004-07-16 01:17:07 PDT
http://bugzilla.mozilla.org/attachment.cgi?id=152067&action=view

That...how do we add that to Firefox?  Or is that C+ or whatever?  Can I assume
this will be implemented in the next released version of the browser?
Comment 106 Mats Palmgren (vacation) 2004-07-16 19:31:11 PDT
Comment on attachment 152067 [details] [diff] [review]
This seems to work for me

I don't think we can ignore 'mCurrentFocus' completely. Also, this patch does
not work correctly with combo boxes.
Comment 107 Mats Palmgren (vacation) 2004-07-16 19:35:18 PDT
Created attachment 153476 [details]
Testcase - complex 1
Comment 108 Mats Palmgren (vacation) 2004-07-16 19:39:14 PDT
Created attachment 153477 [details]
Testcase - complex 1 in IFRAME
Comment 109 Mats Palmgren (vacation) 2004-07-16 19:43:25 PDT
Created attachment 153478 [details]
Testcase - complex 1 in FRAMEs
Comment 110 Mats Palmgren (vacation) 2004-07-16 20:00:27 PDT
Created attachment 153480 [details] [diff] [review]
Patch B rev. 1

This fixes the mouse-wheel scrolling part of this bug.
Comment 111 Mats Palmgren (vacation) 2004-07-16 20:02:18 PDT
Created attachment 153481 [details] [diff] [review]
Patch B rev. 1 (diff -uw)
Comment 112 Mats Palmgren (vacation) 2004-07-16 20:07:04 PDT
I have only tested the patch on Linux, I would appreciate if someone could try
it out on other platforms.
Comment 113 Mats Palmgren (vacation) 2004-07-16 20:16:37 PDT
The keyboard scrolling part of this bug is a different problem AFAICT and
should be spawned into a new bug.  We probably need to make one of the frames
focusable (ScrollPortFrame?) and then keyboard scrolling will work
automagically?
Comment 114 John A. Bilicki III 2004-07-16 21:01:20 PDT
It works fine on .91 on XP.  I feel that half of the problem has been fixed.

The other half is when you move over ANY of those elements while scrolling, that
specific element you are over should start scrolling.  For example, when you
move from the bottom to the top frame, and then scroll over the IFRAME, the
IFRAME should scroll and the frame itself should stop scrolling.  This should be
done without scrolling the mouse more then once.

IE XP fails to do this with all the fields.  The selectable options field for
example will not scroll unless you select an item from that field and then
scroll.  Items should always scroll when the mouse is over them versus having to
manually select them.

Get that issue fixed and consider all of this case closed unless I've missed
something.
Comment 115 Jon Reid 2004-07-17 17:14:33 PDT
(In reply to comment #114)

Just to make sure I haven't misunderstood...  

Remember than the UI paradigm on Windows and Mac is "click to determine what
should scroll," not "view to determine what should scroll."  In other words,
whatever object currently has focus should scroll, and focus should not shift
just because a new object scrolls into view.  Users are used to picking with
their mouse (or keyboard, or whatever) what objects they wish to interact with,
and once they've chosen the browser should not override that choice.

It sounds to me like Comment #114 is saying that an object should scroll until
another embedded sub-object appears, and then that sub-object should immediately
start scrolling while the original object stops scrolling.  Such a behavior
would violate the "click to determine what should scroll" paradigm that users
are used to.

I apologise if I've misunderstood.
Comment 116 Mats Palmgren (vacation) 2004-07-17 17:38:47 PDT
(In reply to comment #114)
> The other half is when you move over ANY of those elements while scrolling,
> that specific element you are over should start scrolling.

That was my intention and it works like that on Linux. I could have
misunderstood what you meant though.  Using for example
"Testcase - complex 1 in IFRAME" (attachment 153477 [details]):

If I place the mouse over the "t" in "IFRAME test" at the top
and then mouse-wheel scroll down, the follwing elements will scroll:
1. Viewport, 1 step (mouse is now over "_1_ ...")
2.   DIV with text "_1_ ...", 5 steps (mouse is now over the first list)
3.    SELECT with eight "option", 1 step (scrollbar reached end)
4.   DIV with text "_1_ ...", 7 more steps (mouse is now over "_2_")
5.    DIV with text "_2_ ...", 8 steps (mouse is now over 2nd list)
6.     2nd SELECT with eight "option", 1 step (scrollbar reached end)
7.    DIV with text "_2_ ...", 2 more steps (reached "textarea2")
8.     TEXTAREA "textarea2", 2 steps (scrollbar reached end)
9.    DIV with text "_2_ ...", 1 more step (scrollbar reached end)
10.  DIV with text "_1_ ...", 2 more steps (scrollbar reached end)
11. IFRAME 8 steps (mouse is now in the last option list)
12.  Last SELECT 1 step (scrollbar reached end)
13. IFRAME, 10 more steps (scrollbar reached end)
14.Viewport, ~17 more steps to reach end of page

Are you seeing something different than this on Windows XP?
Comment 117 Mats Palmgren (vacation) 2004-07-17 17:39:50 PDT
(In reply to comment #115)
The patch works like this:

The currently focused (that is keyboard focus) element always has priority
to scroll, but if it can't scroll (doesn't have scrollbar or the scrollbar
reached its end position) *then* the target element (what is under the mouse)
is scrolled if it can, if not then traverse its enclosing elements until
something can be scrolled. If nothing is found then scroll the page if possible.
(There is an exception for combobox dropdowns, which works the same as now).

It's only when there is nothing focused or the focused element can't scroll
that the case you describe occurs.
Comment 118 Robert Kaiser 2004-07-17 17:40:57 PDT
> Remember than the UI paradigm on Windows and Mac is "click to determine what
> should scroll," not "view to determine what should scroll." 

True, only on Linux/Unix it is usually "mouseover to detemine what to scroll (by
mousewheel action)".
Be sure that at least the Win/Mac way does work as expected, it would be nice
though if the unix way did as well (on that platform[s], of course).
Comment 119 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-07-17 17:49:27 PDT
I really don't like the idea of dispatching keyboard events based on concepts
other than focus or caret position (in particular, mouse coordinates).  (If we
want old-style X11 behavior for some platforms, those platforms can cause mouse
movement to change the focus.)  We already have a bunch of weird code where key
events are dispatched based on coordinates, and I'd rather not have more of it.

I also tend to think that mouse scroll events should also be based on focus --
i.e., that mouse scroll and keyboard scroll should do the same thing.  Or is
that not the convention?

That said, I haven't looked at the patch yet, only some of the comments,
although comment 51 did seem reasonable to me.
Comment 120 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-07-17 17:52:13 PDT
... so I think this bug could probably benefit from some more research into
scrolling behavior on different platforms.

Also, I think frames/iframes and 'overflow' should not be distinguishable to the
user based on their scrolling / focus behavior.  Does this patch do that?
Comment 121 Mats Palmgren (vacation) 2004-07-17 18:53:35 PDT
IE6.0 on Windows XP on the "complex 1" testcases behaves much as I
have implemented it, not what was described above as the "UI paradigm on
Windows". It goes further than I did in fact. The differences I see is:
1. IE6 does not prioritize the element that has keyboard focus - it *always*
   scrolls what is under the mouse, except:
2. IE6 does not start scrolling a SELECT unless you click on it, and it
   does not scroll enclosing elements when its scrollbar reaches the end.

Other than that it does what I have implemented.
I did notice 2. already before but I intentionally wanted lists
to behave as textareas when scrolled into.

Observe that all these tests and the patch addresses the *mouse-wheel*
scrolling part.  Keyboard scrolling is different and will not change by
the proposed patch.

(I used a clean never-been-used-before account for the tests, so the above is
 the default behaviour.)
Comment 122 Mats Palmgren (vacation) 2004-07-17 19:20:56 PDT
(In reply to comment #119)
> I really don't like the idea of dispatching keyboard events based on concepts
> other than focus or caret position (in particular, mouse coordinates).

Just to be clear on this point: I totally agree.

> although comment 51 did seem reasonable to me.

This is the keyboard scroll part I wanted to spawn off as a new bug.
I also agree with comment 51 and this part will be *exactly* as IE6/win32
as far as I can tell (scroll only the focused element - nothing else).


(In reply to comment #120)
> Also, I think frames/iframes and 'overflow' should not be distinguishable
> user based on their scrolling / focus behavior.  Does this patch do that?

With regards to mouse scrolling: yes (including SELECT lists).
The patch does not address focus behaviour.
Comment 123 Mats Palmgren (vacation) 2004-07-17 19:34:49 PDT
Mouse scrolling SELECT lists without having to click on them is also
consistent with other parts of the UI, like for example the folder and message
list panes in Mail, the (2) dropdown lists of location bar, the list of
actions in the Edit Filter dialog etc.
Comment 124 Mats Palmgren (vacation) 2004-07-17 20:17:44 PDT
Comment on attachment 153480 [details] [diff] [review]
Patch B rev. 1

+  for (; focusFrame && passToParent; ) {

This should have been a "while" of course...

Let me know if you want me to make a combined patch with bug 78786
Comment 125 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-17 20:53:50 PDT
I think this patch is the right idea. Having the mousewheel scroll the frame
under the mouse pointer seems reasonable. If you press a regular mouse button,
it does something to the object under the mouse pointer. If you press the scroll
wheel, that scrolls the object under the mouse pointer.

For keyboard scrolling, I think we should do a similar search but start the
search at the frame where the caret is (effectively, the frame that was last
clicked or focused). (There always is a caret even though it's normally hidden;
it's where "find next" starts, for example.)
Comment 126 Jason Bassford 2004-07-17 21:13:48 PDT
FWIW: I completely *disagree* that the focus issue should be taken up in this
bug.  This bug should only be about getting scrollbars in elements such as DIVs
to scroll.  The separate (albeit related) issue of where the focus lies should
be handled elsewhere.  Aside from the fact that clicking on an element to
specifically give it focus SHOULD be addressed here (which is currently broken,
and which this bug was originally about).

Going on to have focus change on mouseover to a different element is a feature
request - not a bug fix...
Comment 127 John A. Bilicki III 2004-07-17 22:05:06 PDT
Scrollbars don't work.  It's very...if it doesn't work, fix ALL of it.

If you are in an accident and you get your left arm and right leg chopped off,
do you think they are going to put you in to two seperate operating rooms for
each limb?

It doesn't matter how many aspects of the same problem there are as long as they
get fixed.  Right now IE still remains superior in many ways (except for it's
win95 network cancel button nature) as far as ease of use goes.  Ease of use and
security should not be a compromise.

Anyway I fail to see any noticeable end user changes from .9 to .91 other then a
different skin.  Skins are great and all, but scrollable fields that don't ****
off Mother Teresa would be great too.

Also another good point, where the heck do you go to officially make a feature
request officially?  Unfortunitly Moz's site is as horridly organized as W3's site.
Comment 128 Robert Parenton 2004-07-17 22:28:59 PDT
Comment #127, this is not the place for these comments.  Sorry for the bugspam
for everyone else.
Comment 129 Jon Reid 2004-07-18 00:41:56 PDT
Agree with Comment 126.  

Also, I was wrong in my Comment 115; for scrolling via a mouse wheel, cursor
position determines what should scroll in both Windows and Mac UI paradigms.  My
apologies for the misinformation, I was confusing "mouse wheel scroll focus" and
"keyboard scroll focus."  Bad interface designer, no biscuit.

Mats, the behavior you describe in Comment 117 sounds like the right way to do
this.  Great work.
Comment 130 Robert Kaiser 2004-07-18 05:33:25 PDT
As there is a patch and I think this long-awaited fix would do good to get some
testing before Seamonkey 1.8 completes (and this is already plussed for aviary
branch), requesting blocking1.8a3 flag.
Comment 131 Mats Palmgren (vacation) 2004-07-18 07:58:05 PDT
I have spawned the keyboard scrolling part to bug 251986 (and fixed it too).
This bug is about mouse scrolling only.  Taking bug.
Comment 132 Mats Palmgren (vacation) 2004-07-18 16:14:05 PDT
Created attachment 153610 [details] [diff] [review]
Patch B rev. 2

After some more thought and comparing my first patch to what IE6 does
I really think we should go all the way like they did.
That is, don't give priority to the keyboard focus element as I
described in comment 117. Instead, only scroll what is under the
mouse. A believe this model is easier to grasp for users
(including myself :-). To sum up:
Mouse scrolling scrolls whatever is under the mouse pointer -
   it does not consider keyboard focus or change it any way.
   When a scrollbar end position is reached, continue with closest
   enclosing scrollable element etc.
Keyboard scrolling (bug 251986) scrolls the closest scrollable
   element starting at the caret (where the user last clicked).
   It does not consider what is under the mouse at all.

This makes the two methods of scrolling "orthogonal" as I see it,
and I think that is good.  This is also what IE6 does, with a couple
of exceptions: 
1. I made SELECT lists behave as any other element (IE6 does not).
2. Combobox drop down menus - in IE6 you can move the mouse outside
   the menu and still scroll it. Mozilla closes the menu (bad!) and
   scrolls what is under the mouse. I actually prefer the IE6 way
   but I haven't changed it in this patch. It can be handled
   in a separate bug (if not reported already).
3. Location bar drop down menu has a similar issue as 2.
   I will report that separately too (and post the bug numbers here.)

There is a bit of ugliness in this patch to handle the drop down
menus of comboboxes/location bar, suggestions for improvements
is appreciated. The problem is when traversing up the view hierarchy
from a ScrollbarFrame (or descendant) we end up "above" the combo.
It would be nice if one could detect such "posted" views somehow
and get to the "principal" frame...

This patch also fixes bug 251986.
Comment 133 Mats Palmgren (vacation) 2004-07-18 16:16:55 PDT
Created attachment 153611 [details] [diff] [review]
Patch B rev. 2 (diff -uw)
Comment 134 Mats Palmgren (vacation) 2004-07-18 17:05:32 PDT
"Patch B rev. 2" also fixes bug 78786 is what I meant to say (not bug 251986).
Comment 135 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-07-21 16:37:04 PDT
One comment (more later): aTargetFrame is never null, so the large chunks of
code for what to do when it's null aren't necessary.
Comment 136 Ben Goodger (use ben at mozilla dot org for email) 2004-07-22 12:03:18 PDT
Either this gets review and is checked in in the next week or so, or it may miss
the aviary 1.0 train. 
Comment 137 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-22 19:59:54 PDT
+  if (targetContent->Tag() == nsXULAtoms::slider ||
+      targetContent->Tag() == nsXULAtoms::thumb ||
+      targetContent->Tag() == nsXULAtoms::scrollbarbutton ||
+      targetContent->Tag() == nsXULAtoms::scrollbar ||
+      targetContent->Tag() == nsXULAtoms::gripper) {

This is pretty yucky. So is the magic number "5" below it. Can you explain why
all this is necessary? It seems to me that if you start at the target frame and
walk up the frame hierarchy, looking for frames that implement
nsIScrollableViewProvider, and stop at the first one that does, then it will
give you the right view. Why doesn't that work?
Comment 138 Mats Palmgren (vacation) 2004-07-23 00:08:58 PDT
Created attachment 154072 [details]
Frame hierarchy with scrolling aspects

Roc, your suggestion seems to work just fine, thanks!  I guess I was to afraid
of changing what was already there - try to get a scrollbar provider first and
if none found, try with GetNearestScrollingView().  That seems wrong as you
can see from this trace output.

As far as I can see, we can walk the frame hierarchy looking for the nearest
scroll view provider and just skip walking the view hierarchy looking for the
nearest scrollable view altogether.

The question is, do all scrollable views have a corresponding frame with a
provider to serve it up?  and given an arbitrary frame with a view, is the
nearest provider always the nearest scrollable view?  I assume there is 
never a case where my nearest scrollable view belongs to a frame sibling
for example?

I will write a new patch assuming that's correct and also address David's
comment. This should simplify the code and get rid of the ugly bits.
Comment 139 Mats Palmgren (vacation) 2004-07-23 02:56:57 PDT
Created attachment 154083 [details] [diff] [review]
Patch B rev. 3
Comment 140 Mats Palmgren (vacation) 2004-07-23 02:58:49 PDT
Created attachment 154084 [details] [diff] [review]
Patch B rev. 3 (diff -uw)
Comment 141 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-23 03:54:42 PDT
(In reply to comment #138)
> The question is, do all scrollable views have a corresponding frame with a
> provider to serve it up? 

Yes, I think so.

> and given an arbitrary frame with a view, is the nearest provider always the
> nearest scrollable view?

Should be.

> I assume there is 
> never a case where my nearest scrollable view belongs to a frame sibling
> for example?

Shouldn't be.

Thanks, the patch is much cleaner now. If this doesn't work for some reason
we'll find out and fix it :-).
Comment 142 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-23 03:57:42 PDT
Comment on attachment 154083 [details] [diff] [review]
Patch B rev. 3

looks OK to me now
Comment 143 John A. Bilicki III 2004-07-23 13:44:54 PDT
I'm not a programmer but I care as much about the development of Mozilla as
anyone here.  Where can I learn to patch Mozilla the way you folks are so I can
see the results as they come out on this bug? / thanks! :-)
Comment 144 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-07-23 13:47:10 PDT
Comment on attachment 154083 [details] [diff] [review]
Patch B rev. 3

As long as this change doesn't prevent comboboxes from being scrolled with the
keyboard when they're not dropped down, sr=dbaron.
Comment 145 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-07-23 13:58:42 PDT
Comment on attachment 154083 [details] [diff] [review]
Patch B rev. 3

Actually, no, there are still some things I don't like about this.  More in a
minute...
Comment 146 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-07-23 14:04:16 PDT
Comment on attachment 154083 [details] [diff] [review]
Patch B rev. 3

Actually, never mind -- I was misreading something.  As long as this doesn't
break keyboard scrolling of comboboxes, that is.  (I'm not sure what's used for
wheel scrolling and what's used for keyboard scrolling.  While you're here, it
might be nice to document that, actually.)

But one more thing:

>+  if (!passToParent && scrollView) {

I'm pretty sure scrollView is guaranteed to be non-null if passToParent is
false, so you can drop the scrollView test and turn this into an if/else rather
than two ifs.
Comment 147 Mats Palmgren (vacation) 2004-07-23 16:51:45 PDT
nsEventStateManager::DoScroll* is used for "mouse-wheel" scrolling only.
Keyboard scrolling goes exclusively through the nsPresShell methods (bug
251986). Drag-select-auto-scrolling lives in nsSelection.cpp and JS scrollBy*
etc lives in nsGlobalWindow.cpp but that code operates directly on scroll
views and are unaffected by my changes as far as I can see.

>+  if (!passToParent && scrollView) {

No, there are three possible states after the search loop:
!passToParent && scrollView  -- we found a view that should be scrolled
!passToParent && !scrollView -- found combobox dropdown at end position case
passToParent                 -- otherwise, recurse with parent document

Yes, keyboard scrolling of not dropped down comboboxes still works as before
with both this patch and the patch in bug 251986 applied.

Note that you may get a CVS conflict on the ESM::GetNearest* method that was
moved by bug 251986, while that line is now gone in the latest patch here.
Comment 148 Mats Palmgren (vacation) 2004-07-24 00:43:07 PDT
> so you can drop the scrollView test and turn this into an if/else rather
> than two ifs

I could do an early "return NS_OK" for the combobox case and then only have one
"if(!passToParent)/else", if that is preferred.

Also, GetParentScrollingView() is only used by DoScrollText() and can be
removed, making DoScrollText() iterative instead. OTOH, a recursive call is only
made when you scroll a IFRAME/FRAME and reach the end.
Comment 149 chris hofmann 2004-07-30 15:14:01 PDT
what are the next steps that are needed here for the aviary 1.0 branch.
Comment 150 Mats Palmgren (vacation) 2004-08-05 06:48:57 PDT
*** Bug 254408 has been marked as a duplicate of this bug. ***
Comment 151 Mats Palmgren (vacation) 2004-08-07 12:38:56 PDT
Checked in to trunk 2004-08-07 07:30 PDT

I have checked all URLs/testcases here and on dupes and they work now.

-> FIXED
Comment 152 Mats Palmgren (vacation) 2004-08-07 13:54:53 PDT
*** Bug 229175 has been marked as a duplicate of this bug. ***
Comment 153 Mats Palmgren (vacation) 2004-08-07 14:47:06 PDT
*** Bug 234236 has been marked as a duplicate of this bug. ***
Comment 154 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-08-08 15:10:07 PDT
*** Bug 254808 has been marked as a duplicate of this bug. ***
Comment 155 Ivan Sagalaev 2004-08-09 01:43:07 PDT
This bug has 'blocking-aviary1.0' flag set but the patch doesn't have a request
for approval to check it in to aviary branch. Who should make it then?
Comment 156 Alan MacDonald 2004-08-13 08:40:38 PDT
Any particular reason why this hasn't been integrated into the Aviary branch yet?
Comment 157 Ryan Polk (Quark) 2004-08-14 04:26:52 PDT
Comment on attachment 154083 [details] [diff] [review]
Patch B rev. 3

Putting on the approvers' radar
Comment 158 Ger Teunis 2004-08-16 23:31:26 PDT
Is it possible to checked this one in into the aviary as well?
Comment 159 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-08-17 07:03:20 PDT
I'm not convinced this should go into Aviary. It's a pretty significant change
and at this late date it could destabilize the branch (and the 1.7 branch). This
bug is not critical.
Comment 160 Tom 2004-08-17 07:20:47 PDT
I dare to not agree. The bug might not be critical for simple viewing pages.
However, FF is not to be a mediocre browser after all! We all want the 1.0 to be
the ultimate browser in the space. Never mind, if the launch slips back a couple
of weeks.
Comment 161 Michiel Toneman 2004-08-17 07:32:12 PDT
(In reply to comment #159)
> I'm not convinced this should go into Aviary. It's a pretty significant change
> and at this late date it could destabilize the branch (and the 1.7 branch). This
> bug is not critical.

Whether or not this bug is critical depends on your point of view. If you are
defending your choice for a frameless CSS2 design to your client and something
simple like scrolling doesn't work, this bug seems very critical indeed.
Comment 162 Jon Reid 2004-08-17 10:47:00 PDT
(In reply to comment #159)
> I'm not convinced this should go into Aviary. It's a pretty significant change
> and at this late date it could destabilize the branch (and the 1.7 branch).
> This bug is not critical.

Shpff.

Okay, I'll grant it's not critical in the strictest meaning of the word in the
context of development.  But in terms of the overall quality of the product,
this is most <em>definitely</em> critical.  This bug has over a hundred votes,
and has been waiting for a fix for three years.  Furthermore, the fix is a
significant fix in the UI capability of the engine, and without it the engine is
<em>broken</em>.  I think it's important to emphasize that point:  without this
fix, the engine <em>does not work correctly</em>.  This isn't some whiz-bang
gosh-wouldn't-that-be-nice improvement, this is something that makes the engine
work as it should in an important and commonly-used way.

The fix should be checked into the Aviary and included in the release.  If that
means extra testing to meet the release deadline, I'm willing to put in the time
and effort.
Comment 163 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-08-17 11:05:12 PDT
The point is that the Aviary team chose to use 1.7, which they knew in advance
would be quite old by the time they shipped.  They chose to do that because they
wanted stability more than the new Gecko features that would be in 1.8.  If
people end up porting half of the stuff landing for 1.8 to the Aviary branch
without the input of the Gecko developers who wrote the patches, they could end
up with problems because of missing dependencies, lack of testing of the patches
on the Aviary branch by the people who wrote them and know what they're supposed
to do, etc.
Comment 164 Alan MacDonald 2004-08-17 11:20:43 PDT
(In reply to comment #163)
> The point is that the Aviary team chose to use 1.7, which they knew in advance
> would be quite old by the time they shipped.  They chose to do that because they
> wanted stability more than the new Gecko features that would be in 1.8.

This isn't a new 'feature' though, it's a fix for a broken UI.
Comment 165 Ger Teunis 2004-08-17 12:49:23 PDT
(In reply to comment #163)
> The point is that the Aviary team chose to use 1.7, which they knew in advance
> would be quite old by the time they shipped...

They checkin a lot of patches into the Trunk as well into the Aviary. This bug
is marked "blocking-aviary1.0" already, so a fix is required for 1.0 release.
Comment 166 Ger Teunis 2004-08-22 15:22:51 PDT
Mats Palmgren: could you please give some reaction on why this is not checked in
into the aviary-branch yet?
Comment 167 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-08-23 01:46:09 PDT
*** Bug 256517 has been marked as a duplicate of this bug. ***
Comment 168 Mike Pinkerton (not reading bugmail) 2004-08-23 11:46:34 PDT
i think this checkin regressed scrollwheel behavior in camino on 10.2, see bug
256538.

ideas?
Comment 169 Mats Palmgren (vacation) 2004-08-26 17:31:48 PDT
Yes, this probably caused bug 256538 (an extreme edge case IMO ;-).

Regarding checkin on branches, please don't bug me about that. It's not my
decision, it's the drivers. Two of them have already commented (comment 159 and
comment 163).
Comment 170 Mike Pinkerton (not reading bugmail) 2004-08-27 05:44:13 PDT
(In reply to comment #169)
> Yes, this probably caused bug 256538 (an extreme edge case IMO ;-).

So, um, does that mean someone will fix 256538? should i reassign it to you?
Comment 171 Brendan Eich [:brendan] 2004-08-27 18:56:34 PDT
Until the regression(s) this caused are fixed, there's no way you can argue it
should land in aviary (and 1.7) with a straight face.

Requirements management 101: you *will* ship with bugs; you can't fix them all;
you can't slip "just a few weeks" for any one bug, or you will never ship.  If
you have to wait for Firefox 1.x to get joy here, and we ship a generally great
1.0, so be it.

Bug votes don't mean a thing for testing, fixing regressions, actually doing
work, and standing behind it, so please stop citing them.

/be
Comment 172 Alan MacDonald 2004-08-27 20:12:34 PDT
(In reply to comment #171)
> Until the regression(s) this caused are fixed, there's no way you can argue it
> should land in aviary (and 1.7) with a straight face.
> 

I think that is fairly obvious and no one is arguing that way now.  At the time
we were discussing this, there weren't any sign of regressions, but thanks for
the lesson.
Comment 173 John A. Bilicki III 2004-08-30 22:42:43 PDT
IE - Encased elements override attributes of the elements they are redered within.

Opera - 7 versions and the interface is still lacking.

Gecko - Simple things like not being able to scroll in certain elements.

As far as I'm concerned there is no perfect browser.  They all **** me off in
one sense or another both as a user and a developer.

What my question is, if this bug has been around before the 9-11 attacks how
come it hasn't been fixed?

Why is this bug marked as resolved fixed?  It's not resolved fixed until we
download it and the feature works...
Comment 174 Robert Kaiser 2004-08-31 04:54:57 PDT
John:
Try to learn the process of open source software and of bugzilla bug reports
before accusing people of doing wrong things.
1) When a bug gets fixed, does mostly depend on finding a volunteer to work on
the issue (additionally to getting module owner and sr to accept/support a given
patch). It took quite a long time in this case until someone decided to really
work on the issue, all others only did complain, but that doesn't get the job
done. Basic open soure software rule: If you really want something fixed, get a
patch done yourself. That's the only really efficient way.
2) This issue is fixed now in the current development source code ("trunk"),
that's why it's marked FIXED. Daily snapshots of that source get compiled and
are available as "nighty builds" on the Mozilla web pages. All releases off the
"trunk" code also contain the fix, in this case Mozilla 1.8 alpha 3 should
already have it, so use that if you really need the fix.
Comment 175 John A. Bilicki III 2004-08-31 11:44:09 PDT
Thanks for the info...

I am curious, does the Moz team release nightly builds of Firefox?

Mozilla 1.8.0.2004083108 besides less customizable interface works perfect
except they have the right click delete rename reversed and I kept on deleting
bookmarks as I added them and went to give them more conservative names.
Comment 176 José Jeria 2004-09-06 10:09:59 PDT
*** Bug 258186 has been marked as a duplicate of this bug. ***
Comment 177 Asa Dotzler [:asa] 2004-09-08 16:52:28 PDT
Comment on attachment 154083 [details] [diff] [review]
Patch B rev. 3

not this late in the game and think we have trunk regressions for this.
Comment 178 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-09-12 14:39:56 PDT
*** Bug 259010 has been marked as a duplicate of this bug. ***
Comment 179 John A. Bilicki III 2004-09-15 16:20:17 PDT
Firefox 1.0 PR has been released and this bug is still part of the Gecko engine.

Will the official 1.0 release still have this bug or not?
Comment 180 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-09-15 18:03:56 PDT
I hope so
Comment 181 scratch 2004-09-15 18:11:08 PDT
if you guys actually read the bug before replying, you'd know the answer is no.
 it will be fixed in subsequent releases of firefox, but it's too risky to add
this close to 1.0.
Comment 182 John A. Bilicki III 2004-09-15 19:50:04 PDT
It is fixed in 1.8 Alpha of Mozilla.

Although I'm not a programmer I fail to see how making a field scrollable can
muck things up as badly as you seem to make it.
Comment 183 André Schild 2004-09-15 22:46:54 PDT
The problem with such a fix is, that it can screw up the whole
layout on the screen.

After all, the scrollable element must get some sort of focus
and usually it is visible to the user which element has the focus.

Second, rendering a scrollbar or not has a very big impact on the
layout.

The other part is the way this had been fixed.
I don't know the details, but there are changes that some internal
controll flow is changed, and such changes aren't reasonable to be put
in the release branch.
Comment 184 Henrik Pauli 2004-09-15 23:14:33 PDT
Then again, André, the scrollbars have been rendered for quite a while -- that
hasn't changed, at least I doubt it has. :)

Shame it can't make it into Ff1, would have been a great little fix to have in
there.
Comment 185 shadytrees 2004-09-18 08:06:02 PDT
> I am curious, does the Moz team release nightly builds of Firefox?
Yes. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Comment 186 José Jeria 2004-09-27 12:00:34 PDT
*** Bug 261807 has been marked as a duplicate of this bug. ***
Comment 187 Stefan Borggraefe 2004-09-30 06:48:22 PDT
*** Bug 262271 has been marked as a duplicate of this bug. ***
Comment 188 José Jeria 2004-10-08 11:01:19 PDT
*** Bug 263507 has been marked as a duplicate of this bug. ***
Comment 189 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-10-12 12:02:40 PDT
*** Bug 264039 has been marked as a duplicate of this bug. ***
Comment 190 Phil Ringnalda (:philor, back in August) 2004-10-16 00:26:03 PDT
*** Bug 259310 has been marked as a duplicate of this bug. ***
Comment 191 Phil Ringnalda (:philor, back in August) 2004-10-16 00:27:17 PDT
*** Bug 263372 has been marked as a duplicate of this bug. ***
Comment 192 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-10-17 17:17:11 PDT
*** Bug 264826 has been marked as a duplicate of this bug. ***
Comment 193 Kevin Brosnan 2004-11-08 16:38:42 PST
*** Bug 268004 has been marked as a duplicate of this bug. ***
Comment 194 Destian 2004-11-08 16:53:39 PST
Hopefully getting this fix in there will be of high priority after the 1.0
launch tomorrow. 

/me coughs
Comment 195 José Jeria 2004-11-09 11:54:43 PST
*** Bug 268638 has been marked as a duplicate of this bug. ***
Comment 196 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-11-26 05:26:56 PST
*** Bug 271830 has been marked as a duplicate of this bug. ***
Comment 197 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-26 16:45:34 PST
*** Bug 271937 has been marked as a duplicate of this bug. ***
Comment 198 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-28 14:45:43 PST
*** Bug 266404 has been marked as a duplicate of this bug. ***
Comment 199 Stefan Borggraefe 2004-11-29 03:03:58 PST
*** Bug 272214 has been marked as a duplicate of this bug. ***
Comment 200 PikeUK 2004-11-30 03:44:28 PST
*** Bug 272231 has been marked as a duplicate of this bug. ***
Comment 201 PikeUK 2004-12-01 07:49:56 PST
*** Bug 272592 has been marked as a duplicate of this bug. ***
Comment 202 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-02 11:43:40 PST
*** Bug 272832 has been marked as a duplicate of this bug. ***
Comment 203 Phil Ringnalda (:philor, back in August) 2004-12-08 15:30:58 PST
*** Bug 273792 has been marked as a duplicate of this bug. ***
Comment 204 Phil Ringnalda (:philor, back in August) 2004-12-11 11:35:24 PST
*** Bug 274207 has been marked as a duplicate of this bug. ***
Comment 205 Bill Mason 2004-12-17 19:50:37 PST
*** Bug 275128 has been marked as a duplicate of this bug. ***
Comment 206 José Jeria 2004-12-19 05:42:45 PST
*** Bug 275261 has been marked as a duplicate of this bug. ***
Comment 207 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-30 15:21:29 PST
*** Bug 276524 has been marked as a duplicate of this bug. ***
Comment 208 Mats Palmgren (vacation) 2005-01-08 02:06:34 PST
*** Bug 277517 has been marked as a duplicate of this bug. ***
Comment 209 David Holmes 2005-01-08 04:36:55 PST
Hello all ye persons regularly spammed by "*** Bug xyzabc has been marked as a
duplicate of this bug. ***" messages for apparently RESOLVED & FIXED bug 97283.

Sorry to contribute yet another such email after moaning about the phenomenon,
but at least this one contains a (very, very evident) question :

When can we at last expect to constate corrected behaviour regarding this bug in
a mainstream Firefox release ?

I've just counted : that's been 22 consecutive "*** marked duplicate ***"
notices  (with one break). Why ? Because the topic of 97283, that received
precedence over all dupes, is probably extremely relevant, but -- with all due
respect to the original poster -- is practically useless. Every dupe-poster
excuses himself for having made unfruitful though multiple searches in the
database before posting. I was one myself. No hard feelings here, just plenty of
time lost.

Why else ? Because it's not in the mainstream ! I read in one of the comments,
by someone who obviously knew what was going on, that the fix involves quite a
basic level of flow control, and is therefore perhaps unfit for wide
distribution. Hence the fix is currently only present in some branch of Mozilla.

Is this for testing purposes ? Are we just waiting a reasonable amount of time
to decide that the fix does not bring up any other issues, before incorporating
it in the most widespread product ? Sounds reasonable -- but please _tell_ us if
such is the case. I'm certainly not managing to read it in any of the BugZilla
bug info.

Or if the reason is different, then please let us know about it as well. I just
hope that nobody here is questioning the fact that this is a fix which _must_ go
mainstream -- IE has it (ok, not a valid argument), but gee, you'd think we were
promoting <frame>s here ! (shudder)

And if it's just a question of getting round to incorporating it in the Firefox
code, with respect to how deep the fix goes, well then this was my encouragement
to the very courageous team of Mozilla developers, which I wish I could join,
but to which I donated instead in the mean time. Keep up the excellent work --
incorporating this fix on the way. Thank you.

There, that was breaking the monotony of mails on the subject of this bug.

Thank you in advance for answers.

David Holmes
Comment 210 Robert Kaiser 2005-01-08 05:08:43 PST
(In reply to comment #209)
> When can we at last expect to constate corrected behaviour regarding this bug in
> a mainstream Firefox release ?

Please go ranting somewhere else, as if you have read the information available
you have realized that your comment doesn't help anything.
Firefox 1.0 is based on the Mozilla 1.7 branch (par with Mozilla 1.7.5), and
that change was too risky to go into that long-lived stable branch (see the
minused flags for 1.7 and aviary).
Firefox 1.1 (expected in March) will be based on the Mozilla 1.8 codebase, which
does/will include this fix, among others. Until Mozilla 1.8 and FF 1.1 there
will be no "stable" release containing this and other fixes of the 1.8 release
cycle.
Comment 211 David Holmes 2005-01-08 05:19:30 PST
(In reply to comment #210)

> Please go ranting somewhere else, as if you have read the information available
> you have realized that your comment doesn't help anything.

Sorry about the ranty feeling, it was indeed intentional.
I'm absolutely certain, you see, that I'm not the only one who had not figured
out the following information :

> Firefox 1.0 is based on the Mozilla 1.7 branch (par with Mozilla 1.7.5), and
> that change was too risky to go into that long-lived stable branch (see the
> minused flags for 1.7 and aviary).

Ah, I thought it had to have something to do with them flags. I had indeed
deduced that incorporation into FF 1.0 had been "denied".

> Firefox 1.1 (expected in March) will be based on the Mozilla 1.8 codebase, which
> does/will include this fix, among others.

Thank you ! That it absolutely all I wanted to know. Sorry again if it is
glaringly visible in the info, but thank you for having made it clear in these
human-readable comments.

I hope all this wasn't too much bother to bring that little, though essential,
piece of information to all others who were wondering at the same thing as me.

Thanks again (sincerely).

David Holmes

Comment 212 John A. Bilicki III 2005-01-09 22:43:33 PST
This bug also seems fixed in Netscape 8 thankfully.  I have been using Nightly
Builds of FF because my site is a dynamically rendered scrolling DIV.  Gecko 1.8
marks the first stable perfected state of the Gecko engine ... though in regards
to creative purposes this bug has existed long since the Netscape 6 days.
Comment 213 José Jeria 2005-01-28 10:40:27 PST
*** Bug 280213 has been marked as a duplicate of this bug. ***
Comment 214 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-02-16 05:53:32 PST
*** Bug 282456 has been marked as a duplicate of this bug. ***
Comment 215 José Jeria 2005-02-19 03:19:02 PST
*** Bug 282815 has been marked as a duplicate of this bug. ***
Comment 216 PikeUK 2005-03-02 01:03:21 PST
*** Bug 284401 has been marked as a duplicate of this bug. ***
Comment 217 PikeUK 2005-03-08 07:18:51 PST
*** Bug 285279 has been marked as a duplicate of this bug. ***
Comment 218 Michiel van Leeuwen (email: mvl+moz@) 2005-03-09 02:34:24 PST
*** Bug 285420 has been marked as a duplicate of this bug. ***
Comment 219 Mats Palmgren (vacation) 2005-03-10 03:27:23 PST
*** Bug 285522 has been marked as a duplicate of this bug. ***
Comment 220 John A. Bilicki III 2005-03-13 17:45:34 PST
I want to be removed from getting emails from this list but I'm not in the CC
list?  Someone please remove me! Thanks...
Comment 221 Bogdan Stroe 2005-03-14 00:37:24 PST
(In reply to comment #220)
> I want to be removed from getting emails from this list but I'm not in the CC
> list?  Someone please remove me! Thanks...

You get emails because you voted for this bug. You can remove your vote, or edit
the bugzilla preferences (visit a bug in Bugzilla and go to Edit Prefs in the
footer of the page).
Comment 222 John A. Bilicki III 2005-03-14 15:10:53 PST
Got it, thanks.
Comment 223 José Jeria 2005-03-29 09:52:58 PST
*** Bug 288034 has been marked as a duplicate of this bug. ***
Comment 224 José Jeria 2005-03-29 09:53:31 PST
*** Bug 288035 has been marked as a duplicate of this bug. ***
Comment 225 irongut 2005-03-29 13:12:14 PST
*** Bug 241418 has been marked as a duplicate of this bug. ***
Comment 226 R.K.Aa. 2005-03-30 21:36:14 PST
*** Bug 288372 has been marked as a duplicate of this bug. ***
Comment 227 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-05 16:56:38 PDT
*** Bug 289213 has been marked as a duplicate of this bug. ***
Comment 228 Steve England [:stevee] 2005-04-16 14:32:30 PDT
*** Bug 290621 has been marked as a duplicate of this bug. ***
Comment 229 Gilles Durys 2005-04-19 03:04:56 PDT
*** Bug 290934 has been marked as a duplicate of this bug. ***
Comment 230 Matthias Versen [:Matti] 2005-04-19 15:59:46 PDT
*** Bug 291041 has been marked as a duplicate of this bug. ***
Comment 231 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-04-26 08:09:35 PDT
*** Bug 291942 has been marked as a duplicate of this bug. ***
Comment 232 Kevin Brosnan 2005-04-26 11:58:24 PDT
*** Bug 291976 has been marked as a duplicate of this bug. ***
Comment 233 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-04-27 04:28:53 PDT
*** Bug 292070 has been marked as a duplicate of this bug. ***
Comment 234 Kevin Brosnan 2005-05-20 14:54:24 PDT
*** Bug 294985 has been marked as a duplicate of this bug. ***
Comment 235 Kyle Denney 2005-05-20 15:01:14 PDT
(In reply to comment #234)
> *** Bug 294985 has been marked as a duplicate of this bug. ***

See bug 294985 for an oddity about this bug. If you drag and drop a link inside
the div, scrolling works. (details in bug 294985)
Comment 236 Henrik Pauli 2005-05-20 15:07:13 PDT
Good catch there.  If there's an active link in the div, it works.  And
activating one can be achieved by dragging and dropping it somewhere empty on
the div.

Now, this bug seems to be fixed in the 1.8, so whenever Suites and Firefoxes
start rolling out on that codebase (you can of course try nightlies), you're
already rid of the bug.
Comment 237 Peter Grabner 2005-05-20 17:53:23 PDT
(In reply to comment #236)
> Good catch there.  If there's an active link in the div, it works.  And
> activating one can be achieved by dragging and dropping it somewhere empty on
> the div.
> 
> Now, this bug seems to be fixed in the 1.8, so whenever Suites and Firefoxes
> start rolling out on that codebase (you can of course try nightlies), you're
> already rid of the bug.

It should have something to do with focus/event. - Have seen that it works too,
if you click a textfield in such div or click a mailto-link (opens email client).
after that you can sroll the div til you click outside.
Comment 238 Peter Grabner 2005-05-20 18:13:28 PDT
(Addition to comment #237)
Instead of scrolling whith the mouse wheel it should also work when dragging
with the mid-button of a 3-button-mouse.
In that cases when you have "activated" the "focus" on the div (like #236) and
the mouse wheel works for scrolling, - the 3-button-mouse does it in no way.
Comment 239 Destian 2005-05-24 17:39:53 PDT
 I was under the impression that autoscrolling, in addition to mousewheel
scrolling, would be fixed in gecko 1.8, but in the latest Fx nightlies (1.8b2) I
still cannot autoscroll.

I'm sorry to bring up what appears to be a sore subject. If there is something I
have misunderstood could someone please drive it through my thick skull? Is
there a seperate bug for the broken autoscrolling within divs using
overflow:auto/scroll? If not, should there be? Should this be reopened?

The only explanation I can think of is that it will be fixed in the 1.8 final
but not in b2, but that doesn't make sense to me.

Any help will be greatly appreciated. This bug has been bothering me for a long
time as I find divs with scrolling to be extremely useful in design. I would
just like to understand what is going on.

Thank you.
Comment 240 jery_wang2002 2005-05-24 22:31:26 PDT
Funny, the status of this bug is -RESOLVED-?????

I too wait for this bug to be solved, I reported this few months back and tons
of other people.

IE does not have this problem. But I love to use firefox, I just hope that
firefox fix this soon.

(In reply to comment #239)
>  I was under the impression that autoscrolling, in addition to mousewheel
> scrolling, would be fixed in gecko 1.8, but in the latest Fx nightlies (1.8b2) I
> still cannot autoscroll.
> 
> I'm sorry to bring up what appears to be a sore subject. If there is something I
> have misunderstood could someone please drive it through my thick skull? Is
> there a seperate bug for the broken autoscrolling within divs using
> overflow:auto/scroll? If not, should there be? Should this be reopened?
> 
> The only explanation I can think of is that it will be fixed in the 1.8 final
> but not in b2, but that doesn't make sense to me.
> 
> Any help will be greatly appreciated. This bug has been bothering me for a long
> time as I find divs with scrolling to be extremely useful in design. I would
> just like to understand what is going on.
> 
> Thank you.
Comment 241 José Jeria 2005-05-25 00:27:55 PDT
(In reply to comment #239)
> still cannot autoscroll.

What system are you on?

(In reply to comment #240)
> Funny, the status of this bug is -RESOLVED-?????

Please dont add the entire last message when replying, also, what version/system
are you using?
Comment 242 Christian :Biesinger (don't email me, ping me on IRC) 2005-05-25 07:38:56 PDT
(In reply to comment #239)
>  I was under the impression that autoscrolling, in addition to mousewheel
> scrolling, would be fixed in gecko 1.8

"gecko"? autoscrolling is implemented in frontend code. so that sounds like a
different bug.
Comment 243 Destian 2005-05-25 22:54:56 PDT
(In reply to comment #241)
> (In reply to comment #239)
> > still cannot autoscroll.
> 
> What system are you on?
winxp sp2

Comment 244 Lukas Petrovicky (CZilla) 2005-05-29 23:37:42 PDT
I can confirm that *autoscrolling does not work*. (see http://www.petrovicky.net/)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050529
Firefox/1.0+
Someone should REOPEN this as I don't feel like doing it myself.
Comment 245 Matthew Cheale 2005-05-30 01:27:03 PDT
It's not the mousewheel scrolling part that's not working.  It's a case of
getting the focus to the right element.  Go to your site, CTRL-Click a link and
then go back to the page, assuming it opening in another tab/window.  You'll now
find that the mouse wheel scrolling is effective.  As such I would say this bug
is affected by another bug that should be or is already filed seperatly, I
haven't checked.

Something like, "mouse wheel event over block element with scroll: auto style
doesn't make block element focused".
Comment 246 Lukas Petrovicky (CZilla) 2005-05-30 02:30:33 PDT
(In reply to comment #245)
> It's not the mousewheel scrolling part that's not working.  It's a case of
> getting the focus to the right element.  Go to your site, CTRL-Click a link and
> then go back to the page, assuming it opening in another tab/window.  You'll now
> find that the mouse wheel scrolling is effective.

For me, it isn't. The mouse wheel scrolling itself is alright, but the
autoscrolling feature doesn't work even if I manage to get the right focus.
White circle appears with arrows in it, but when I move the mouse, scrolling
doesn't happen.
Comment 247 José Jeria 2005-05-30 02:36:49 PDT
I see what you guys mean now, the scrolling doesn't work when using the
autoscroll feature, it does work with the mousewheel though. And that is what
this bug is about. Please file a new bug for the autoscroll issue. Post the bug
number here.
Comment 248 Destian 2005-05-30 08:18:23 PDT
(In reply to comment #247)
> I see what you guys mean now, the scrolling doesn't work when using the
> autoscroll feature, it does work with the mousewheel though. And that is what
> this bug is about. Please file a new bug for the autoscroll issue. Post the bug
> number here.

"Mouse wheel scrolling does not work for elements such as div using overflow -
***auto*** or scroll"

The description implies that this bug is both about the normal wheel scrolling
and the auto, so perhaps the title should be changed? I agree that this is a
different problem.

New bug: https://bugzilla.mozilla.org/show_bug.cgi?id=295977
Comment 249 Matthew Cheale 2005-05-30 08:36:41 PDT
'auto' and 'scroll' are two settings for the CSS property 'overflow'.  Both
result in scrollbars, the title refers to this and not a mouse interface system.
Comment 250 Destian 2005-05-30 09:56:30 PDT
Yeah, I'm at least mildly retarded. I actually wrote that message after filing
the new bug and writing "1. Create a <div> with overflow:auto or overflow:scroll
which contains enough data to require scrolling."

Scary.

My apologies.
Comment 251 Matthias Versen [:Matti] 2005-06-06 03:42:20 PDT
*** Bug 296805 has been marked as a duplicate of this bug. ***
Comment 252 Frank Wein [:mcsmurf] 2005-06-19 03:01:22 PDT
*** Bug 298146 has been marked as a duplicate of this bug. ***
Comment 253 Erik Johnson 2005-06-23 15:06:20 PDT
When is this bug fix going to make it into a release?  It appears to have been 
fixed since July of last year, but as of Mozilla 1.7.8, div tags still do not 
scroll with the mouse wheel.
Comment 254 timeless 2005-06-23 15:40:15 PDT
erik.johnson@grainger.com: 1.7 was branched in early april 2004. use something
that isn't based on 1.7.
Comment 255 Erik Johnson 2005-06-24 08:23:48 PDT
Thanks for the suggestion... but I'm extremely new to all this.  What's 
available that's not "based on 1.7"?  1.8 beta?  I'm not sure where to go with 
this.
 
Thanks in advance for any more help,
 
--- Erik Johnson
erik.johnson@grainger.com
Comment 256 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-06-30 10:24:31 PDT
*** Bug 299264 has been marked as a duplicate of this bug. ***
Comment 257 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-07-05 07:52:40 PDT
*** Bug 263929 has been marked as a duplicate of this bug. ***
Comment 258 alex 2005-07-14 12:47:49 PDT
My Firefox 1.0.4 still has this Bug, and its very annoying!
Can someone reopen the Bug and fix it then?
Comment 259 alex 2005-07-14 12:55:47 PDT
My Firefox 1.0.4 still has this Bug, and its very annoying!
Can someone reopen the Bug and fix it then?
Comment 260 Christian :Biesinger (don't email me, ping me on IRC) 2005-07-14 13:02:48 PDT
this won't be fixed on 1.0.x.
Comment 261 Robert Kaiser 2005-07-14 13:03:58 PDT
(In reply to comment #259)
> My Firefox 1.0.4 still has this Bug, and its very annoying!
> Can someone reopen the Bug and fix it then?

No, noone will reasonably reopen it. It _is_ fixed in current devlopment
versions, and the first stable Firefox release with this fix will be 1.1, it
will not ever make it's way into any Firefox 1.0.x release.

To say it clear again: All current testing builds ("Deer Park" Alphas and
SeaMonkey nightly builds) have this fixed, so Firefox 1.1 and SeaMonkey 1.0 will
work correctly. It will not be ported back to any older release.
Comment 262 Destian 2005-07-14 13:07:43 PDT
Since this is being discussed again I'd like to point out that
https://bugzilla.mozilla.org/show_bug.cgi?id=295977 which involves
autoscrolling with the mousewheel under the same circumstances is still broken
and for some reason being largely ignored (only 5 votes). I think anyone who had
an issue with this bug should probably be concerned with that one as well.
Comment 263 José Jeria 2005-07-29 09:34:12 PDT
*** Bug 302488 has been marked as a duplicate of this bug. ***
Comment 264 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-08-01 10:54:59 PDT
*** Bug 302965 has been marked as a duplicate of this bug. ***
Comment 265 Dave Townsend [:mossop] 2005-09-01 15:50:25 PDT
*** Bug 306676 has been marked as a duplicate of this bug. ***
Comment 266 Adam Guthrie 2005-09-02 11:58:14 PDT
*** Bug 306823 has been marked as a duplicate of this bug. ***
Comment 267 Ryan 2005-09-06 09:39:20 PDT
(In reply to comment #174)
> John:
> Try to learn the process of open source software and of bugzilla bug reports
> before accusing people of doing wrong things.
> 1) When a bug gets fixed, does mostly depend on finding a volunteer to work on
> the issue (additionally to getting module owner and sr to accept/support a given
> patch). It took quite a long time in this case until someone decided to really
> work on the issue, all others only did complain, but that doesn't get the job
> done. Basic open soure software rule: If you really want something fixed, get a
> patch done yourself. That's the only really efficient way.
> 2) This issue is fixed now in the current development source code ("trunk"),
> that's why it's marked FIXED. Daily snapshots of that source get compiled and
> are available as "nighty builds" on the Mozilla web pages. All releases off the
> "trunk" code also contain the fix, in this case Mozilla 1.8 alpha 3 should
> already have it, so use that if you really need the fix.

Comment 268 Jayakrishnan G 2005-09-06 22:34:25 PDT
Ryan:

I agree with John coz this bug is there for more than four years and it is 
still not fixed in either of the release builds (not even in Firefox which has 
been released later). Just see the no. of times it has been commented and no. 
of times it has been duplicated. This itself shows the significance of this 
issue which is not fixed in any of the publicly available release builds.

Also for your kind info., everyone who posts issue in an open source product 
won't be in a position to fix the issue by himself/herself. It is the 
community's duty to assign the issue to a responsible person and fix it duly 
within a stipulated time based on its criticality.

So, whomsoever in the community it may be concerned, please have this issue 
fixed and resolved in any of the release build. Or else, atleast have a patch 
released and make it available to a common man through the "Latest Updates 
Available" facility.

Thanks & Regards
Jai
Comment 269 Henrik Skupin (:whimboo) 2005-09-07 00:46:04 PDT
I think we can clear these flags cause they aren't need anymore. Marking this
bug as verified cause it's working fine with builds of different OS for a long time.
Comment 270 Jayakrishnan G 2005-09-07 01:22:19 PDT
(In reply to comment #269)
> I think we can clear these flags cause they aren't need anymore. Marking this
> bug as verified cause it's working fine with builds of different OS for a 
long time.

So guys, make it available for the whole world. What the hell you are doing 
without releasing it???
Comment 271 Henrik Skupin (:whimboo) 2005-09-07 02:08:24 PDT
(In reply to comment #270)
> So guys, make it available for the whole world. What the hell you are doing 
> without releasing it???

It's still available since a couple of month in trunk nightly builds. If you
wanna test an official release then grab Firefox 1.5 Beta1, which will be
released tomorrow. 
Comment 272 Jayakrishnan G 2005-09-07 02:15:04 PDT
(In reply to comment #271)
> It's still available since a couple of month in trunk nightly builds. If you
> wanna test an official release then grab Firefox 1.5 Beta1, which will be
> released tomorrow. 

OK i'll check out in FireFox 1.5 Beta1 release. Btw, won't the Bugzilla provide 
the exact link of a build for an issue that has been fixed. I expect a link of 
the issue-fixed-build in each issue's detail page.
Comment 273 Phil Ringnalda (:philor, back in August) 2005-09-12 18:35:24 PDT
*** Bug 302613 has been marked as a duplicate of this bug. ***
Comment 274 Olav Vitters 2005-09-16 12:16:33 PDT
*** Bug 308847 has been marked as a duplicate of this bug. ***
Comment 275 Bryan 2005-12-03 16:08:33 PST
Clicking the mouse wheel down and moving mouse up or down does not scroll the overflow div in test cases above.  Is this reported under a different bug id?

Tested with stable 1.5
Comment 276 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-12-03 16:10:18 PST
Ys, (In reply to comment #275)
> Clicking the mouse wheel down and moving mouse up or down does not scroll the
> overflow div in test cases above.  Is this reported under a different bug id?

Yes, that's bug 295977.

Note You need to log in before you can comment on or make changes to this bug.