Open Bug 496725 Opened 15 years ago Updated 2 years ago

repetitive scrolling with single mouse click in scrollbar

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: newtz, Unassigned)

References

(
URL
)

Details

(Whiteboard: DUPEME) 

User-Agent:       Opera/9.80 (Macintosh; PPC Mac OS X; U; en) Presto/2.2.15 Version/10.00
Build Identifier: Version 2.0b3 (1.9.0.11 2009060219)

Upon clicking within the non-thumb area of a scrollbar to scroll a page, Camino acts as if the mouse button is stuck or bouncing.  At least one, sometimes multiple page scrolls occur.  

Reproducible: Sometimes

Steps to Reproduce:
1.Load a web page in Camino, preferably as a URL referred from a different application (e.g. - Vienna).  Will also occur when changing focus from a different application to a page loaded from a URL clicked in Camino.
2.Click on the Camino icon in the Dock, bringing the fully loaded page into focus.  Page must have more than 2 screens to scroll.
3.Click on the scrollbar to scroll the page.  
Actual Results:  
After the first (or sometimes the second after a 'normal' first) click in the non-thumb area of the scrollbar, the page will scroll multiple times.

Expected Results:  
Scroll once to the next page.

This problem does not occur in any other application (e.g. Camino 1.6).  

When switching from a different application to Camino, a previously viewed page that had already been scrolled down several pages will exhibit the behaviour when attempting to scroll upward (i.e. - the bug is bidirectional).  The bug appears to be triggered by bringing Camino into focus, when another application had previously been in the foreground.

I am running a G3 Firewire Powerbook, Mac OS X 10.4.11, all security updates applied.
Do you have any other pages open in Camino besides the one that opened from the external app?

For that matter, does the problem still occur if you use Troubleshoot Camino to run with a fresh profile?

http://pimpmycamino.com/parts/troubleshoot-camino is the URL for it.

Have you tried another mouse, if possible? (I doubt this is the problem but it's worth a shot.)
> Do you have any other pages open in Camino besides the one that opened from the external app?

It can happen if I close all windows in Camino, and have the external application open a window.  It can also happen when Camino has several tabs open, and I switch back and forth between Camino and the other application - on a page that shows the symptoms.  Not all do.  The one I cited was an example of many that I have experienced.  It also appears that it is not necessary to have an external application open the page in Camino.  That just seems to me to be the most reliable way to trigger it by my browsing habits.  I can put together a list of other pages that have triggered it.

> For that matter, does the problem still occur if you use Troubleshoot Camino to run with a fresh profile?

I downloaded Troubleshoot Camino and tried it.  I normally have Camino set to work within one window, opening new tabs.  The troubleshooting profile opens in separate windows, which still show the behaviour.  I saw it on two separate windows of the same web page.

>Have you tried another mouse, if possible? 

Well, I just tried the one on my G4 Cube after I installed the v2.0 beta 3 on that computer...  Saw the 'bug' on the Cube also.

So - I have seen it happening on two PPC computers now.
OK, just wanted to make sure we had all the bases covered.

I'll try to look at this tomorrow on my PPC machine. (Have you tried it at all on Intel?)
No Intel Macs here - yet.  There is one G4 PowerBook running Leopard that I might be able to test it on.  I'll see if I can get some hands-on time with it in the next day or so.
OK - I tried the v2.0 beta 3 on a 15" PowerBook G4 1.25GHz running Leopard, and saw the same issue.
Can you get this to happen when opening a link in an app that immediately brings Camino to the foreground? (For example, double-clicking links in most e-mail clients will do this, while most newsreaders leave the browser in the background.)

I can't reproduce this behaviour on my PBG4/1.5 with links that bring Camino to the foreground. I haven't tried installing a newsreader on there yet.

It's possible it could be page-specific, too. Can you give an example of a page that triggers it *fairly* reliably (doesn't have to be every time, just most of the time)? I've been trying with some Wikipedia pages (e.g., http://en.wikipedia.org/wiki/Huntington%27s_Disease because it was convenient) and I'm so far unable to get it to happen.
Did some more testing, including with the URL originally given here. I *think* I saw this a couple of times, but once I turned on ad-blocking, I couldn't seem to get it to happen except *maybe* once. I'm thinking this could just be an artifact of using a slower Mac, and all the CPU-intensive ads on that Yahoo news page really aren't helping.
When I use my mail client (PowerMail) to open the link to this page from the Bugzilla notification, launching Camino and bringing it to the front, I get the problem.  I've repeated it 5 or 6 times in a row.  Quit Camino, open link from mail message, click in scroll bar, screen scrolls at least two pages.

It happens for me with ad blocking turned on.  I'll keep testing to see if I can find a preference that changes the behaviour.
Hmm... - It seems that (on this page, at least) closing the window and leaving Camino running does not trigger the symptom when an external link again brings Camino to the front, while quitting Camino and then using the external link to launch Camino and open the page does trigger the problem.  Again - tested on this page using a mail link.
I haven't found any preference that I can change that will affect what I am seeing - with the caveat that I changed preferences and worked within currently loaded pages, or reopened pages without relaunching Camino.  

I foggily recall that there was another application that was updated (possibly an alpha or beta) within the past few months that I saw this symptom as well.  I may just be remembering loading an earlier build of Camino 2 (which I did, but removed without doing much, if any testing).

I would welcome suggestions for other things to try to further clarify what I am seeing on my 3 PPC systems.

 - Don
Still seeing this in Camino 2.0b4...

Annoying enough to render the program unuseable.

 - Don
Do you have any custom mouse software installed?  Or any hacks/haxies installed?  Does the problem persist in a fresh Mac OS X user account?

Is anything logged to the Console when you see this behavior?
Also, do you see this problem if you test with Firefox 3.0.x? (And if so, how about
Firefox 3.5.x?)
Do you have any custom mouse software installed?  - No

Or any hacks/haxies installed? - Nothing in any of the following in the /Library folder:
  Startup Items
  Bundles
  Input Managers
  Launch Agents
In LaunchDaemons, I have the plist file for Little Snitch.

Does the problem persist in a fresh Mac OS X user account? - Yes, I have a clean account I use for such purposes.  The only things that were running in that account when I verified the problem were Flip4Mac Prefpane and Little Snitch.

Is anything logged to the Console when you see this behavior? - Nothing

Please keep in mind that I saw this same behavior in the previous beta on a PowerBook G4, an iBook G4, and a Pismo (the latter is what I am running).  The PowerBook is running Leopard, the rest Tiger.  I also just finished doing an erase/install of Tiger on my G4 Cube, and after doing all the Apple updates, the only software I added was Camino 2.0b4.  That one also shows the scroll anomaly.

I did notice that I can reproduce the problem on an intermittent basis just by accessing a bookmark and waiting for the page to fully load.  I saw it both on Amazon.com and the Yahoo! News bookmarks in the default install (but not all the time).

I'll try to have a look at Firefox a bit later today.
I did not find a download link to Firefox 3.0.x, but I did try v3.5.3, and it _does_ show the same behavior on my Pismo.
Sending to Cocoa Widgets, since it's not a Camino-specific problem.
Component: Accessibility → Widget: Cocoa
Product: Camino → Core
QA Contact: accessibility → cocoa
How do I get action to be taken on this bug?  Since my last post, I have downloaded and tried Firefox 3.5.3, Thunderbird 3, Camino 2.0.1 and 2.0.2, and SeaMonkey 2.0.3, and _all_ have shown this same bug.  It is sufficient annoyance that I find the programs virtually unuseable, as it interrupts my work flow.  Yes, I know there are other ways to scroll, but I am 60 years old, and have some pretty well established mousing habits :^)

To summarize and clarify the above history, the window will scroll multiple pages when clicking below the scroll bar, if there are several pages of scrolling available.  It is erratic and not particulary reproducible. The best approximation of a description that I can come up with is that it is (sometimes) as if the Appearance pane 'Jump to here' preference was engaged, except the window makes several jumps instead of a single jump as in the 'Jump to here' mode.  The mouse click must be more than the length of the existing scroll bar below the scroll bar, otherwise a single window scroll jump will be made.

While investigating this bug initially, I confirmed that it happened in Camino beta 2.0 beta 3 on my PowerBook G3 (Pismo), a 1GHz iBook G4, and a PowerMac G4 Cube (all running Mac OS X 10.4.11) as well as a 1.25 GHz Aluminum PowerBook G4 running Mac OS X 10.5.

Thanks!

 - Don
When I press and hold in the scrollbar track, both Firefox and Safari will scroll multiple pages after a certain delay. The difference is that in Safari the delay is slightly longer. Might that be the issue here?
If that is part of the issue, it's an awfully short delay!  Today I was trying out mail in SeaMonkey, and while trying to scroll a long list of messages (message pane hidden), was unable to click briefly enough to avoid multiple page scrolls.  For quite awhile, I was getting multiple scrolls on every click! I also noticed that clicking the scroll arrows would scroll a line more than once.  I think I noticed that it was more frequent in Camino when a download was in progress.

I find it strange that I am seeing this behavior across the line of Mozilla software (and nowhere else) on multiple computers, yet nobody else seems to have commented on it.  Maybe not so strange, however, since there are now mice with scroll wheels, two-finger scrolling trackpads and other tools that take place of classic scrollbar use.  Plus, all of the computers I have tried it on are PPC and slow by today's standards.

Is there any configuration setting that would affect the scroll delay, that I could try out?

Thanks - 

 - Don
I still think my theory in comment 7 is probably the root cause of this bug, and there's probably nothing that can be done about it short of upgrading to a newer Mac (or doing some very detailed debugging on a very early PPC and trying to figure out where the bottleneck is happening).
Ah, you mean the CPU intensive ads make the main thread block longer than the autorepeat delay, and thus we didn't get a chance to process the mouseup event before that timer fires? That could be.
Whatever is going on started in the transition from Camino 1.x to 2.x, and also in the transition from Thunderbird 2.x to 3.x - I had never tried FireFox or SeaMonkey prior to my first noticing the problem.

To add a little more data:  In both Thunderbird and SeaMonkey 2.0.3, scrolling of long lists of mail messages is particularly susceptible to this issue - especially in SeaMonkey.  The Thunderbird 3 GUI is sluggish on this computer, while SeaMonkey performs reasonably well.  SeaMonkey shows the issue similarly to what I see in Camino while web browsing.  I have been watching CPU loads, making sure that web pages fully load before scrolling, and still see it.  As I commented before, I see it from time to time on this Bugzilla page, so CPU intensive ads seem to be unlikely as a cause.

 - Don
Ads specifically probably aren't what's doing it, but to answer Markus's question in comment 21, yeah, that seems like a reasonable explanation. Replace "CPU intensive ads" with "CPU intensive activity of any kind" and I'd agree with it. It'd also explain why we're not seeing this at all on anything newer.

cl
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.