iOS like "rubber band" scrolling in Lion - Safari

It works in many apps but not all. Most probably it doesn't work for apps which use a custom implementation of elastic scrolling.

To be honest, I'd be happy if I could simply get it to work in Safari only.

Does Safari use a "custom implementation of elastic scrolling?" If so, why would it?

Good question, I don't know :/

I didn't figure it out. Tclement heard my cries of pain and gracefully added a few lines of code to an open source plugin for Xcode.

The lines of code you are referring to are in the header files for NSScrollView which, along with the NSScrollView programming reference were what I was trying to get working for TextEdit (and did) some weeks back around 3:30 AM.

It's the figuring out how we can disable this globally, or write the variable states into plist files that I'm also very interested in getting understood.

I just want to be able to disable all the crud in Lion so that it is a usable OS for me, considering that we will have to move to it some day.

Bouncy ScrollViews, gray scroll bars where the graphics don't fill the width of the active scrollthumb, (they are the width of a quarter on my MacBook Pro) and apps that auto quit but really don't quit just make Lion useless to me.

Once I am able to get the scrollViews fixed and auto quitting disabled I'll see what I can do to to add bounce back to Mail so I can bounce back all the junk my friends send me.

Thanks Tom, you've helped immensely.

Adding bounce to Mail will likely require a plugin of sorts.

AFAICT, NSScrollViewRubberbanding isn't one of Apple's approved constants. Nothing, except a deprecated AppKitJava pub pops up, but that only mentions rubberbanding WRT NSBezierPath objects. As Topher Kessler mentioned, it doesn't work.

Just for the sake of completeness and collaboration, I found another discussion going on about the same issue, with many of the same ideas bandied about, here: http://apple.stackexchange.com/questions/18187/can-you-disable-rubber-band-scrol ling-in-os-x-lion

Fofer wrote:

Indeed, I have just pasted the following command into Terminal.app:

defaults write -g NSScrollViewRubberbanding -bool false

And guess what?!?!? It works. No more inane rubber-banding. Hurrah!

But only in TextEdit.

It doesn't work in Safari, where we are wanting it most. Boo!!!!

One step closer, though?

Interesting, since it's not documented anywhere that I can find.

It actually works in all applications I've tried, except for Safari. It turns off the behavior in the Finder, TextEdit, Firefox, Pages, and basically everything...except Safari.

Well, aint' that a kick in the head. I mean, yeah, it's great, and I certainly appreciate it... but Safari is the one app where I notice it most (and am annoyed by it.) LOL

What the fudge?

It doesn't seem to worn in iTunes either.

But it works in every other app I have tried - Hallelujah!

How about Chrome? Am I doing something wrong or it doesn't apply there either?

I have the Safari Webkit source so I'll see what I can look into. Maybe do a custom build there, or a pList preference.

That is probably because the WebView might have a superclass that is an NSScrollView and we would have to set it for the the parent view.

I'll see what I can look into tomorrow. I don't have a Mac OS dev license, but just an iOS dev license.

baltwo wrote:

Fofer wrote:

Indeed, I have just pasted the following command into Terminal.app:

defaults write -g NSScrollViewRubberbanding -bool false

And guess what?!?!? It works. No more inane rubber-banding. Hurrah!

But only in TextEdit.

It doesn't work in Safari, where we are wanting it most. Boo!!!!

One step closer, though?

Interesting, since it's not documented anywhere that I can find.

There's a key difference between what we're doing here (setting an undocumented preference) and anything you'll find in the documentation, which is that the latter is part of the programming API, and so will is documented, and will definitely work, but will require you to recompile the entire program to apply the change, essentially. The nice thing about the undocumented preferences is that they will continue to work until either the code that checks them is removed or you set them to be otherwise; custom binaries require a lot of work to keep up with software updates and the like.