Closed Bug 22175 Opened 26 years ago Closed 24 years ago

dragging thumb away from scrollbar should cancel scrolling

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: deanis74, Assigned: deanis74)

References

(
URL
)

Details

Attachments

(3 files)

patch, take 1
1.71 KB, patch
Details | Diff | Splinter Review
new patch with a threshold of 6 * the thumb width
1.45 KB, patch
Details | Diff | Splinter Review
cvs diff -u (crud removed, should still apply just fine)
1.48 KB, patch
Details | Diff | Splinter Review
I logged this in bug 4799, but I'm not sure if my comments will ever be seen since that bug is marked as RESOLVED-FIXED. There was a lengthy discussion that I followed in the newsgroups a while back. It revolved about what should happen if the user is dragging the scrollbar thumb and they drag the cursor off of the thumb (eg. to the left/right of a vertical scrollbar). I agree that the snapping-back of the scrollbars once the mouse moves a certain distance away from the scrollbar is pretty wacky. But I use it, especially with long documents. If I want to scroll down to look at another reference to something, when I'm done I just move my mouse over to the left far enough and I return to my previous position in the huge document. This is one thing that's extremely painful about IE now. And remembering where the thumb of the scrollbar is isn't always an option, because with the resizable scrollbar thumb, it's sometimes so small that being 1/4 inch off means a couple of pages. But I also realize the ease of use for new users that removing this snap-back behavior has created. But how about letting me cancel the dragging of the thumb by pressing Esc? Then, for most people, it will work exactly the same as it does now, but if someone wants to cancel the scroll they can (I think at least a bit intuitively) press the Esc key. Last build tested: 1999121915 Platform: NT 4 sp5
Assignee: karnaze → evaughan
Reassigning to evaughan.
Status: NEW → ASSIGNED
Target Milestone: M15
Target Milestone: M15 → M20
Its an interesting idea. Fortunately we are pushing the kit so that the scrollbars implementation will eventually be written in javascript and will live in you chrome registry as part of the skin. Skin files will not just be a look but also the feel. So I'm sure someone will eventually make scrollbars work the way you want them. And if not you could easily just edit the javascript and make it work however you wanted.
*** Bug 21243 has been marked as a duplicate of this bug. ***
From bug 21243: a possible compromise, if the currently specified scrollbars are not well recieved: make the scrollbar and view snap back if the cursor strays too far outside the window, so there is still a way to do that, but it would be essentially impossible to do accidentally.
Component: HTML Form Controls → XP Toolkit/Widgets
The standard (on major platforms that have a standard) ability to cancel is by dragging some distance away from the scrollbar, which snaps the thumb back to the starting position. Rather than introducing some non-standard means, especially one that involves the keyboard, we should support the accepted MacOS/Windows standard of snapping back if the cursor gets more than a scrollbar-width away while dragging the thumg. Personally, I think it would be a huge improvement if we could have this distance controlled by a hidden pref. Especially on a large monitor, I have trouble staying within such a narrow vertical band. Linux is infinitely forgiving in this, but provides no way to cancel. In any case, I think we need to do this work, moving to M16.
Keywords: pp
Summary: request: ability to cancel dragging of a window's scrollbar → Need to be able to cancel dragging of scrollbar thumb
Target Milestone: M20 → M16
*** Bug 25711 has been marked as a duplicate of this bug. ***
Due to Peter's comments, and bug 25711 being resolved against this one, please consider changing platform/OS to all/all. - Adam
Agreed; neither the expectation of, nor the usefulness of, cancelling scrolling is platform specific: changing to "All/All" and removing "pp" keyword. I'd rather see *some* way of cancelling scrolling by mousing by straying horizontally, but if this really is not going to happen, the original proposal of having [ESC] cancel the scroll, while probably a pain to implement, would be far better than nothing. Ever tried to read the MySQL manual online? Let's just say that if you lose your place you'd better have remembered the subsection number.
Keywords: pp
OS: Windows NT → All
Hardware: PC → All
Exactly. In IE5, the scrollbars changed so that moved away from the scrollbar horizontally (for vert. scrollbars) didn't cancel the scroll. So many times when I was using it (hey, I have to explore new technology), I lost my place in the very large document I was reading. _Very_ annoying. One point made in the discussion in the newsgroups a while back was that it was too easy to move outside the scrolling range, so the document was always jumping around. So make the default safe scrolling range something huge, like 200 pixels on either side of the scrollbar or the edge of the screen, whichever comes first.
On the Mac at least, this is part of Apple's HIG. It's not really a feature, it's expected behavior. Please see bug 25711 for a complete explanation and link to Apple's HIG manual. - Adam
Please, let's not talk about the escape key any more. Forcing people to go to the keyboard to cancel a mouse operation is just too painful to contemplate. Since the Mac HIG spec on this is so concise, I'm including it here (Win IG just paraphrased it anyway): "If the user starts dragging the scroll box, then moves the pointer out of the scroll bar, the scroll box stops following the pointer and snaps back to its original position. The user can move the pointer out of the scroll bar region by a little more than the width of the scroll box before the scroll box snaps back. If the user then releases the mouse button, no scrolling occurs. But if the user, still holding down the mouse button, moves the pointer back into the scroll bar, the scroll box resumes its movement in the direction of the pointer. This type of tracking is standard behavior for controls in general, such as buttons, checkboxes, and radio buttons."
This is technically pp, since it's normal behavior on MacOS and Win32 but not in Motif or (IIRC) GTK. However, I think Unix users would like this feature as much as anyone else. I don't buy any argument that not implementing the drag-away method makes anything easier for anyone. *As well as* the drag-away method, clicking the right mouse button (for those platforms which have one) while the left mouse button is still down should cancel the drag. This would be a lot nicer than pressing Escape. (BTW, I think pressing Escape is 4xp on Win32, because it's part of the native scrollbars.)
URL: any → http://developer.apple.com/techpubs/m...
Keywords: 4xp
Massive QA Contact update.
QA Contact: ckritzer → jrgm
I'm an IE user, and I've gotten used to scrollbars not snapping back to the point that using netscape 4.x has become pretty frustrating. I doubt I'm the only IE user who would have a hard time switching (partly) because of this. I like the right-click idea, but escape should also work (because that's the most obvious thing to do).
David, "I'm an IE user, and I've gotten used to scrollbars not snapping back to the point that using netscape 4.x has become pretty frustrating." How typical that Microsoft would not follow their own HIG, if indeed this behavior is UI-compliant on Windows. I'm sure there will be a prefs file that you'll be able to easily modify somewhere that will allow you the behavior you enjoy. However, "out of the box" Mozilla should behave according to HIG on the major platforms. Apple's HIG manual has a very strict definition of this behavior, and where Microsoft doesn't explicitly specify a behavior, I believe most people just follow Apple's lead anyway. Therefore, let's just follow HIG. If you don't like it, you'll probably be able to turn it off easily. - Adam
>you'll probably be able to turn it off easily. ok, that's cool.
What's the bet that Microsoft simply *forgot* to reimplement the drag-cancelling from their native scrollbars into their GFX scrollbars, rather than changing the behavior on purpose?
"What's the bet that Microsoft simply *forgot* to reimplement the drag-cancelling from their native scrollbars into their GFX scrollbars, rather than changing the behavior on purpose?" Who cares? When you use native UI widgets, you get these features automagically. You don't have to put them in; they're part of the behavior of the widget. So, at best, MS is reimplementing Windows UI widgets in their applications, which is a total waste of space (which would explain MS bloatware), because MS engineering is loopy; at worst, native Windows UI widgets are broken out of the box, forcing MS to reimplement them in their applications. In either case, you've lost the entire point of the OS having built-in support for UI widgets, and you've almost guaranteed that your UI will not follow its own standards across applications. I totally understand why we're doing this exercise with Moz. We require a cross- platform gfx toolkit so that when a developer is creating a "web application," they know precisely what their app will look like (within the browser window) on all platforms. Makes sense to me, as long as we follow interface standards on each platform so the users aren't wildly confused by Moz behavior. Hence, the reporting of this bug. Now back to our regularly scheduled programming... - Adam
Target Milestone: M16 → M18
Target Milestone: M18 → M19
Mass moving M18 bugs to M19
Instead of moving away the mouse to have the view snap back you could just hold down RMB (right mouse button). If you at this time keep RMB pressed at let go of LMB the view would permanently stay where it originally was - cancelling the scollbar movment.
Yes, the right mouse button should cancel all left mouse button drags, and vice versa. But that can only be an extra solution for those OSes with two-button mice. I shouldn't have to do the MacOS equivalent -- drag the scrollbar thumb to the menu bar -- just to cancel a scrollbar drag.
The right mouse button isn't intuitive. What most people (Win32 at least) know it for is invoking context menus. Not for canceling actions and definitely not anything to do with scrollbars.
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future' milestone
Target Milestone: M21 → Future
Given the -- Additional Comments From evaughan@netscape.com 2000-01-13 14:42 -- this looks like a natural for "helpwanted".
Keywords: helpwanted
Sounds good to me. As lame as it may sound, this is one of the main reasons that I don't use IE, other than a pro-NS bias. When reading large documents, which there are so many of on the web these days, if I can't cancel my drag and return to where I was reading, I will _very_ quickly become annoyed.
Just ran into this again while two-thirds of the way through bug 26502 (a fairly lengthy bug). Almost strangled some unfortunate soul that wandered into my office. Eric (when you're back from vacation and have waded through the thousands of email messages you must have) are scrollbars to the point that you alluded to on Jan 13? If so, where would someone start attacking this bug? If not, was there a design change?
Let's not forget that this is an issue for all drag operations, and only scrollbar drags can have the drag-away capability. Hence a consistent cancel operation is important.
Blocks: 70279
I agree that right-clicking isn't the most obvious thing to try. I think pressing escape to cancel dragging the scrollbar is the most obvious solution for a user to find. Having the scrollbar snap back after drifting from the scrollbar, on the other hand, is counter-intuitive and sometimes annoying (although very discoverable because it's so easy to trigger accidentally).
Using keypresses to cancel mouse operations always scares me. It takes me a second or two each time to figure out what I need to press and release, and in what order, to successfully cancel the operation (no matter how many times I do it); it just isn't intuitive. (Maybe that's just 'coz I'm an idiot :-)
This still really bugs me. Any complaints by anyone if I start looking down the press-Esc-to-cancel path? We can always look at other things later, but I'd really like to have something to cancel the drag.
Well, please don't do this on Mac. You'll simply make things more broken than they are, and you're also violating HIG. Let's shoot for HIG conformance first, before we start trying to figure out how to make things "better." If you really want this, hack your own downloaded copy of Moz. I'd wager that the other 99% of the Moz-using populace simply wants 1.0 out the door, and as HIG-compliant as it can be. - Adam
Hey, I'm not saying ignore the HIG. I'm saying that I want _something_ to do this, and Esc seems easier for me to implement when thinking of the options. I don't think this would break anything on the Mac, nor I don't see it as "violating HIG" as you put it, unless Mac has something else reserved for Esc while in the middle of a scrollbar drag. But from my years of using a Mac, I can't remember anything.
Please see the URL at the top of this page. It's a link to Apple's Developer Tech Publications, that explain proper cancel of a scroll. Forcing the user to hit escape is non-intuitive, and does not follow HIG (on Macintosh, which tends to lead the way for everybody else's HIG anyway). Adding your escape cancel might be nifty to some, but only if it's in addition to, and not instead of, the HIG method. (in other words, if you want to go in and add both w/a pref toggle somewhere, be my guest; if not, you're really not helping.) We're just going 'round and 'round on this, and wasting the other readers' time. A similar bug I wrote was resolved against this one; if you go back and read through this entire bug, you'll see that this has all been discussed before. - Adam
Please stop running around in circles!! masri@nolex.com I'm sure whomever spends their time implementing drag away cancel will read the macos hig. filed bug 72775 Escape should cancel scrollbar thumb dragging operations filed bug 72776 Right Click should cancel scrollbar thumb dragging operations this bug is now limited to the one silly implementation described by hig et al. file new bugs for any others.
Summary: Need to be able to cancel dragging of scrollbar thumb → dragging thumb away from scrollbar should cancel scrolling
Vast apologies to timeless and everyone else, but I have to reply. masri@nolex.com, please see the original reporter of this bug and the original description. I feel this gives me some right to offer to work on my own suggestion. Thanks, timeless, for opening the other bugs. I'll ignore this one now. I was not intending it to go around in circles, I thought I was quite clear. Oh well.
Fwiw, I've lost my place in documents several times while using IE 5.5 because IE 5.5 *does* support this feature. The most recent time was when I had been dragging with the mouse down for several pages and wanted to click on a link, and started moving toward the link just before releasing the mouse button.
What I've been struggling with for the past several hours... There's a whole wack of co-ordinates in nsSliderFrame.cpp. Which one stores the original scrollbar position? mDragStartPx? mThumbStart? And do I have to convert these to something else before calling SetCurrentPosition()?
Attached patch patch, take 1 — — Splinter Review
I think I figured out what to use for the original position: (int) (mThumbStart / onePixel / mRatio) The only time this doesn't seem to work is when the thumb is at the very bottom of the scrollbar. It pops back to one pixel above the end. Nothing major, I don't think.
Forgot to mention that I give a 100 pixel buffer on each side of the thumb, so it's not overly easy to drag off of it.
Adding keywords, looking for an r=. I think we can address that one pixel problem I mentioned later, as polish. This bug is on my dogfood list, recommending that we get this in for at least 1.0.
Keywords: patch, review
I suggest changing `100' to `(6*thumbSize.width)'. This is pretty much the same as 100 pixels for a 16-pixel-wide scrollbar, but it's also forwards-compatible with much higher screen resolutions in the future. (You may want to do that when fixing up the off-by-one error later, so as not to hold up this patch.)
But if someone makes a garish theme with a thumb width of 100, I've all but lost this functionality on my 800-pixel wide display. Apple's HIG states that it should be "a little more than the width of the scroll box", but I think that's too much. Really, 6*thumbSize.width is as arbitrary as 100, isn't it?
My width is 9px, so that'd be 36. nc4w32 is behaving near ~100px.
Errrr.... you mean 54.
yeah yeah... *sigh* we're really making a mess of the little things.
Bah. If you're silly enough to use a a thumb 100 pixels wide on a display 800 pixels wide, you *deserve* to lose this `functionality'. :-) The only app I can find which follows Apple's `a little more than the width of the scroll box' guideline is 4.x itself, and there it seems too constrictive. All other apps I have seem to use about 6*thumbSize.width (though this is probably hard-coded in their case, like the thumb size width itself is).
Well I'll be damned, it does adjust in Window based on the size of the scrollbar. mpt, are you sure it's 6X, or are you guessing? (And quit knocking my pathetic, 800-pixel display!)
First, a suggestion. I like the 6x scrollbar width you came up with, but why not limit it to some arbitrary # of pixels, like 50, or 100, or (edge of screen)-20? That way, it doesn't get ridiculously large, and yet the scroll is still cancelable? Of course, that brings us back to what my original complaints were. Dean, exactly which bug are you fixing? The name of this bug is "dragging thumb away from scrollbar should cancel scrolling." If this is not the bug you are fixing, then I suggest you move your discussion off to one of the bugs timeless so graciously opened (with my name appearing at the top of each), bug 72775 and bug 72776. Once again, I need to remind you that other bugs that wished a scroll cancel have been resolved against this one, so I'm just trying to keep this one on topic as best as I can. The fact that you created this bug is irrelevant. And just an aside to timeless, why would I be angry that you followed Bugzilla directions, and opened new bugs for those desired features? Good job. :) - Adam
as far as I can tell, the patch is indeed fixing this bug...
would it be possible to make this (hidden) pref controlled? Preferably that 6 but even turning the whole thing off would be ok. I usually use rather high resolution display with high mouse sensitivity and curse that snapping-back feature much more often then I use it.
I don't know prefs that well. Someone else would have to do that, maybe in a separate bug dependent on this one?
There's a pending patch for this. Can we set this to mozilla1.0?
r=timeless, could you add //XXX see bug 22185 or some new bug number for the minor pixel off issue?
Status: ASSIGNED → NEW
Keywords: helpwanted, review → approval
Target Milestone: Future → ---
really reassign to dean.
Assignee: evaughan → dean_tessman
Blocks: 81586
Allrighty. Setting target to mozilla1.0. New patch coming with reference to bug 81586. cc: hyatt for an sr=.
Target Milestone: --- → mozilla1.0.1
Dropping milestone down to 0.9.3, since I think this should make it in before 1.0, and cc:ing blake for a possible sr=.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla0.9.3
sr=blake
OK, now all I need is for someone to check this in for me. Any takers?
This is a mozilla0.9.3 bug with an r= and an sr=. Can someone check it in?
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This should be backed out or made platform specific. Unix users are used to scrollbars which remain scrolling without snapback as long as they are held (both motif and gtk have this behavior).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Marking fixed again, since the patch is checked in and the platformos for this bug is set to all/all. See my 2001-05-06 21:33 comment regarding a pref. File an RFE to make this platform-specific, in a separate bug.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Tested this on Linux: I like it.
Have to agree with Tor. This feels disgusting and wrong under unices. Should be pref'd and disabled by default on unix.
I agree with tor too, this is now "broken" on unix.
And I agree with Dean, file a new bug if you don't like it because it's not getting fixed here.
Ok, see bug #90982
for prefing see bug 90985 instead.
Blocks: 90985
No longer blocks: 90985
This has been in for two years and definitely works. Verified Fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: