Closed Bug 97283 Opened 23 years ago Closed 20 years ago

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

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8alpha3

People

(Reporter: tack-bugzilla, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: access, testcase)

Attachments

(12 files, 6 obsolete files)

Test case -- a small div with overflow:auto
236 bytes, text/html
Details
Testcase - Comparison of iframe and div scrolling
4.34 KB, text/html
Details
Testcase - including overflow:scroll
5.49 KB, text/html
Details
Same as testcase 3, but with links to test tab focus
6.04 KB, text/html
Details
:hover & :focus behaviour test & <textarea> added to example
6.52 KB, text/html
Details
Improved workaround
1.01 KB, text/html
Details
Testcase - complex 1
11.50 KB, text/html
Details
Testcase - complex 1 in IFRAME
430 bytes, text/html
Details
Testcase - complex 1 in FRAMEs
632 bytes, text/html
Details
Frame hierarchy with scrolling aspects
8.22 KB, text/plain
Details
Patch B rev. 3
8.18 KB, patch
roc
: review+
dbaron
: superreview+
asa
: approval-aviary-
Details | Diff | Splinter Review
Patch B rev. 3 (diff -uw)
7.71 KB, patch
Details | Diff | Splinter Review
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.
what build are you using?
Right now I'm using 2001083108. It also didn't work using a build from 3 or 4 days ago.
mind giving us a testcase?? :)
XP Toolkit
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
->bryner for triage
Assignee: trudelle → bryner
confirmed
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.8
->moz101
Target Milestone: mozilla0.9.8 → mozilla1.0.1
OS: Linux → All
Hardware: PC → All
*** Bug 135491 has been marked as a duplicate of this bug. ***
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)
*** Bug 135906 has been marked as a duplicate of this bug. ***
he's right. scrolling is totally non-functional, not just with wheel. try the testcase for example. clarifying summary
Summary: Scroll wheel does not work for divs using overflow:auto → scrolling (keyboard or wheel) does not work for divs using overflow:auto
*** Bug 137839 has been marked as a duplicate of this bug. ***
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.
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.
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.
*** Bug 148536 has been marked as a duplicate of this bug. ***
*** Bug 155296 has been marked as a duplicate of this bug. ***
Blocks: focusnav
Severity: normal → major
Keywords: access, sec508
*** Bug 152513 has been marked as a duplicate of this bug. ***
Looks like the div does not get focus -> no keyboard/wheel input.
*** Bug 169267 has been marked as a duplicate of this bug. ***
*** Bug 176029 has been marked as a duplicate of this bug. ***
Bug still occurs in mainline build 2002110704... will it ever be fixed?
Still in 2002111508 Win32 Any word on this one?
*** Bug 170012 has been marked as a duplicate of this bug. ***
*** Bug 182536 has been marked as a duplicate of this bug. ***
*** Bug 172318 has been marked as a duplicate of this bug. ***
Whiteboard: [jk-focus]
*** Bug 188535 has been marked as a duplicate of this bug. ***
*** Bug 193171 has been marked as a duplicate of this bug. ***
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.
Summary: scrolling (keyboard or wheel) does not work for divs using overflow:auto → scrolling (keyboard or wheel) does not work for elements using overflow:auto
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.
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.
Browsing with caret (F7) does allow more navigation. You can then click in the textarea and move around it with the cursor keys.
Press tab to see the focus of the overflow-are change to show the links.
Any chance of this making 1.3? It breaks our site, requiring Yet Another workaround based on the user-agent string.
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)
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.
Flags: blocking1.3?
Blocking 1.3 because of this bug? Cooool. :)
Flags: blocking1.3? → blocking1.3+
Lemming: I do not think you are a mozilla.org driver.
"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...
Flags: blocking1.3+ → blocking1.3?
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.
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).
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?
Flags: blocking1.3?
Target Milestone: mozilla1.0.1 → mozilla1.4beta
*** Bug 204597 has been marked as a duplicate of this bug. ***
*** Bug 209673 has been marked as a duplicate of this bug. ***
*** Bug 210878 has been marked as a duplicate of this bug. ***
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?
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.
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...
Blocks: 63663
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.
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.
Blocks: atfmeta
*** Bug 213540 has been marked as a duplicate of this bug. ***
Tweaking summary for better b.m.o. queries. (A search on "mouse scroll div" should include this bug.)
Summary: scrolling (keyboard or wheel) does not work for elements using overflow:auto → scrolling (keyboard or mouse wheel) does not work for elements such as div using overflow - auto or scroll
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.
*** Bug 215113 has been marked as a duplicate of this bug. ***
> 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.
*** Bug 216671 has been marked as a duplicate of this bug. ***
Keywords: testcase
This bug two years old, and very annoying. Any plans to fix it?
Added myself to the CC list. The milestone for this bug _should_ be changed. The current one is out of date.
This bug seems to have been around forever. I can confirm it still exists in Firebird 20030822, and its VERY annoying.
What's the status on this bug?
Nominating this bug for blocking 1.5
Flags: blocking1.5?
mozilla1.5 is already out so blocking it is a futile action. However, I wonder when "blocking1.6a" flag will be available.
Flags: blocking1.5?
I have created a little workaround for this bug http://kla.usj.dk/mozilla/scroll.html - it's not that nice but it works...
Attached file Improved workaround —
This workaround improves on the one posted in comment 64
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.
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.
Flags: blocking1.6b?
Flags: blocking1.6a?
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.
Flags: blocking1.6a? → blocking1.6a-
*** Bug 223890 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Target Milestone: mozilla1.4beta → ---
Bryner, can you look at these workaround patches and see if they're appropriate?
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.
no patch, not likely for 1.6.
Flags: blocking1.6b? → blocking1.6b-
*** Bug 228656 has been marked as a duplicate of this bug. ***
*** Bug 228150 has been marked as a duplicate of this bug. ***
Flags: blocking1.7a?
*** Bug 230148 has been marked as a duplicate of this bug. ***
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
Attachment #139476 - Attachment description: html/css → rendering of bkg image in overflow:auto div
Comment on attachment 139476 [details] rendering of bkg image in overflow:auto div Not related to this bug. Please file another.
Attachment #139476 - Attachment is obsolete: true
Flags: blocking1.7a? → blocking1.7a-
Blocks: 229175
Blocks: 233381
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)
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.)
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
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.
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.
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
*** Bug 235833 has been marked as a duplicate of this bug. ***
Doesn't work for me either (Firefox 0.8 Mac.)
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?
Blocks: 236727
No longer blocks: 236727
*** Bug 237019 has been marked as a duplicate of this bug. ***
*** Bug 240684 has been marked as a duplicate of this bug. ***
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...
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...
*** Bug 241923 has been marked as a duplicate of this bug. ***
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.
Flags: blocking1.7?
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.
Blocks: 230863
Flags: blocking1.7a-
Flags: blocking1.7?
Flags: blocking1.7-
Flags: blocking1.6b-
Flags: blocking1.6a-
Flags: blocking1.8a1?
Flags: blocking1.8a1?
*** Bug 246703 has been marked as a duplicate of this bug. ***
(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
*** Bug 248591 has been marked as a duplicate of this bug. ***
Attached patch This seems to work for me (obsolete) — — Splinter Review
Well, this seems to work for me, at least for the testcases it is.
(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?
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)
*** Bug 251014 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0?
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)
*** Bug 251477 has been marked as a duplicate of this bug. ***
*** Bug 251569 has been marked as a duplicate of this bug. ***
*** Bug 251667 has been marked as a duplicate of this bug. ***
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 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.
Attachment #152067 - Attachment is obsolete: true
Attached file Testcase - complex 1 —
Attached patch Patch B rev. 1 (obsolete) — — Splinter Review
This fixes the mouse-wheel scrolling part of this bug.
Attached patch Patch B rev. 1 (diff -uw) (obsolete) — — Splinter Review
I have only tested the patch on Linux, I would appreciate if someone could try it out on other platforms.
Attachment #153480 - Flags: superreview?(dbaron)
Attachment #153480 - Flags: review?(bryner)
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?
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.
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
Priority: -- → P3
Blocks: 78786
(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.
(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?
(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.
> 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).
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.
... 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?
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.)
(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.
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 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
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.)
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...
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 #127, this is not the place for these comments. Sorry for the bugspam for everyone else.
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.
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.
Flags: blocking1.8a3?
I have spawned the keyboard scrolling part to bug 251986 (and fixed it too). This bug is about mouse scrolling only. Taking bug.
Assignee: bryner → mats.palmgren
No longer blocks: focusnav
Status: ASSIGNED → NEW
Summary: scrolling (keyboard or mouse wheel) does not work for elements such as div using overflow - auto or scroll → [FIX] Mouse wheel scrolling does not work for elements such as div using overflow - auto or scroll
Attached patch Patch B rev. 2 (obsolete) — — Splinter Review
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.
Attachment #153480 - Attachment is obsolete: true
Attachment #153481 - Attachment is obsolete: true
Attached patch Patch B rev. 2 (diff -uw) (obsolete) — — Splinter Review
Attachment #153480 - Flags: superreview?(dbaron)
Attachment #153480 - Flags: review?(bryner)
Attachment #153610 - Flags: superreview?(dbaron)
Attachment #153610 - Flags: review?(roc)
"Patch B rev. 2" also fixes bug 78786 is what I meant to say (not bug 251986).
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.
Either this gets review and is checked in in the next week or so, or it may miss the aviary 1.0 train.
+ 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?
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.
Attached patch Patch B rev. 3 — — Splinter Review
Attachment #153610 - Attachment is obsolete: true
Attachment #153611 - Attachment is obsolete: true
Attachment #153610 - Flags: superreview?(dbaron)
Attachment #153610 - Flags: review?(roc)
Attachment #154083 - Flags: superreview?(dbaron)
Attachment #154083 - Flags: review?(roc)
(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 on attachment 154083 [details] [diff] [review] Patch B rev. 3 looks OK to me now
Attachment #154083 - Flags: review?(roc) → review+
Whiteboard: [jk-focus] → [jk-focus][have patch]
Blocks: 234236
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 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.
Attachment #154083 - Flags: superreview?(dbaron) → superreview+
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...
Attachment #154083 - Flags: superreview+ → superreview-
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.
Attachment #154083 - Flags: superreview- → superreview+
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.
> 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.
Keywords: sec508
what are the next steps that are needed here for the aviary 1.0 branch.
Blocks: 176538
*** Bug 254408 has been marked as a duplicate of this bug. ***
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
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking1.8a3?
Resolution: --- → FIXED
Summary: [FIX] 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 - auto or scroll
No longer blocks: 229175
*** Bug 229175 has been marked as a duplicate of this bug. ***
No longer blocks: 234236
*** Bug 234236 has been marked as a duplicate of this bug. ***
No longer blocks: 230863
*** Bug 254808 has been marked as a duplicate of this bug. ***
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?
Any particular reason why this hasn't been integrated into the Aviary branch yet?
Comment on attachment 154083 [details] [diff] [review] Patch B rev. 3 Putting on the approvers' radar
Attachment #154083 - Flags: approval-aviary?
Is it possible to checked this one in into the aviary as well?
Whiteboard: [jk-focus][have patch] → [jk-focus][have patch][needed-aviary1.0]
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.
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.
(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.
(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.
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.
(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.
(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.
Mats Palmgren: could you please give some reaction on why this is not checked in into the aviary-branch yet?
*** Bug 256517 has been marked as a duplicate of this bug. ***
i think this checkin regressed scrollwheel behavior in camino on 10.2, see bug 256538. ideas?
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).
(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?
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
(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.
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...
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.
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.
*** Bug 258186 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
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.
Attachment #154083 - Flags: approval-aviary? → approval-aviary-
*** Bug 259010 has been marked as a duplicate of this bug. ***
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?
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.
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.
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.
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.
> I am curious, does the Moz team release nightly builds of Firefox? Yes. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
*** Bug 261807 has been marked as a duplicate of this bug. ***
*** Bug 262271 has been marked as a duplicate of this bug. ***
*** Bug 263507 has been marked as a duplicate of this bug. ***
*** Bug 264039 has been marked as a duplicate of this bug. ***
*** Bug 259310 has been marked as a duplicate of this bug. ***
*** Bug 263372 has been marked as a duplicate of this bug. ***
*** Bug 264826 has been marked as a duplicate of this bug. ***
*** Bug 268004 has been marked as a duplicate of this bug. ***
Hopefully getting this fix in there will be of high priority after the 1.0 launch tomorrow. /me coughs
*** Bug 268638 has been marked as a duplicate of this bug. ***
Blocks: 268003
*** Bug 271830 has been marked as a duplicate of this bug. ***
*** Bug 271937 has been marked as a duplicate of this bug. ***
*** Bug 266404 has been marked as a duplicate of this bug. ***
*** Bug 272214 has been marked as a duplicate of this bug. ***
*** Bug 272231 has been marked as a duplicate of this bug. ***
*** Bug 272592 has been marked as a duplicate of this bug. ***
*** Bug 272832 has been marked as a duplicate of this bug. ***
*** Bug 273792 has been marked as a duplicate of this bug. ***
*** Bug 274207 has been marked as a duplicate of this bug. ***
*** Bug 275128 has been marked as a duplicate of this bug. ***
*** Bug 275261 has been marked as a duplicate of this bug. ***
*** Bug 276524 has been marked as a duplicate of this bug. ***
*** Bug 277517 has been marked as a duplicate of this bug. ***
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
(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.
(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
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.
*** Bug 280213 has been marked as a duplicate of this bug. ***
*** Bug 282456 has been marked as a duplicate of this bug. ***
*** Bug 282815 has been marked as a duplicate of this bug. ***
*** Bug 284401 has been marked as a duplicate of this bug. ***
*** Bug 285279 has been marked as a duplicate of this bug. ***
*** Bug 285420 has been marked as a duplicate of this bug. ***
*** Bug 285522 has been marked as a duplicate of this bug. ***
I want to be removed from getting emails from this list but I'm not in the CC list? Someone please remove me! Thanks...
(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).
Got it, thanks.
*** Bug 288034 has been marked as a duplicate of this bug. ***
*** Bug 288035 has been marked as a duplicate of this bug. ***
*** Bug 241418 has been marked as a duplicate of this bug. ***
*** Bug 288372 has been marked as a duplicate of this bug. ***
*** Bug 289213 has been marked as a duplicate of this bug. ***
*** Bug 290621 has been marked as a duplicate of this bug. ***
*** Bug 290934 has been marked as a duplicate of this bug. ***
*** Bug 291041 has been marked as a duplicate of this bug. ***
*** Bug 291942 has been marked as a duplicate of this bug. ***
*** Bug 291976 has been marked as a duplicate of this bug. ***
*** Bug 292070 has been marked as a duplicate of this bug. ***
*** Bug 294985 has been marked as a duplicate of this bug. ***
(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)
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.
(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.
(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.
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.
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.
(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?
(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.
(In reply to comment #241) > (In reply to comment #239) > > still cannot autoscroll. > > What system are you on? winxp sp2
No longer blocks: majorbugs
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.
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".
(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.
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.
(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
'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.
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.
Blocks: 295977
*** Bug 296805 has been marked as a duplicate of this bug. ***
*** Bug 298146 has been marked as a duplicate of this bug. ***
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.
erik.johnson@grainger.com: 1.7 was branched in early april 2004. use something that isn't based on 1.7.
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
*** Bug 299264 has been marked as a duplicate of this bug. ***
*** Bug 263929 has been marked as a duplicate of this bug. ***
My Firefox 1.0.4 still has this Bug, and its very annoying! Can someone reopen the Bug and fix it then?
My Firefox 1.0.4 still has this Bug, and its very annoying! Can someone reopen the Bug and fix it then?
this won't be fixed on 1.0.x.
(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.
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.
*** Bug 302488 has been marked as a duplicate of this bug. ***
*** Bug 302965 has been marked as a duplicate of this bug. ***
*** Bug 306676 has been marked as a duplicate of this bug. ***
*** Bug 306823 has been marked as a duplicate of this bug. ***
(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.
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
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.
Status: RESOLVED → VERIFIED
Whiteboard: [jk-focus][have patch][needed-aviary1.0]
Target Milestone: --- → mozilla1.8alpha3
(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???
(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.
(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.
*** Bug 302613 has been marked as a duplicate of this bug. ***
*** Bug 308847 has been marked as a duplicate of this bug. ***
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
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: