32344 - Scrollbar accepts focus when clicking on the scrollbar arrows

Status: VERIFIED DUPLICATE of bug 9086

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[old account]

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.

Comment 1

[Daniel Roberts]

CC'ing myself--this bug is interesting to me, since it is kind of a spin-off of
bug 30174.

Comment 2

[old account]

Reassigning to saari.  Feel free to update the summary to indicate what the 
real problem is.

Comment 3

[saari (gone)]

Hey bryner, try this again, I think it may be fixed.

Comment 4

[old account]

Nope, sorry.  mCurrentFocus is remaining set after you drag the scrollbar
around.

Comment 5

[saari (gone)]

Grrr. Scrollbars should *not* be accepting focus...

Comment 6

[old account]

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.

Comment 7

[Peter Trudelle]

Mass-moving most M15 bugs to M16

Comment 8

[saari (gone)]

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!

Comment 9

[old account]

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

[Daniel Roberts]

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.

Comment 11

[R.K.Aa.]

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]

Comment 12

[R.K.Aa.]

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

Comment 13

[old account]

The broken behavior when a row is selected is probably an entirely different
problem.  I'll look into it.

Comment 14

[old account]

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

Comment 15

[R.K.Aa.]

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?

Comment 16

[old account]

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

Comment 17

[Peter Trudelle]

moving to m18

Comment 18

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 19

[saari (gone)]

dup of 9086


*** This bug has been marked as a duplicate of 9086 ***

Comment 20

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 21

[Loco]

Updating QA Contact.

Comment 22

[Brian Ryner (not reading)]

dragging slider then mousewheel scrolling a tree works fine in a current build.