New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 161 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

No autoscroll on linux

Project Member Reported by michael....@gmail.com, Jul 24 2009 Back to list

Issue description

Chrome Version : 3.0.196.0 (Developer Build 21527)
OS + version : Linux
Behavior in Firefox 3.x (if applicable): works
Behavior in Chrome for Windows (optional): works

What steps will reproduce the problem?
1. middle-click on a webpage body and move mouse up/down

What is the expected result?
autoscroll should kick in an the page should move up/down (works on 
chrome/windows)

What happens instead?
nothing
 

Comment 1 Deleted

Comment 2 Deleted

Comment 3 Deleted

Comment 4 Deleted

Comment 5 Deleted

Comment 6 Deleted

Comment 7 Deleted

Comment 8 Deleted

Comment 9 Deleted

Comment 10 by evan@chromium.org, Sep 9 2009

Labels: Mstone-X Pri-3
Status: Available
We rediscussed this recently.

There's a technical problem: middle-click paste/open link in new tab happens on mouse 
up, while autoscroll happens on mouse down.  But we can't know if we're going to do 
the latter behavior when the mouse is held down, only when it's released.

If someone can figure that one out, I think we'd turn this on.
Thank you very much for the reply!
I am not sure I understand the exact problem. Here is how firefox does it: 

Autoscroll should not be activated if mousedown-on-webpage event happens on a text
insertion area (=paste) or on a link (=get ready to open in a new tab). 
In all other cases, mousedown activates autoscroll.

If a mouseup event follows without a significant change to the cursor location, the
autoscroll remains on (the user now scrolls just by moving the mouse without touching
the buttons). Another mouseup event is required to resume regular mode.

If the cursor moves significantly while the mouse middle button is still down, the
browser should treat it as a short-term scroll (where the user is scrolling with his
finger still pressing the button), and the next mouseup should resume regular mode.
definition of "not a linux behavior"
a) not turned on by default in any linux browser I've tested (ephy, firefox, 
konqueror)
b) conflicts with middle click paste

@9: you are welcome to write an extension that does autoscroll
Is there anything wrong with the suggestion in 11 that autoscroll should not be activated when the cursor is 
over a text input area?  Additionally, a middle mouse up event over a text area should not paste if autoscroll 
was activated (meaning the cursor moved into the text area while scrolling).

I'd be willing to implement this feature myself if it is lacking developer interest / time.

@12 I think native support would be preferable to an extension.  You can't disable autoscroll in Windows, so 
it seems odd that it's not included in Linux (which raises the question if autoscroll should be added to the 
options dialog).

Comment 14 by evan@chromium.org, Sep 22 2009

Re #13: if you can implement that without breaking any other functionality (middle-
click pasting in text areas, etc.), then I'd apply the patch happily.  I think it'll 
pretty tricky to make work though.
I had some time this weekend to try to figure this out.  I was able to get autoscroll
(panscroll as it is known in the code) to work in Linux.  It requires changes to two
files in WebKit.  See attached diffs. Autoscroll will start if the cursor is not over
a link or an editable element on the page.  If an editable item is focused but the
cursor is not over it when the middle button is pressed, the editable item will be
unfocused and autoscroll started.  The cursor does not change to arrows pointing in
the scroll direction as it does in Windows, however.  It remains the basic cursor
pointer.
linux-autoscroll.WebCore.diff
1.1 KB View Download
linux-autoscroll.JavaScriptCore.diff
404 bytes View Download
@dsargeant
Patches to webkit must be contributed to webkit since we use the upstream copy as-is. 
Here's the url with guideline with their contribution process:
http://webkit.org/coding/contributing.html

Thanks, I'll look into it.

Comment 18 Deleted

Comment 19 by ripps...@gmail.com, Oct 11 2009

Just so everybody knows, you can install the chrometouch extension that allows you to 
click and drag pages like you do on an iphone. It's not the same as autoscroll, but 
it's good substitute until someone figures this out.

http://www.chromeextensions.org/appearance-functioning/chrometouch/

Comment 20 by ripps...@gmail.com, Oct 11 2009

Btw, I built some webkit packages using the patches by dsargeant, but they don't seem 
to work on any webkit browser. However, it does work with embedded webkit used by 
simple application plugins and gwibber.
Sorry I haven't yet submitting this to upstream since I haven't had time to create a
test for it.  Ripps818, my patches should work for any browser that is built with
__linux__ defined.  I have only tested it with the Linux Chromium build.  Did it not
work for the Linux build for you?

Comment 22 by ripps...@gmail.com, Oct 12 2009

Well, here's the ppa I built the autoscroll patched webkit:
https://edge.launchpad.net/~ripps818/+archive/test
And it's buildlog:
http://launchpadlibrarian.net/32932146/buildlog_ubuntu-karmic-i386.webkit_1.1.15.1-
1ubuntu1%2Bautoscroll1_FULLYBUILT.txt.gz

I've tried epiphany-webkit, midori, arora, and chromium, and none of them had working 
autoscroll. However, gwibber and the wikipedia plugin for gmpc did.

Comment 23 by rdw...@gmail.com, Oct 15 2009

I know this may be beyond the scope of this bug, but for users with a TrackPoint-style 
pointing device, the GPointingDeviceSettings program (the successor to gsynaptics) 
makes it easy to set up scroll wheel emulation without breaking middle-click paste, 
open-link-in-new-tab, etc. For those who can employ it, this may be a better solution, 
especially since it will work with all programs on your computer.

Comment 24 Deleted

Comment 25 Deleted

I haven't accomplished much on this after I attached the patches in comment 15. I
have downloaded the full WebKit source but have been unable to compile it, or chrome
in release mode due to my version of Linux (Ubuntu 9.10). I would be happy to pass
this off to an experienced Chromium developer, otherwise this will probably take a
while for me to get it accepted in WebKit since I have to research how to resolve the
build errors.

Comment 27 Deleted

Comment 28 Deleted

Comment 29 Deleted

 Issue 23803  has been merged into this issue.

Comment 31 by dhw@chromium.org, Nov 23 2009

 Issue 28607  has been merged into this issue.

Comment 32 Deleted

Comment 33 Deleted

Comment 34 Deleted

Comment 35 Deleted

FWIW, I exchanged a few mails with some Chromium developers a while ago and there were 
technical issues keeping this from being implemented. IIRC the problem was tied to the 
middle mouse button (because of the way it is supposed to also handle clipboard).

Right now I wonder if it was possible to provide a way for a simple extension to 
enable autoscroll on another (unused) mouse button.

Comment 37 Deleted

IIRC the problem was that someone wanted to use middle mouse paste for his extension 
(pasting a url to open it in a new tab or something like that) and for some reason 
this seems to cause a problem.

Comment 39 Deleted

Comment 40 Deleted

Auto-scroll is breaking extensions developed for Mac or Linux when they run on 
Windows.  Here is the relevant issue:
http://code.google.com/p/chromium/issues/detail?id=29826

Hopefully, the Chrome team won't add auto-scroll to these platforms until the bug is 
fixed.
This is one of the reasons I can't use chrome as my default browser on linux, please 
add autoscroll.
Yep, add autoscroll for Linux! I use Chrome but I suffer :(
While you're waiting for this to be fixed in Chrome, you can use the attached 
extension to add autoscroll to Linux. Due to the security model, it won't work on 
chrome:// or https:// sites.

It shouldn't activate on text input fields, or on links. Also, if you press the 
middle mouse button, it will remain scrolling until you press it again.

However, if you drag the mouse while holding down the middle mouse button, it will 
stop scrolling when you release. This is the behavior in Firefox and other browsers.
pcxunlimited, this is great stuff :)
anything you can do about https? (chome:// is not that important imho)
also, why not add it to https://chrome.google.com/extensions ?

Comment 46 Deleted

it downloaded but there is no install dialog.

Comment 48 by ric...@inmail.sk, Dec 12 2009

I tried autoscroll on Linux and Mac and it works! Thanks!
..but it is a bit jerky.
> but it is a bit jerky

Thought the same initially but the problem seems to be that it only works if you 
actually move the mouse. On Firefox, if you go into autoscroll mode and move the 
mouse a bit down, it will slowly scroll down forever. With this, you have to keep on 
moving downwards slowly all the time.

As this is getting a bit out of topic, is there a better place to discuss this 
extension?
> While you're waiting for this to be fixed in Chrome, you can use the attached extension

pcxunlimited, how do I install it? Clicking an attchment saves it to the default download directory.
@michael.monreal: I don't think that's possible, sorry. I have "https" listed in the 
manifest, so I don't think it's a problem on my end.

@aleksri...@gmail.com: I noticed that too. Try dragging the file from where you 
downloaded it into Chrome. It should install then.

@www.gelios.net: Try dragging the file into Chrome.

@michael.monreal: Ah, yes, I should be able to fix that... thanks for pointing out 
that bug! As for where to discuss it...

It would be a good idea to move discussion to this site:

http://kaescripts.blogspot.com/2009/12/autoscroll-in-chrome-linux.html
 Issue 31202  has been merged into this issue.

Comment 53 by Deleted ...@, Jan 30 2010

Yes please, this feature is important for me too/
AutoScroll extension works good, but native web browser feature is better!
Labels: -Area-Misc -Size-Medium Area-UI
Ahh! Finally titlebar buttons are on the right side.

Now I'm just one step away from coming back to using Chrome!! What's the problem with 
the autoscroll!?!
See comments #10 and #26. Until this has been fixed by the Chrome team, you can use 
this extension:

https://chrome.google.com/extensions/detail/occjjkgifpmdgodlplnacmkejpdionan
Thanks. I wasn't really happy with the feel of this extension (that's why I posted
here) but since, I have found an even better extension:

https://chrome.google.com/extensions/detail/ibehnpdcgpabccnlefccelhblhphbbpl

I'm pretty happy, now! Especially as it works with HTTPS and incognito pages. 

Comment 59 by evan@chromium.org, Jul 13 2010

Status: Started
It seems dsargeant disappeared?  I took their patch and ran it by the local WebKit masters and cooked up this trivial patch, implementing the idea where we just blanket disallow it from firing when your mouse is over a text area.  (Aside from it being technically more fiddly to make it conditional on your paste buffer, it also seems kinda unpredictable to me from a user experience sense.)  The patch seems to work, needs cleaning up so that it doesn't affect non-Linux platforms.
middlescroll.patch
966 bytes View Download

Comment 60 by evan@chromium.org, Jul 15 2010

Status: WontFix
Having talked to teammates about this, they feel passionately that this is not a Linux behavior and that there are plenty of confusing precedents for middle click already (pasting into text areas, pasting URLs to navigate, opening links in new tabs) and that this adds one more.

See also  issue 11612 , where we also punted the feature out into an extension.


PS: I am well aware that this is a preference in Firefox; however, we don't do prefs so asking for a pref on this bug will just waste everyone's time.  The patch is in comment 59 if you'd like to modify your own copy.  :)

Comment 61 by dhw@chromium.org, Jul 15 2010

Comment 62 by shoc...@gmail.com, Jul 16 2010

I guess my advice would be: you should talk more to your users instead of your teammates.

Saying "The patch is in comment 59 if you'd like to modify your own copy.  :)" is not helping anyone. The users capable of patching and compiling their own copy are able to locate the patch.

Isn't it time to end the mantra that everyone who uses linux does because it's opensource and they can modify the source? I don't! I use it because I like it. I use it because it's better than Windows. I use it because it's free. So stop making excuses for yourselves by saying that I can modify my copy. You can add parking sensors to your car, can't you?

So please listen to your users.
Exactly so. Listen to your users. "we don't do preferences" is an absurdly arrogant line to take, as it necessarily involves you in the assumption that you know better than anyone else, and that your preferences are better. This can be guaranteed to be false. Add-ons and plugins are not the answer in relation to the fundamentals of usability. A browser that fails to provide this feature is broken.

I have used Linux exclusively for at least 8 years now, and I had never encountered middle-button autoscroll until I found it in Firefox on Linux. So this is not just the rant of a recent refugee from Windows or Mac.

Just do it and stop telling us what is or isn't 'linux behaviour'.

Comment 64 by shoc...@gmail.com, Jul 16 2010

Would you have said "The patch is in comment 59 if you'd like to modify your own copy" if we were talking about chromium for windows? I don't think so. So please, please, end the "free to modify the source" mantra. It is a right I enjoy, but I care about productivity and wasted time also. There are a lot of linux users that don't know how to patch and build nor should they have to know but I think they should enjoy the same level of usability as the users on other platforms. Especially so considering that the development effort has already been spent.
I don't get what the problem is. Every other browser on Linux has this
functionality with no argument saying it's "not linux behavior" - which
doesn't make sense to me. It seems like we were getting towards a solution
here only to have it unceremoniously chopped. It's strange and inconsistent
that the Linux side of the browser operates differently to the other
platforms. I'm sure creating the browser in the first place was a whole lot
harder then introducing a bloody autoscroll function. If it's hard to
implement on the linux platform but apparently not on others then maybe the
browser was designed wrong in the first place? If Google wants to spread
chromium and chrome on Linux powered Google OS machines this must be fixed.

Comment 66 by shoc...@gmail.com, Jul 16 2010

Since you also state "this is not a Linux behavior" but then say "we don't do prefs so asking for a pref on this bug will just waste everyone's time" I also need to point out that this, arguably, is not a Linux way of thinking.

Comment 67 by nam...@gmail.com, Jul 16 2010

do we really need all these e-mails
Right... it's very unfortunate but as the bug was WontFix'd, I'll unstar it now because I cannot stand all the bug spam
Well clearly it is a divisive issue.

Comment 70 by evan@chromium.org, Jul 16 2010

Just some facts, in case anyone else is getting confused:
- Chrome only does this on Windows (not on Mac or ChromeOS)
- As far as I can tell, the code in WebKit is only enabled on Windows, so other Linux WebKit browsers don't do it (e.g. epiphany, midori).
- Firefox has it off by default on Linux, the pref is under the advanced tab
- Opera does it on Win+Lin but not Mac (according to their knowledge base, haven't tried myself)

I'm sorry about the preferences thing.  It's not my decision to make, so please don't yell at me about it.
Hey, guys, on the plus side, there are two extensions that work decently at emulating this on Linux and Mac:

https://chrome.google.com/extensions/detail/occjjkgifpmdgodlplnacmkejpdionan

https://chrome.google.com/extensions/detail/ibehnpdcgpabccnlefccelhblhphbbpl

Comment 72 by dtfi...@gmail.com, Jul 16 2010

I wonder what percentage of future ChromeOS users are likely to have Windows-like expectations of what middle clicking in their browser should do. They'll want to lazily scroll down without having to hold down a mouse button or spin the wheel for long periods, and instead it'll paste the clipboard contents into the address bar and navigate away from the current page, possibly even erasing whatever they had typed into forms on that page.

With this feature still missing, even if all the other problems I've had with Chrome are fixed (such as middle clicks firing left onclick events, or the inability to delete history older than X days), it'll be dead to me on Linux. 
Labels: Restrict-AddIssueComment-Commit
by all means, use the browser that best suits your needs.
Project Member

Comment 74 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-UI Cr-UI

Comment 75 by dhw@chromium.org, Mar 6 2015

Cc: rponnada@chromium.org
 Issue 109611  has been merged into this issue.

Sign in to add a comment