324024 - Vertical scrollbar: dragging button down impossible

Status: RESOLVED DUPLICATE of bug 367028

(Core Graveyard :: Widget: Mac, defect)

Description

[dex_sf]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

For some pages it's not possible to scroll down by dragging down the button of the vertical scrollbar. Clicking the scroll arrows works, as well as clicking in the scroll bar. After clicking in the scroll bar dragging is possible again until the button is moved to the top position, then dragging doesn't work anymore again.

As long as dragging is blocked by one page, dragging is blocked for the other tabs in the window as well until the page that blocks is closed.

On http://www.auto-motor-und-sport.de/ vertical scolling by dragging is not completely blocked but not working properly as well.

 

Reproducible: Always

Steps to Reproduce:
1. load http://www.bild.t-online.de/BTO/index.html
2. keep the button of the vertical scrollbar left clicked 
3. try to scroll by dragging down the button of the vertical scrollbar

Actual Results:  
The button doesn't move, scrolling down doesn't work

Expected Results:  
The button should move according to the movement of the cursor, the page should scroll down.

Comment 1

[Tracy Walker [:tracy]]

this is a regression from 1.5 on Mac

Comment 2

[Tracy Walker [:tracy]]

also notice that when licking on the scrollbar slider the ticker at the bottum of the screen pauses until the slider is released.

Comment 3

[Tim Riley [:timr]]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I see this also.  Works on 1.5.  Horked on 1.5.0.1 RC1.   http://www.bild.t-online.de/BTO/index.html causes vert scroll bar to freeze.  The drag scroll is still frozen when going to other pages in other tabs.  Other browser windows are not affected.

Closing the offending tab or replacing the URL in that tab with another clears the problem.

This is also only when the scroll cursor (or what ever you call the blue highlighted part of the scroll bar) is at the top.  If you click further down the scroll bar to move the cursor down, the cursor can be dragged normally until it hits the top of the scroll bar.  Then dragging is locked out until the cursor is again moved in a way other than dragging.

This also seem to affect scroll bars inside web pages such as the scroll bar to the left of this Additional Comments field in Buzilla!

Comment 4

[Marcia Knous [:marcia]]

Could https://bugzilla.mozilla.org/show_bug.cgi?id=314856 possibly be the culprit?

Comment 5

[Mark Mentovai]

This was caused by bug 311399, which works around even worse problems caused by bug 282940.  Our hands are really tied on this one.  What's happening is that when the user wants to scroll with the thumb, we call into the system's tracking function, which is supposed to block the UI thread and not return control to us until the mouse button comes up.  Since 282940, we use CFRunLoop for PLEvents.  The system's tracking function runs its own internal run loop on CFRunLoop also, so the result is that PLEvents still fire while in tracking.  Some of those PLEvents change various bits of state, notably the port origin, which interferes with the way the Control Manager does its job.  Without any additional attention, this results in scrollbars drawing in the wrong spot, and in jerky scrollbars.  Bug 311399 and others contain workarounds for these behaviors, but on very active pages, it's possible for the port state to get messed up again in between the time we fix it up and the time we get another opportunity to handle a moved scrollbar.

I haven't found a good way to filter the PLEvents while tracking a scrollbar.  That would be the best way to address this problem.

For me, scrolling with the thumb works, except it pauses periodically.

I recommend this not block 1.5.0.1, but if we come up with a better solution (like filtering PLEvents), it should make it into a 1.5.0.x release.

Comment 6

[Marcia Knous [:marcia]]

Based on Mark's comments, nominating for the next release.

Comment 7

[Daniel Veditz [:dveditz]]

Not blocking 1.8.0.1 (see comment 5). It's probably not a true 1.8.0.2 blocker either but leaving nominated for the visibility since we would like a fix.

Comment 8

[Simon Fraser [no longer active]]

We could still play with the runloop modes for which we fire plevents.

Comment 9

[Daniel Veditz [:dveditz]]

Doesn't look like this will make 1.8.0.2

Comment 10

[Pierre de La Morinerie]

Attachment: Testcase on Windows - overflow of an anchor content

When applying the "overflow:auto" rule to the content of an anchor, the scrollbar button is not draggable.
Tested on WinXP SP2 with Firefox 1.5.3

Comment 11

[Mark Mentovai]

Comment 10 must be a different bug, this should be Mac-only.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Mark, can you reproduce this with a nightly build of a branch nightly? We're not seeing this right now (using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1a3) Gecko/20060627 BonEcho/2.0a3) and are wondering if we had a serendipitous fix or not.

Please renominate for blocking if we're wrong, or mark worksforme otherwise.

Comment 13

[Mark Mentovai]

I still see the same interference on 1.8.1b that I see in 1.8.0.x.  The site may have changed over the past several months in such a way that makes the behavior less aggravating.  The degree of annoyance is probably also directly influenced by connection speed.  You're looking for the page to "jump" as you're scrolling while it's loading.

Comment 14

[dex_sf]

Yes, the page has been modified massively lately. Especially the JavaScript news ticker has been removed. As you guessed, Mark, that modification makes the page a lot less aggravating.

Comment 15

[Mark Mentovai]

http://www.auto-motor-und-sport.de/ (from comment 0) still shows the annoying behavior.

Comment 16

[Patrick Nagurny]

I'm using 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
and I still am having the same problem.

Has this bug not been fixed yet?

I don't remember this being a problem before on my Macbook Pro..only this version and last version I've really been noticing it.

Comment 17

[Patrick Nagurny]

For the record, this bug and bug 396597 appear to be the same.

Comment 19

[Nochum Sossonko [:Natch]]

Th testcase has been improved a bit by bug 506081, however since links are by default draggable, it still doesn't work perfectly. The original url seems to have changed dramatically since this bug's been originally filed.

Comment 20

[[:Aleksej]]

(In reply to Pierre de LA MORINERIE from comment #10)
> Created attachment 221952 [details]
> Testcase on Windows - overflow of an anchor content

Described in bug 367028.