RFC: Firefox general.autoScroll to true

[markg85]

Binary package hint: firefox

Hey,

When you run firefox on windows, get on a big page and press the scroll wheel you get this [1].
When you press it on linux in firefox you get... nothing...
It looked like mozilla intended to make it on (true) by default [2] but could not find a later document of it.

The advantage of having this turned to true by default is to get the expected behavior compared to firefox for windows.

[1] http://www.techspot.com/tweaks/firefox2/firefo54.gif
[2] http://kb.mozillazine.org/Talk:General.autoScroll

[Davidpjames (davidpjames)]

I think what we've got here is a conflict between middlemouse.contentLoadURL and
Autoscroll which results from an inadequately thought-out implementation of
autoscroll.

contentLoadURL works as follows (as far as I can tell): it parses the contents
of the X buffer (similar in concept to a clipboard, but not quite the same
thing). If it finds something that looks like a url, eg http://www.mozdev.org or
bugzilla.mozilla.org or canada.info, it loads that page. If the contents of the
buffer is something other than a URL, eg "Mozilla Firebird", it invokes the
Google "I'm Feeling Lucky" search and takes you to that page.

I have autoscroll turned off, since I use contentLoadURL quite a bit, but I
would also like to get autoscroll to work.

Here's what I think we should do if both general.autoScroll and
middlemouse.contentLoadURL are both set to true:

We parse the X buffer as I explained above; if the contents look like a url we
load it. If not, instead of going off and performing a nearly-useless "I'm
Feeling Lucky" search, we engage autoscroll. A second middle-click (outside the
autoscroll icon) should then disengage autoscroll, unless you highlight a url in
the interim, in which case it ought to load that and leave autoscroll engaged.

This solution should make just about everyone happy. If (as is default) you've
got both set to "true" and you want to engage autoscroll, just ensure that
something other than a url is present in the buffer (eg, highlight "are") and
autoscroll will engage.

Confirming, taking QA and altering summary.

[Wayne Davison (wayned)]

I have a different suggestion for when both flags are set: leave autoscroll
starting first, but allow the user to middle-click even inside the autoscroll
icon to paste the URL. This would allow the user to double-middle-click to go to
the clipboard URL, or to click, see the autoscroll icon, and click again
(without having to move outside the icon). Since a left-click inside the icon
already turns it off, I think we don't need middle-click inside the icon to do
the same thing IFF middlemouse.contentLoadURL is also true.

For the original bug reporter: you will get your desired behavior by simply
turning off middlemouse.contentLoadURL.

[Loonxtall (loonxtall)]

David's solution in comment #1 makes more sense to me. If middle-clicking inside
the icon activates Paste, this same bug report will come in. And AFAIK, there's
no decent way to decide on the double-click delay on Linux.

If disabling middlemouse.contentLoadURL is a serious suggestion, there should be
a pref for it ASAP. Nobody should need about:config.

[Wayne Davison (wayned)]

I think the suggestion in comment #1 will be very confusing. People who know
about how the feature works won't remember what they have at the top of the
clipboard (so you'll always have to check or always have to select something
everytime you want to autoscroll). People who don't know how the feature works
will file bug reports saying that autoscroll only starts up some of the time
(and I doubt if many people would figure out why on their own).

If you want less confusion for newbies, I'd suggest setting only one of the
options by default and adding a pref that lets the user choose if they want
autoscroll, paste, or both. It would thus only be the people who explicitly
select "both" that would have to learn that you can only turn off autoscroll
with a left click (since a middle click after starting autoscroll would paste).

Finally, your comment on the double-click delay only becomes relevant if someone
decides to differentiate a double-middle-click from a middle-click inside the
icon after a delay (in my suggestion both did the same thing: paste).

[Loonxtall (loonxtall)]

Wayne: I understand what you mean now. Sounds good, with the exception that
left-clicks to stop autoscroll conflicts with left-clicks on links. Users
shouldn't have to care where the pointer is (on the document at least;
preferably within the whole window) to stop autoscroll.

I think autoscroll-only should be default. It seems completely unintuitive that
middle-clicking the read-only document text should be "go to URL in X
selection". Can MMB on the address bar's favicon or tab be "replace URL", and
clicking elsewhere in the address bar keep the current paste behavior?

[Davidpjames (davidpjames)]

Chad,

Links are treated differently by all forms of clicking... that's just the way it
is. You can't activate autoscroll (or LoadURL) by middle-clicking on a link
since that will open the link in a new tab.

ContentLoadURL has a long history in the *NIX world - the early versions of
Netscape had this and so does every other *NIX browser in existence; it's simply
a logical extension of the MM paste function. It's no more unintuitive than
autoscroll if you think about it - the first time autoscroll appeared I was
really pissed because this funny icon appeared and the page started bobbing
around apparently at random; at the time I didn't even know what autoscroll was
or that it even existed. The *REAL* issue is how to inform new users of both of
these great features in a non-annoying (and non-conflicting) way.

[Daihardm3-yahoo (daihardm3-yahoo)]

If one of the two options needs to be disabled by default as a workaround, I
strongly believe that contentLoadURL must be left ON. As David eloquently
explained, middle-clicking to paste the content of the clipboard is the default
behaviour of UNIX/Linux. I don't see any reason autoscroll should take
precedence over it.

[Jmd (jmd)]

Finally found this bug. Could someone please inform me as to how to disable this
newfangled scrollthingamabob, so my good old paste function works once again?
"Find" in about:config didn't turn up anything on "autoscroll".

(I highly advise this bug be set to block the next release, and one method
simply be disabled on UNIX for the time being, probably the autoscroll since
UNIX users expect middle click to paste.)

[Wayne Davison (wayned)]

Jeremy: my version of firebird has "general.autoScroll" as the option you wish
to disable. The alternative is to middle-click, move the mouse out of the
circle, and middle-click again to get to the paste functionality you're missing.

[Jmd (jmd)]

Was autoscroll disabled for the 0.7 release, or are we torturing users with
click overloads?

[Ari Pollak (aripollak)]

*** Bug 222816 has been marked as a duplicate of this bug. ***

[Ari Pollak (aripollak)]

*** Bug 218686 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

Yesterday, bryner checked in a change to make autoscroll default to off on
Linux. He checked it into both the trunk and branch.

[Mike Connor (mconnor)]

.

[Mike Connor (mconnor)]

fixed, branch and trunk

[Rparenton (rparenton)]

Mike, this isn't fixed, Brian Ryner just disabled autoscroll by default on
Linux. If you re-enable autoscroll on Linux, the problem persists. Jesse was
simply pointing out what Brian Ryner had checked in, as he could have resolved
this bug himself.

[Davidpjames (davidpjames)]

Yeah, Mike, the problem still exists. It just doesn't exist by default anymore.

Reopening

[Mike Connor (mconnor)]

using that logic, this bug exists on Windows too, since someone could turn
contentLoadURL on there...

[Rparenton (rparenton)]

Mike, is contentLoadURL a function that is dependant on X? For some reason I
remember it having something to do with being X specific. See comment #1.

[Rparenton (rparenton)]

Argh. Forgot to mention that if it is X specific then it is Linux/Unix
specific. Sorry for the bugspam.

[Mike Connor (mconnor)]

*** Bug 232244 has been marked as a duplicate of this bug. ***

[Bugzilla-babylonsounds (bugzilla-babylonsounds)]

*** Bug 231161 has been marked as a duplicate of this bug. ***

[Mike Connor (mconnor)]

*** Bug 233427 has been marked as a duplicate of this bug. ***

[Bugzilla-spray (bugzilla-spray)]

*** Bug 235907 has been marked as a duplicate of this bug. ***

[max (maxozilla)]

If autoscroll is enabled, middle-click pasting should be disabled. To be honest,
middle-click pasting is probably the most ridiculous enabled "feature" X has.
I've seen it drive countless people new to Linux mad. When I enable autoscroll,
I want middle-clicking to _do_ autoscroll, not search for what might be
something important in my clipboard into google.

[Offerk (offerk)]

By default Firefox comes with autoscroll off, and the option to enable it is in
the Advanced preferences window- unlike middlemouse.contentLoadURL, which is not
in the preferences but instead can be found by typing "about:config" in the URL
bar. The solution to this bug is I think therefore simple- change the location
of the middlemouse.contentLoadURL so that it can be controlled from the Advanced
preferences window, and make sure that middlemouse.contentLoadURL and autoscroll
are mutually exclusive selections (radio buttons). This will highlight the
problem(?) to the newbie user (me :-) and allow everyone to choose whichever
behaviour suits them.

You might put an advanced option in the about:config options to enable both
behaviours at the same time as some of the previous comments suggested, but
personally I feel these really are mutually exclusive options which should not
be able to work together.

[Osaier-hotmail (osaier-hotmail)]

(In reply to comment #26)
> By default Firefox comes with autoscroll off

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040617
Firefox/0.9.0+, which (as well as v0.9) came with Autoscrolling ON and Use
Smooth Scrolling OFF.

[Kidgenius2002 (kidgenius2002)]

Well, the suggestion Offer Kaye was a good one. When I set the value of
"middlemouse.contentloadurl" = false, it got rid of the extremely annoying
problem of those missed middle-clicks. Example, if I tried to middle-click a
link, and I happend to not be on the link, the page would load to some *random*
page. I say random, because I haven't quite figured out what page it is loading.
 Some pages are pages I've recently visited, while others are pages I've never
visited. A missed middle-click shouldn't cause the problem I saw. The windows
version treats the middle-click autoscroll properly, whereas the linux version
does not.

[Bugs-bengoodger (bugs-bengoodger)]

->P4, which means this is likely cut. Succinctly explain the remaining problem,
contribute a patch, and we may reconsider.

[Chofmann (chofmann)]

need to minus at this point. if a patch appears in the next couple of weeks
renominate. otherwise this will be a good addition for the next release

[Philringnalda (philringnalda)]

*** Bug 266517 has been marked as a duplicate of this bug. ***

[dogshu (dogshu)]

I just want to add my support for the idea that autoscrolling and
middlemouse.contentloadurl should be mutually exclusive. Middle clicking when
autoscrolling is enabled should always result in autoscrolling, instead of the
crap shoot behaviour Firefox currently has.

The first part of suggestion #5 of bug #258751 is a good idea for how to solve
this.... a radio button in the preferences menu to allow you to change the
behaviour of the middle mouse button. This will also help to make it clear
exactly what is and how to use the "autoscrolling" option. Since the
preferences menu does not say exactly what autoscrolling is, people may enable
it without realizing it will change the behaviour of the middle mouse button.

By the way, I've also filed a bug report related to this on Gentoo Bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=87310

[Mike Connor (mconnor)]

not going to block on this, will take patch if a properly implemented one appears

[Peterph-bugzilla (peterph-bugzilla)]

What about a preference for setting different actions for middle buton with
modifiers. Like middle = X11 paste, Ctrl+middle = autoscroll/panning...
(see bug #305540)

[Elmar-ludwig (elmar-ludwig)]

*** Bug 316854 has been marked as a duplicate of this bug. ***

[Elmar-ludwig (elmar-ludwig)]

*** Bug 263036 has been marked as a duplicate of this bug. ***

[Pkasting (pkasting)]

Created an attachment (id=224002)
Make autoscroll override contentLoadURL

This very simple patch (for Firefox) will make autoscrolling override contentLoadURL if both are enabled. (This is not the default pref configuration on any platform, so this only affects users who have changed their prefs.) There are several reasons why I think doing the override this way rather than the opposite is preferable; ask if you'd like to hear them.

This makes no changes to the preferences window. I don't think there's additional clarity to be had from adding radio buttons to the prefs UI for this.

If this behavior is desirable, then in theory, collapsing the two existing prefs into one (integer?) pref controlling "middle mouse behavior" might better parallel the browser functionality. I don't see a big reason to do that right now, either, especially since it would be a migration obstacle for users who've manually twiddled these prefs.

[Pkasting (pkasting)]

Created an attachment (id=224006)
Don't include crap from another bug

Oops. Try a version of the patch without a bunch of stuff from another bug in it. Thanks to ispiked for the catch.

[Mike Connor (mconnor)]

(From update of attachment 224006)
r+a=me, patches in browser don't need SR if they have review from an owner/peer.

[Brettw-gmail (brettw-gmail)]

Fixed on trunk and 1.8 branch.

[Ria-klaassen (ria-klaassen)]

Does this error belong to this bug:

Error: gPrefService.savePrefFile is not a function
Source File: chrome://browser/content/browser.js
Line: 1056

[Pkasting (pkasting)]

No, I don't think it does. My patch doesn't touch anything like that.

[Onemen-one (onemen-one)]

The fix for bug 216899 make autoscrolling override contentLoadURL if both are enabled.

why autoscrolling need to override contentLoadURL if user click on tab or tabbar ?

[Pkasting (pkasting)]

(In reply to comment #43)
> why autoscrolling need to override contentLoadURL if user click on tab or
> tabbar ?

In my builds at least, middle-clicking a tab closes it. That leaves middle-clicking in the empty part of the tab strip. It's not clear what this is supposed to mean. Having autoScroll basically just override contentLoadURL entirely seems clearer than having it override it "except if you click in the empty part of the tab strip". Plus the patch is simpler.

[Onemen-one (onemen-one)]

(In reply to comment #44)
> Having autoScroll basically just override contentLoadURL
> entirely seems clearer than having it override it "except if you click in the
> empty part of the tab strip".

But as it now users can't use both middlemouse.autoScroll and middlemouse.contentLoadURL. maybe its time to add the contentLoadURL to the main context menu or find another way to activate this option.

i also think that if user want to use middlemouse.contentLoadURL then middlemouse on tab need to use this option instead of then close the tab.

[Pkasting (pkasting)]

(In reply to comment #45)
> But as it now users can't use both middlemouse.autoScroll and
> middlemouse.contentLoadURL.

Yes... because using both makes very little sense, as I said above. That's basically what this entire bug was about.

> maybe its time to add the contentLoadURL to the
> main context menu or find another way to activate this option.

Why? This isn't the sort of behavior any normal user will want to toggle. It's very confusing to people who aren't used to it, which is why we default it off except on Linux, where it's more of a platform convention.

And how does this follow from contentLoadURL being overridden by autoScroll, anyway?

> i also think that if user want to use middlemouse.contentLoadURL then
> middlemouse on tab need to use this option instead of then close the tab.

If you mean in the case where autoScroll is false, then maybe, but I'd bet more of our Linux users want the tab closing behavior than the contentLoadURL behavior when clicking on a tab. You can file a bug on it, but it seems very iffy. If my content area and my URL bar both respond to middle-clicks this way already, what additional utility am I gaining from removing the "close tab" behavior in the tab strip?

If you mean in the case where autoScroll is true, then no.

[Onemen-one (onemen-one)]

what is your suggestion for convenient replacement to call middleMousePaste() if user enable middlemouse.autoScroll

[Pkasting (pkasting)]

(In reply to comment #47)
> what is your suggestion for convenient replacement to call middleMousePaste()
> if user enable middlemouse.autoScroll

I don't understand the question. If you need to discuss/debate functionality in general, please bring this topic up on an appropriate newsgroup; bugzilla isn't really the place.

[Bugzilla-snugmail (bugzilla-snugmail)]

this "bug" has been a great feature for me; it's how I managed to use both autoscroll and middlemouse.contentloadURL (greatly underrated feature) at the same time

[Blue-cube (blue-cube)]

(In reply to comment #49)
> this "bug" has been a great feature for me; it's how I managed to use both
> autoscroll and middlemouse.contentloadURL (greatly underrated feature) at the
> same time
>

i agree with that - would it be possible to have a pref for closing / loading x sel when a tab is clicked?

[Adam Guthrie (ispiked)]

*** Bug 310019 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

*** Bug 302349 has been marked as a duplicate of this bug. ***

[Elmar-ludwig (elmar-ludwig)]

(In reply to comment #50)
> i agree with that - would it be possible to have a pref for closing / loading
> x sel when a tab is clicked?

I guess bug 291768 is what you are looking for (without the need for a pref).

Verified FIXED on Minefield/3.0a3pre ID:2007022304 [cairo]

[markg85 (markg85)]

Binary package hint: firefox

Hey,

When you run firefox on windows, get on a big page and press the scroll wheel you get this [1].
When you press it on linux in firefox you get... nothing...
It looked like mozilla intended to make it on (true) by default [2] but could not find a later document of it.

The advantage of having this turned to true by default is to get the expected behavior compared to firefox for windows.

[1] http://www.techspot.com/tweaks/firefox2/firefo54.gif
[2] http://kb.mozillazine.org/Talk:General.autoScroll

[markg85 (markg85)]

Sorry, this should be filled against firefox 3.0.*
But the same is true for firefox 2.

[max (maxozilla)]

I agree with this, general.autoscroll should be set to true by default.

[John Vivirito (gnomefreak)]

Marked incomplete and wishllist. This will not be added to firefox 2. have you also filed this upstream? to see if they will set it?

[markg85 (markg85)]

@comment #3
No need to fill it because the link i gave [1] has 3 links on it to the issue [2] [3] [4]
And there is a whole lot more if you search for it.
Also in unix it "seems" to be the default action to paste text when you press the scrollwheel.
I don't know who or how that was ever made up but i don't think that "standard" should be followed in firefox.

And one of ubuntu's goals is to have a seamless transition between Windows and Linux right? then this autoscroll should be set to true since that's the default for windows. (described here [5])

The idea is simple. A windows user that starts using Linux (ubuntu distribution) is gonna expect to have autoscroll when they press the mousewheel.

[1] http://kb.mozillazine.org/Talk:General.autoScroll
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=216899
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=310380
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=303203
[5] http://kb.mozillazine.org/About:config_entries#General..2A

[John Vivirito (gnomefreak)]

Upstream stated in all cases that this was fixed in 3.0 and i am unable to reproduce in 3.0.7 or higher.
If this is still a problem please file this bug upstream at: https://bugzilla.mozilla.org and add the link to this bug report so we can track upstream progress. Let them know with a new bug that it is still not fixed. reopen this bug if you file an upstream report.