Closed Bug 153946 Opened 22 years ago Closed 19 years ago

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

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7alpha

People

(Reporter: xolaware.llc, Assigned: caillon)

References

Details

Attachments

(1 file)

Patch
5.78 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review 
(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.
johndoe@san.rr.com, 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.
Assignee: caillon → jaggernaut
Severity: normal → minor
Status: UNCONFIRMED → NEW
Component: XP Apps: GUI Features → XP Toolkit/Widgets
Ever confirmed: true
QA Contact: paw → jrgm
Summary: click-hold behavior of scrollbar handle does not conform to normal mac GUI behavior → Click+holding below scroll elevator, then moving cursor down, doesn't result in additional scrolling
> assigned by request of the assignee

-> caillon
Assignee: jaggernaut → caillon
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".
still a bug on macos X
OS: Mac System 9.x → MacOS X
OS: MacOS X → All
Hardware: Macintosh → All
Attached patch Patch — — Splinter Review 
Update our destination when the mouse moves if we are click+holding.
Attachment #139878 - Flags: superreview?(roc)
Attachment #139878 - Flags: review?(roc)
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.7alpha
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
Attachment #139878 - Flags: superreview?(roc)
Attachment #139878 - Flags: superreview+
Attachment #139878 - Flags: review?(roc)
Attachment #139878 - Flags: review+
(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.

Checked in 01/26/2004 21:19 PST.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 71458 has been marked as a duplicate of this bug. ***
So does this actually work?  I picked up a new Firefox build the other day and
still see this behavior.
*** Bug 224599 has been marked as a duplicate of this bug. ***
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.
I'm using a trunk build.  Or at least I think I am.  Maybe Ben's tricked me.  Again.
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+
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.
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?
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.

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+
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Dean, can you try this in SeaMonkey?
Huh, it doesn't work there either.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040504
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.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 19 years ago
Resolution: --- → FIXED
Filed bug 282195.
(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)).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: