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)
Core
XUL
Tracking
()
VERIFIED
FIXED
mozilla1.8alpha3
People
(Reporter: tack-bugzilla, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: access, testcase)
Attachments
(12 files, 6 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
roc
:
review+
dbaron
:
superreview+
asa
:
approval-aviary-
|
Details | Diff | Splinter Review |
(deleted),
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.
Comment 1•23 years ago
|
||
what build are you using?
Reporter | ||
Comment 2•23 years ago
|
||
Right now I'm using 2001083108. It also didn't work using a build from 3 or 4
days ago.
XP Toolkit
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
Comment 6•23 years ago
|
||
confirmed
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.9.6
Reporter | ||
Comment 7•23 years ago
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Updated•23 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 9•23 years ago
|
||
*** Bug 135491 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
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•23 years ago
|
||
*** Bug 135906 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
*** Bug 137839 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 148536 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** Bug 155296 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Comment 19•22 years ago
|
||
*** Bug 152513 has been marked as a duplicate of this bug. ***
Comment 20•22 years ago
|
||
Looks like the div does not get focus -> no keyboard/wheel input.
Comment 21•22 years ago
|
||
*** Bug 169267 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
*** Bug 176029 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
Bug still occurs in mainline build 2002110704... will it ever be fixed?
Comment 24•22 years ago
|
||
Still in 2002111508 Win32
Any word on this one?
Comment 25•22 years ago
|
||
*** Bug 170012 has been marked as a duplicate of this bug. ***
Comment 26•22 years ago
|
||
*** Bug 182536 has been marked as a duplicate of this bug. ***
Comment 27•22 years ago
|
||
*** Bug 172318 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Whiteboard: [jk-focus]
Comment 28•22 years ago
|
||
*** Bug 188535 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
*** Bug 193171 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 30•22 years ago
|
||
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
Comment 31•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Press tab to see the focus of the overflow-are change to show the links.
Comment 35•22 years ago
|
||
Any chance of this making 1.3? It breaks our site, requiring Yet Another
workaround based on the user-agent string.
Comment 36•22 years ago
|
||
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•22 years ago
|
||
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?
Comment 38•22 years ago
|
||
Blocking 1.3 because of this bug? Cooool. :)
Flags: blocking1.3? → blocking1.3+
Comment 39•22 years ago
|
||
Lemming: I do not think you are a mozilla.org driver.
Comment 40•22 years ago
|
||
"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?
Comment 41•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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?
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → mozilla1.4beta
Comment 44•22 years ago
|
||
*** Bug 204597 has been marked as a duplicate of this bug. ***
Comment 45•21 years ago
|
||
*** Bug 209673 has been marked as a duplicate of this bug. ***
Comment 46•21 years ago
|
||
*** Bug 210878 has been marked as a duplicate of this bug. ***
Comment 47•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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
Comment 50•21 years ago
|
||
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.
Comment 52•21 years ago
|
||
*** Bug 213540 has been marked as a duplicate of this bug. ***
Comment 53•21 years ago
|
||
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
Comment 54•21 years ago
|
||
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•21 years ago
|
||
*** Bug 215113 has been marked as a duplicate of this bug. ***
Comment 56•21 years ago
|
||
> 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•21 years ago
|
||
*** Bug 216671 has been marked as a duplicate of this bug. ***
Comment 58•21 years ago
|
||
This bug two years old, and very annoying. Any plans to fix it?
Comment 59•21 years ago
|
||
Added myself to the CC list.
The milestone for this bug _should_ be changed. The current one is out of date.
Comment 60•21 years ago
|
||
This bug seems to have been around forever. I can confirm it still exists in
Firebird 20030822, and its VERY annoying.
Comment 61•21 years ago
|
||
What's the status on this bug?
Comment 63•21 years ago
|
||
mozilla1.5 is already out so blocking it is a futile action.
However, I wonder when "blocking1.6a" flag will be available.
Updated•21 years ago
|
Flags: blocking1.5?
Comment 64•21 years ago
|
||
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•21 years ago
|
||
This workaround improves on the one posted in comment 64
Comment 66•21 years ago
|
||
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•21 years ago
|
||
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?
Comment 68•21 years ago
|
||
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.
Updated•21 years ago
|
Flags: blocking1.6a? → blocking1.6a-
Comment 69•21 years ago
|
||
*** Bug 223890 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Target Milestone: mozilla1.4beta → ---
Comment 70•21 years ago
|
||
Bryner, can you look at these workaround patches and see if they're appropriate?
Comment 71•21 years ago
|
||
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 73•21 years ago
|
||
*** Bug 228656 has been marked as a duplicate of this bug. ***
Comment 74•21 years ago
|
||
*** Bug 228150 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.7a?
Comment 75•21 years ago
|
||
*** Bug 230148 has been marked as a duplicate of this bug. ***
Comment 76•21 years ago
|
||
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 77•21 years ago
|
||
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
Updated•21 years ago
|
Flags: blocking1.7a? → blocking1.7a-
Comment 78•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
*** Bug 235833 has been marked as a duplicate of this bug. ***
Comment 85•21 years ago
|
||
Doesn't work for me either (Firefox 0.8 Mac.)
Comment 86•21 years ago
|
||
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•21 years ago
|
||
*** Bug 237019 has been marked as a duplicate of this bug. ***
Comment 88•21 years ago
|
||
*** Bug 240684 has been marked as a duplicate of this bug. ***
Comment 89•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
*** Bug 241923 has been marked as a duplicate of this bug. ***
Comment 92•21 years ago
|
||
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?
Comment 93•21 years ago
|
||
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.
Updated•21 years ago
|
Flags: blocking1.7a-
Flags: blocking1.7?
Flags: blocking1.7-
Flags: blocking1.6b-
Flags: blocking1.6a-
Updated•21 years ago
|
Flags: blocking1.8a1?
Updated•21 years ago
|
Flags: blocking1.8a1?
Comment 94•20 years ago
|
||
*** Bug 246703 has been marked as a duplicate of this bug. ***
Comment 95•20 years ago
|
||
(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•20 years ago
|
||
*** Bug 248591 has been marked as a duplicate of this bug. ***
Comment 97•20 years ago
|
||
Well, this seems to work for me, at least for the testcases it is.
Comment 98•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
*** Bug 251014 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0?
Comment 101•20 years ago
|
||
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)
Assignee | ||
Comment 102•20 years ago
|
||
*** Bug 251477 has been marked as a duplicate of this bug. ***
Comment 103•20 years ago
|
||
*** Bug 251569 has been marked as a duplicate of this bug. ***
Comment 104•20 years ago
|
||
*** Bug 251667 has been marked as a duplicate of this bug. ***
Comment 105•20 years ago
|
||
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?
Assignee | ||
Comment 106•20 years ago
|
||
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
Assignee | ||
Comment 107•20 years ago
|
||
Assignee | ||
Comment 108•20 years ago
|
||
Assignee | ||
Comment 109•20 years ago
|
||
Assignee | ||
Comment 110•20 years ago
|
||
This fixes the mouse-wheel scrolling part of this bug.
Assignee | ||
Comment 111•20 years ago
|
||
Assignee | ||
Comment 112•20 years ago
|
||
I have only tested the patch on Linux, I would appreciate if someone could try
it out on other platforms.
Assignee | ||
Updated•20 years ago
|
Attachment #153480 -
Flags: superreview?(dbaron)
Attachment #153480 -
Flags: review?(bryner)
Assignee | ||
Comment 113•20 years ago
|
||
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•20 years ago
|
||
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.
Updated•20 years ago
|
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
Priority: -- → P3
Comment 115•20 years ago
|
||
(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.
Assignee | ||
Comment 116•20 years ago
|
||
(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?
Assignee | ||
Comment 117•20 years ago
|
||
(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•20 years ago
|
||
> 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•20 years ago
|
||
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•20 years ago
|
||
... 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?
Assignee | ||
Comment 121•20 years ago
|
||
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.)
Assignee | ||
Comment 122•20 years ago
|
||
(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.
Assignee | ||
Comment 123•20 years ago
|
||
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.
Assignee | ||
Comment 124•20 years ago
|
||
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.)
Comment 126•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
Comment #127, this is not the place for these comments. Sorry for the bugspam
for everyone else.
Comment 129•20 years ago
|
||
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•20 years ago
|
||
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?
Assignee | ||
Comment 131•20 years ago
|
||
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
Assignee | ||
Comment 132•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #153480 -
Attachment is obsolete: true
Attachment #153481 -
Attachment is obsolete: true
Assignee | ||
Comment 133•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #153480 -
Flags: superreview?(dbaron)
Attachment #153480 -
Flags: review?(bryner)
Assignee | ||
Updated•20 years ago
|
Attachment #153610 -
Flags: superreview?(dbaron)
Attachment #153610 -
Flags: review?(roc)
Assignee | ||
Comment 134•20 years ago
|
||
"Patch B rev. 2" also fixes bug 78786 is what I meant to say (not bug 251986).
Comment 135•20 years ago
|
||
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•20 years ago
|
||
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?
Assignee | ||
Comment 138•20 years ago
|
||
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.
Assignee | ||
Comment 139•20 years ago
|
||
Attachment #153610 -
Attachment is obsolete: true
Attachment #153611 -
Attachment is obsolete: true
Assignee | ||
Comment 140•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #153610 -
Flags: superreview?(dbaron)
Attachment #153610 -
Flags: review?(roc)
Assignee | ||
Updated•20 years ago
|
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+
Updated•20 years ago
|
Whiteboard: [jk-focus] → [jk-focus][have patch]
Comment 143•20 years ago
|
||
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•20 years ago
|
||
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 145•20 years ago
|
||
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 146•20 years ago
|
||
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+
Assignee | ||
Comment 147•20 years ago
|
||
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.
Assignee | ||
Comment 148•20 years ago
|
||
> 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•20 years ago
|
||
what are the next steps that are needed here for the aviary 1.0 branch.
Assignee | ||
Comment 150•20 years ago
|
||
*** Bug 254408 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 151•20 years ago
|
||
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
Assignee | ||
Comment 152•20 years ago
|
||
*** Bug 229175 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 153•20 years ago
|
||
*** Bug 234236 has been marked as a duplicate of this bug. ***
Comment 154•20 years ago
|
||
*** Bug 254808 has been marked as a duplicate of this bug. ***
Comment 155•20 years ago
|
||
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•20 years ago
|
||
Any particular reason why this hasn't been integrated into the Aviary branch yet?
Comment 157•20 years ago
|
||
Comment on attachment 154083 [details] [diff] [review]
Patch B rev. 3
Putting on the approvers' radar
Attachment #154083 -
Flags: approval-aviary?
Comment 158•20 years ago
|
||
Is it possible to checked this one in into the aviary as well?
Updated•20 years ago
|
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.
Comment 160•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
Mats Palmgren: could you please give some reaction on why this is not checked in
into the aviary-branch yet?
Comment 167•20 years ago
|
||
*** Bug 256517 has been marked as a duplicate of this bug. ***
Comment 168•20 years ago
|
||
i think this checkin regressed scrollwheel behavior in camino on 10.2, see bug
256538.
ideas?
Assignee | ||
Comment 169•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
*** Bug 258186 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
Comment 177•20 years ago
|
||
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-
Comment 178•20 years ago
|
||
*** Bug 259010 has been marked as a duplicate of this bug. ***
Comment 179•20 years ago
|
||
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?
I hope so
Comment 181•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
> I am curious, does the Moz team release nightly builds of Firefox?
Yes. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Comment 186•20 years ago
|
||
*** Bug 261807 has been marked as a duplicate of this bug. ***
Comment 187•20 years ago
|
||
*** Bug 262271 has been marked as a duplicate of this bug. ***
Comment 188•20 years ago
|
||
*** Bug 263507 has been marked as a duplicate of this bug. ***
Comment 189•20 years ago
|
||
*** Bug 264039 has been marked as a duplicate of this bug. ***
Comment 190•20 years ago
|
||
*** Bug 259310 has been marked as a duplicate of this bug. ***
Comment 191•20 years ago
|
||
*** Bug 263372 has been marked as a duplicate of this bug. ***
Comment 192•20 years ago
|
||
*** Bug 264826 has been marked as a duplicate of this bug. ***
Comment 193•20 years ago
|
||
*** Bug 268004 has been marked as a duplicate of this bug. ***
Comment 194•20 years ago
|
||
Hopefully getting this fix in there will be of high priority after the 1.0
launch tomorrow.
/me coughs
Comment 195•20 years ago
|
||
*** Bug 268638 has been marked as a duplicate of this bug. ***
Comment 196•20 years ago
|
||
*** Bug 271830 has been marked as a duplicate of this bug. ***
Comment 197•20 years ago
|
||
*** Bug 271937 has been marked as a duplicate of this bug. ***
Comment 198•20 years ago
|
||
*** Bug 266404 has been marked as a duplicate of this bug. ***
Comment 199•20 years ago
|
||
*** Bug 272214 has been marked as a duplicate of this bug. ***
Comment 200•20 years ago
|
||
*** Bug 272231 has been marked as a duplicate of this bug. ***
Comment 201•20 years ago
|
||
*** Bug 272592 has been marked as a duplicate of this bug. ***
Comment 202•20 years ago
|
||
*** Bug 272832 has been marked as a duplicate of this bug. ***
Comment 203•20 years ago
|
||
*** Bug 273792 has been marked as a duplicate of this bug. ***
Comment 204•20 years ago
|
||
*** Bug 274207 has been marked as a duplicate of this bug. ***
Comment 205•20 years ago
|
||
*** Bug 275128 has been marked as a duplicate of this bug. ***
Comment 206•20 years ago
|
||
*** Bug 275261 has been marked as a duplicate of this bug. ***
Comment 207•20 years ago
|
||
*** Bug 276524 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 208•20 years ago
|
||
*** Bug 277517 has been marked as a duplicate of this bug. ***
Comment 209•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
*** Bug 280213 has been marked as a duplicate of this bug. ***
Comment 214•20 years ago
|
||
*** Bug 282456 has been marked as a duplicate of this bug. ***
Comment 215•20 years ago
|
||
*** Bug 282815 has been marked as a duplicate of this bug. ***
Comment 216•20 years ago
|
||
*** Bug 284401 has been marked as a duplicate of this bug. ***
Comment 217•20 years ago
|
||
*** Bug 285279 has been marked as a duplicate of this bug. ***
Comment 218•20 years ago
|
||
*** Bug 285420 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 219•20 years ago
|
||
*** Bug 285522 has been marked as a duplicate of this bug. ***
Comment 220•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
Got it, thanks.
Comment 223•20 years ago
|
||
*** Bug 288034 has been marked as a duplicate of this bug. ***
Comment 224•20 years ago
|
||
*** Bug 288035 has been marked as a duplicate of this bug. ***
Comment 225•20 years ago
|
||
*** Bug 241418 has been marked as a duplicate of this bug. ***
Comment 226•20 years ago
|
||
*** Bug 288372 has been marked as a duplicate of this bug. ***
*** Bug 289213 has been marked as a duplicate of this bug. ***
Comment 228•20 years ago
|
||
*** Bug 290621 has been marked as a duplicate of this bug. ***
Comment 229•20 years ago
|
||
*** Bug 290934 has been marked as a duplicate of this bug. ***
Comment 230•20 years ago
|
||
*** Bug 291041 has been marked as a duplicate of this bug. ***
Comment 231•20 years ago
|
||
*** Bug 291942 has been marked as a duplicate of this bug. ***
Comment 232•20 years ago
|
||
*** Bug 291976 has been marked as a duplicate of this bug. ***
Comment 233•20 years ago
|
||
*** Bug 292070 has been marked as a duplicate of this bug. ***
Comment 234•20 years ago
|
||
*** Bug 294985 has been marked as a duplicate of this bug. ***
Comment 235•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
(In reply to comment #241)
> (In reply to comment #239)
> > still cannot autoscroll.
>
> What system are you on?
winxp sp2
Comment 244•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
'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•20 years ago
|
||
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•20 years ago
|
||
*** Bug 296805 has been marked as a duplicate of this bug. ***
Comment 252•19 years ago
|
||
*** Bug 298146 has been marked as a duplicate of this bug. ***
Comment 253•19 years ago
|
||
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•19 years ago
|
||
erik.johnson@grainger.com: 1.7 was branched in early april 2004. use something
that isn't based on 1.7.
Comment 255•19 years ago
|
||
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•19 years ago
|
||
*** Bug 299264 has been marked as a duplicate of this bug. ***
Comment 257•19 years ago
|
||
*** Bug 263929 has been marked as a duplicate of this bug. ***
Comment 258•19 years ago
|
||
My Firefox 1.0.4 still has this Bug, and its very annoying!
Can someone reopen the Bug and fix it then?
Comment 259•19 years ago
|
||
My Firefox 1.0.4 still has this Bug, and its very annoying!
Can someone reopen the Bug and fix it then?
Comment 260•19 years ago
|
||
this won't be fixed on 1.0.x.
Comment 261•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
*** Bug 302488 has been marked as a duplicate of this bug. ***
Comment 264•19 years ago
|
||
*** Bug 302965 has been marked as a duplicate of this bug. ***
Comment 265•19 years ago
|
||
*** Bug 306676 has been marked as a duplicate of this bug. ***
Comment 266•19 years ago
|
||
*** Bug 306823 has been marked as a duplicate of this bug. ***
Comment 267•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
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
Comment 270•19 years ago
|
||
(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•19 years ago
|
||
(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•19 years ago
|
||
(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•19 years ago
|
||
*** Bug 302613 has been marked as a duplicate of this bug. ***
Comment 274•19 years ago
|
||
*** Bug 308847 has been marked as a duplicate of this bug. ***
Comment 275•19 years ago
|
||
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•19 years ago
|
||
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.
Description
•