Scrollbar accepts focus when clicking on the scrollbar arrows

VERIFIED DUPLICATE of bug 9086

Status

()

P1
normal
VERIFIED DUPLICATE of bug 9086
19 years ago
18 years ago

People

(Reporter: dead, Assigned: saari)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
After dragging the scrollbar slider, mousewheel scrolling in a tree (such as an
FTP listing) no longer works.  This is because the scrollbar drag is leaving
mCurrentFocus set in nsEventStateManager.
(Reporter)

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 1

19 years ago
CC'ing myself--this bug is interesting to me, since it is kind of a spin-off of
bug 30174.
(Reporter)

Updated

19 years ago
OS: Linux → All
(Reporter)

Updated

19 years ago
Target Milestone: M15
(Reporter)

Comment 2

19 years ago
Reassigning to saari.  Feel free to update the summary to indicate what the 
real problem is.
Assignee: bryner → saari
Status: ASSIGNED → NEW
(Assignee)

Comment 3

19 years ago
Hey bryner, try this again, I think it may be fixed.
Status: NEW → ASSIGNED
(Reporter)

Comment 4

19 years ago
Nope, sorry.  mCurrentFocus is remaining set after you drag the scrollbar
around.
(Assignee)

Comment 5

19 years ago
Grrr. Scrollbars should *not* be accepting focus...
(Reporter)

Comment 6

19 years ago
I just found this out:

(a) The behavior described ONLY seems to happen with scrollbars on trees (i.e.
an ftp directory listing).

(b) Dragging the slider is not required, only clicking on it.  Updating Summary
to reflect that.
Summary: Mousewheel scrolling in trees breaks after dragging scrollbar → Mousewheel scrolling in trees breaks after clicking scrollbar

Comment 7

19 years ago
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
(Assignee)

Comment 8

19 years ago
Bryner, I'm going to bother you and ask you to test this one more time. If it is
still broken, I promise I'll go to Fry's today and buy a scroll mouse :-)
Thanks!
(Reporter)

Comment 9

19 years ago
Seems to still be broken.  Going to ftp://ftp.mozilla.org/pub/mozilla/nightly/,
I did one mousewheel scroll (with logging on) and got:

GetScrollableFrameOrView: mCurrentFocus = NULL

then I clicked on the scrollbar thumb once, tried mousewheel scrolling the page
again, and got:

GetScrollableFrameOrView: mCurrentFocus = 8925390

So, something in clicking the scrollbar thumb is setting mCurrentFocus.

Comment 10

19 years ago
I don't suppose this will help fix the bug, but I hope this will at least help

put you on the right track in diagnosing it...  Anyway, I suspect this focus on

the scrollbar problem is UNIVERSAL, and *NOT* just in scrolling trees.  Example:

if I click on the arrows on the scrollbar to scroll Tinderbox, for example, it

seems the focus goes to the scrollbar there too, because I notice that I also

cannot get the mouse cursor to change when I mouse over links.  In fact, I am

going to change the summary to reflect this fact--I think it does much more than

just break the mousewheel scrolling.



I'm voting for this bug, too.

Summary: Mousewheel scrolling in trees breaks after clicking scrollbar → Scrollbar accepts focus when clicking on the scrollbar arrows

Comment 11

19 years ago
Clicking scrollbar or scrollbar button in trees does this. Clicking same in
ordinary browser pages work OK.
Are there two kinds of scrollbars being used in Mozilla? Or is it that just some
of them are debugged? I'll explain why i think there are two types:
An easy way (under linux) to see "which is which" is disable debugging of GFX
scrollbars in preferences.

The set of scrollbars that work OK will then "transform" to the native GUI or
windowmanager's set of scrollbar's - themed.
These apply in browser windows and in dropdown forms on web-pages.
The other kind, that removing debugging does NOT change are in;
mysidebar
preferences
ftp trees

These are the "problem scrollbars". Right now the dropdown boxes in
preferences/fonts are gone again. But only in those dropdown boxes that would
have to have a scrollbar.

Using preferences as a sample: You see that something is wrong by only clicking
on a scrollbar arrow there. A tiny dotted "box" appears around it, and when you
click in the area outside the scrollbar (which would normally "deactivate" the
dropdownbox") - the button still has this dotted box. Clicking once more removes
it. I believe this box indicates "selected" state.
However, you don't see the dotted box in other trees than prefs: Prefs just got
this "boxed" behaviour after a problem with drawing the arrows in them was
fixed. (34801)
Mentioning this for what it's worth. I'm no programmer, maybe i'm spamming.

PERHAPS relevant:
bug 33230 clicking on scrollbar looses selection [FIXED] (probably irrelevant
since it's about the "kind" of scrollbars that normally work OK.]

Bugs about "tree-scrollbar" type of scrollbars:
bug 34525 Font selection is broken [open]
bug 34635 No drop list in preferences->fonts [open]
bug 34801 [REGRSSION]Image buttons don't paint all the way.[FIXED]
(Assignee)

Updated

19 years ago
Priority: P3 → P1

Comment 12

19 years ago
Build ID 2000041816 Linux
Clicking anywhere in an ftp listing (selecting) also breaks wheel-scrolling now.
(Reporter)

Comment 13

19 years ago
The broken behavior when a row is selected is probably an entirely different
problem.  I'll look into it.
(Reporter)

Comment 14

19 years ago
Breakage on selection is in fact a different bug, filed as bug 36348.

Comment 15

19 years ago
A click on the downarrow on a tree scrollbar widget shows unusual behaviour
also: In a ftp tree, the scrollbar won't move till you raise button again.
If you click + hold in, for a very long time, the scrollbar will suddenly move
to bottom when you let go.
But there is no "visual" control over what is happening, as the slider on the
scrollbar doesn't move *while* you press the arrowbutton.

In the File/File Open menu, a click+hold down has another effect: No matter how
long you hold in, the slider will only move a distance equivalent to the one you
achieve with one quick click.

Related?
(Reporter)

Comment 16

19 years ago
I've worked around this bug as far as the mousewheel scrolling goes... but this
probably still needs a real fix.

Comment 17

19 years ago
moving to m18
Target Milestone: M16 → M18

Comment 18

19 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
(Assignee)

Comment 19

19 years ago
dup of 9086


*** This bug has been marked as a duplicate of 9086 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 20

19 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 21

18 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca
dragging slider then mousewheel scrolling a tree works fine in a current build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.