153946 - Click+holding below scroll elevator, then moving cursor down, doesn't result in additional scrolling

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[xolaware.llc]

(assigned by request of the assignee.  made a guess as to the component of origin 
of this error.  this is a problem in browser windows, mailreader windows -- 
including the content and summary panes.  i.e. it seems to be a general problem.)

click-hold in the scrollbar doesn't behave exactly like most other mac apps.  

e.g. take a lengthy mail or a page like the URL for this bug 74688 (the origin of 
this bug).  with the scrollbar handle near the top, click-hold in the scrollbar 
pane about halfway down and wait for the handle to page down that far -> so far, 
so good.  but now, if while still mousedown, attempting to move the pointer 
immediately to about 3/4 down, nothing else happens, whereas in most other apps, 
the scroll bar will page down until it gets to the new spot.

another slight 'deviation' is that, starting with the handle at the top again, 
click-hold near the bottom, but then before the handle gets there, move to about 
halfway down.  in other apps, this will cause scrolling to stop at the 
intersection of where your mouse is and where the scrollbar handle is.  but in 
mozilla, scrolling continues all the way to the original point at which you 
performed the mousedown, often beyond where you are holding the pointer steady.

(and when moving before the handle gets to the pointer, don't do it "too fast", 
or else sometimes the scrollbar handle will just stop before it gets to the 
pointer.)

i've entered this as mac only because i have no idea whether this is a bug or 
even expected behavior on other platforms.

Comment 1

[Greg K.]

[e-mail], you should report the second issue (about moving the cursor above the scroll 
destination point) as a separate bug.

Your first issue (can't continue scroll by moving held cursor down below elevator) is confirmed using 
Mac/2002080208/9.2.2.

Reassigning to XP Toolkit/Widgets.

Comment 2

[John Morrison]

> assigned by request of the assignee

-> caillon

Comment 3

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 4

[xolaware.llc]

still a bug on macos X

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch

Update our destination when the mouse moves if we are click+holding.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 139878 [details] [diff] [review]
Patch

+  static PRBool gotPrefs;
I suppose it's not necessary, but "= PR_FALSE;" would make me sleep better at
night.

+  PRBool mRedrawImmediate;
Might as well make it PRPackedBool

+  static PRBool mMiddlePref;
Make this PRPackedBool too
+  static PRInt32 mSnapMultiplier;
Name these "gMiddlePref", "gSnapMultiplier"


r+sr with those changes

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #6)
> +  static PRBool mMiddlePref;
> Make this PRPackedBool too

Doing that would make me need an intermediate PRBool (pref getters require
PRBools) so I'll leave this as-is.  I'll make the other changes though.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

Checked in 01/26/2004 21:19 PST.

Comment 10

[:deanis74]

*** Bug 71458 has been marked as a duplicate of this bug. ***

Comment 11

[:deanis74]

So does this actually work?  I picked up a new Firefox build the other day and
still see this behavior.

Comment 12

[:deanis74]

*** Bug 224599 has been marked as a duplicate of this bug. ***

Comment 13

[Christopher Aillon (sabbatical, not receiving bugmail)]

Firefox 0.8 was built off of a branch in the 1.6(b?) time frame, so you probably
wouldn't see this fixed there.

Comment 14

[:deanis74]

I'm using a trunk build.  Or at least I think I am.  Maybe Ben's tricked me.  Again.

Comment 15

[:deanis74]

This still isn't working in my Firefox nightly.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040406
Firefox/0.8.0+

Comment 16

[xolaware.llc]

WFM.  (in fact, both "parts" of the original bug work as i would expect, even in
spite of the request to break them into separate bugs.)

it is odd, dean, that it is not working for you.

can you try something?

i notice that if the cursor is not in the scroll-elevator that the behavior is
kind of like what i originally reported.  but as soon as you put the cursor back
in the elevator at a position further along the same scroll direction, the bar
will once again move toward it and stop appropriately when it gets there.  and
if you keep the cursor in the scroll elevator, it works as expected.  this
behavior appears to be standard on mac; finder, adobe acrobat reader and safari
both act this same way.

(i also notice that the finder & acrobat reader behave differently than safari
if, after the original scroll, you move the cursor into the elevator in the
opposite direction of the original scroll:  safari moves to that location,
whereas finder & acrobat reader do not.  firefox behaves like finder & acrobat
reader.  given that finder & safari are both mac apps & behave differently in
this regard, i would say that there is no accepted mac default behavior, and
given that 2 of these 3 behave in one direction, that is good evidence to me
that firefox is doing the right thing in its behavior in this regard.  so, i
would say this bug should indeed not be reopened.)

if this is the behavior you see, dean, i'd mark this as verified-closed.

Comment 17

[:deanis74]

Nope.  No matter where the pointer is, I can't get the scroll thumb to start
moving again.  You're on Max OS X, right?  I'm on Windows XP. Does this work for
someone else on XP?

Comment 18

[xolaware.llc]

yes, sorry, dean, my case is mac OS X.  i had originally submitted this as a mac
os classic bug, then changed the OS to mac OS X, and didn't recognize from my
last commit that the OS/platform had been changed to all.

Comment 19

[:deanis74]

I'm reopening this, it's not fixed in Firefox trunk builds.  Maybe it's Firefox,
maybe it's Windows XP, I don't know.  There's no reason from looking at the code
that it shouldn't work.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040419
Firefox/0.8.0+

Comment 20

[Christopher Aillon (sabbatical, not receiving bugmail)]

Dean, can you try this in SeaMonkey?

Comment 21

[:deanis74]

Huh, it doesn't work there either.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040504

Comment 22

[Christopher Aillon (sabbatical, not receiving bugmail)]

Going to reclose this one out.  It works on MacOSX and Linux as far as I can
tell.  I have no idea why it would not work for you Dean, but feel free to file
a new bug (NOT assigned to me since I have no access to a Windows machine) if
the bug still exists on Windows.

Comment 23

[:deanis74]

Filed bug 282195.

Comment 24

[Daniel B.]

(In reply to comment #22)
> Going to reclose this one out.  It works on MacOSX and Linux as far as I can
> tell.  

Actually, it does not work on Linux.

(That's with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 SeaMonkey/1.0.6)).