2001010908 linux SEA Been seeing this forever, haven't found a bug on it: When i click scrollbar area above or below slider in 4.75, and then keep mousebutton pressed in, the slider will slide till it reaches top or bottom of page. If i move the mouse during this (still pressing button) - it doesn't change anything - slider still slides till it reaches top (or bottom) - or till i release mousebutton. The behaviour in mozilla is quite different: The slider will only slide till it hits the point i pressed at on scrollbar. And if i move the mouse while button is pressed, the scrolling completely stops. I much prefer the behaviour in NC4.75 in this respect, as it is way easyer to maneuvre with. Smoother, fewer clicks, less jerky.

typo

I'm sorry you don't like it, but it is behaving as designed. ->invalid.

Tsk tsk. Reopening and filing as RFE.

I would like to add that not only is this feature-request 4xp, and in other words in line with how NC4.* behaves on Linux: It is in also how every Gnome and KDE application with scrollbars behave.

Well, we aren't really a Gnome app or a KDE app, and we certainly aren't a Motif app, so we aren't bound by their behavior. I wish there were platform guidelines for the UI, as there are on Mac and Windows, but AFAIK there aren't. Personally, I think this is a defect in their toolkits; most GUI environments work the way our scrollbars do. I find it very strange to have the mousedown in the pageUp area, yet have the window paging down, as eventually happens with the behavior you want. We actually had this behavior in an early implementation, but it was considered a defect, and we got a lot of strong negative feedback about it. In any case, we will probably move such behavior into JS in the future, so it can be skinnable, and someone can write a Gnome-ish or Motif-like theme, or whatever other look/feel they prefer. ->evaughan/future

changing summary. Being the same as 4.x is not the issue. Being the same as other apps is. Personally I much prefer the mozilla way, but I am a windows user.

If memory serves me right, this is also to some extent normal behaviour in Windows applications: Once you've grabbed the slider and still hold button pressed in, the window is still responsive to the drag if you zig-zag your way a little - outside left/right visible scrollbar. It doesnt "drop" the drag as soon as you are outside visible border. Which, in my opinion, is a user-friendly behaviour - we are organic beeings, and some have problems dragging the slider in a perfectly straight line downwards etc.

This bug has nothing to do with dragging the thumb, it is about whether holding mouseDown in the pgUp/pgDn area of the scrollbar will continue to cause scrolling in the same direction, even when the thumb moves to the other side of the cursor. New summary is thus much too broad. Current behavior matches Windows (98 at least) and Mac.

Sorry.. I should take a break. But compare it: The behaviour is inconsistent: The slider button behaves correct - responding as long as grab is held. It would be logical that the rest of the scrollbar area behaved in the same way.

rkaa, is this a dup of bug 31490?

Not an exact match.. Linux behaviour differs in that it keeps scrolling. You can page-scroll a whole page with one click and no movement on Linux. In bug 71458 comment 1, Trudelle thinks that is plain wrong - but I like it - it's a practical feature.

Changing summary from [RFE] Browser scrollbar on linux should behave like Gnome/KDE/Motif scrollbars to Linux: click-and-hold in scrollbar elevator should not stop at cursor position Does this really depend on bug 78248? Click-and-hold works on Windows and Linux, it's just that it shouldn't stop as soon on Linux in order to be consistent with other Linux scrollbars.

Anyone check what the Gnome UI Guidelines (for Gnome 2.0) are saying about this?

If there is currently nothing to determine if a mouse-button is pressed.. that - IMO - seems to be a requirement for a fix of this bug. see comment http://bugzilla.mozilla.org/show_bug.cgi?id=71458#c2 where bug 79248 is also a dependency

typo: bug 71458 depends on bug 78248

wrt comment 13, I didn't see anything relevant to this in a quick skim of the GNOME 2.0 Human Interface Guidelines (CVS draft) http://developer.gnome.org/projects/gup/hig/ ... but then, why would there be, as there's the common toolkit in that context. The gtk+ 1 and 2 bits I have work as described in this bug, i.e. holding mouse button down in the scrollbar through scrolls pages so the scrollbar thumb goes all the way and past the mouse pointer location.

This bug needs attention as it affects basic functionality. It does not depend on bug 26828 [Platform-specific look+feel for <scrollbar>] as suggested in the summary above. That one has to do with /appearance/ of the scrollbar, this one has to do with the function of the slider in respect to both primary pointer button state and pointer location. I fail to see the reason why it would block bug 78248 [[RFE] API to determine if a mouse button is pressed] either, but that's neither here nor there. bug 71458 [Scrollbars don't adjust to new mouse position while in a page scroll] was referenced at one point in these comments, but that one should in no way pertain to Unix(Linux) implementations using the GTK stuff, since the slider should already be motoring towards the end of the scrollbar toward which it was started, while the primary pointer button remains pressed, regardless the pointer's current position. There are actually two bugs being represented by this present(ly inactive?) bug: Primary: the slider does not continue past the point in the trough from where it's motion was initiated with the primary pointer button, as it should within the framework of the GTK. Secondary: the slider ceases motion for this activity if/when the pointer (with yet held primary button) leaves the trough. I hope those descriptions are succinct enough. In the GTK+ 2.0 Tutorial, Chapter 8, "Range Widgets", (currently available at http://www.gtk.org/tutorial/ch-rangewidgets.html) it's stated in the very first paragraph: "Dragging the slider with the pointer moves it back and forth within the trough, while clicking in the trough advances the slider towards the location of the click, either completely, or by a designated amount, depending on which mouse button is used." That information is unchanged from the tutorial for version 1.2 of the toolkit (currently available at http://www.esc.auckland.ac.nz/Docs/gtk/gtk_tut.html). The action of advancing the slider directly to the point in the trough where the pointer resides while pressing the middle button (button 3?) has been correctly implemented. That corresponds directly to the "by a designated amount" above. The slider currently remains captive and active regardless the pointer location in the entire screen so long as the button remains pressed. It would appear that in this matter, the middle pointer button works perfectly with the scrollbar - don't change anything there. The action of completely advancing the slider while the primary pointer button is pressed has not been properly implemented using the current toolkit. In the context of the GTK, the primary button in the scrollbar trough does not designate extent of slider travel, but simply direction. The current implementation has apparently been assigned the action specified in an entirely different (foreign?) toolkit which does not natively put numerous pointing device buttons to use. In fact, the current implementation appears to have in some way combined the two functions (distance and direction of travel) which are clearly separated in the GTK, and relegated to different buttons. If the current implementation isn't found to be puzzling, see the paragraph previous to this one and ask, regarding it, "why was this even done?". If this bug needs to be broken into two separate items to get fixed, then that's fine. But it definitely needs attention. Primarily, as respects the extent of slider travel; and secondarily, as respects the cessation of same if/when the pointer leaves the trough. I searched through the past year's worth of messages in netscape.public.mozilla.ui, which I deemed to be the appropriate forum, and found nothing regarding this matter, so please be kind to me if I'm out of line here.

IMO, the key phrase in the text you cite is "towards the location of the click". This bug asks for it to continue past this location, which would then be away from, rather than toward the click. I still think this is invalid, and the toolkits you mention are defective.

I understand it to mean (both by the text and in conjunction with experience) to mean that the slider *starts* moving in the direction of the click, and it advances *completely* in the scrollbar. Your current implementation on Unix is broken. It breaks the Unix toolkit you've chosen. We have a working "come to this point" function. We don't need our "scroll completely in this direction" tool broken to incorporate the former by the evident desire of someone (who doesn't use our tools?) to "fix" it for us based upon their mis-{understanding,appreciation} of them. The left mouse button action for Windows, and the only button action for the Mac targets, have been "fixed". Can't you see fit to do so in a way that doesn't break ours in the process? It's not as if the criteria were commonality across systems (which would be a bad idea) since there's already divergent behavior, both specified and realized. Please provide a way for the compilers to skip the breakage while producing executables for us. The current "severity" classification is incorrect but I don't have the authority to alter it. This is not a request for an enhancement, but rather a very real (and aggravating) bug. I have to wonder why, if you think the toolkits are defective, you opted to use one of them.

This is the exact same issue as bug 71458, which is a valid bug for Windows. I'd prefer marking this as a dupe of that bug, since 71458 is much cleaner.

I don't think this is a dup of that bug, and the issue here is that correct behavior may differ by platform. I've appealed to the Gnome 2.0 folks directly to help clarify this fine point.

In all scrollbars i've seen besides mozilla that _do_ stop at the cursor position, they continue paging if you subsequently move the mouse further along the scrollbar in the direction in which you are scrolling. Mozilla fails to do so.

------- Additional Comment #22 From random832@rcbooks.org 2003-04-05 14:54 ------- > In all scrollbars i've seen besides mozilla that _do_ stop at the cursor > position, they continue paging if you subsequently move the mouse further along > the scrollbar in the direction in which you are scrolling. Mozilla fails to do so. See new bug 224599 dealing with that specific aspect.