User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030817 Mozilla Firebird/0.6.1+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030817 Mozilla Firebird/0.6.1+ Middle-clicking a page while autoscrolling stops the autoscroll as well as activating the normal middle-click function. Most of the time, that function is Paste, and Firebird goes away to another page. Sometimes, it ignores Esc and keeps the Stop button greyed during this transition. Middle-clicking to start the autoscroll does not display the same behavior. Bug present in latest nightly (Build 20030820) as well. Reproducible: Always Steps to Reproduce: 1. Put something on the clipboard, for instance "are". 2. Start autoscroll. 3. Middle-click somewhere outside of the autoscroll icon. Actual Results: Firebird stops autoscrolling AND starts a Google "I'm Feeling Lucky" search for "are". Expected Results: Simply stopped autoscrolling.

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.

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.

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.

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).

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?

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.

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.

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.)

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.

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

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

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

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

.

fixed, branch and trunk

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.

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

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

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.

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

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

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

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

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

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.

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.

(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.

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.

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

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

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

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 **** 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

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

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

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

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

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.

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

Comment on attachment 224006 [details] [diff] [review] Don't include crap from another bug r+a=me, patches in browser don't need SR if they have review from an owner/peer.

Fixed on trunk and 1.8 branch.

Does this error belong to this bug: Error: gPrefService.savePrefFile is not a function Source File: chrome://browser/content/browser.js Line: 1056

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

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 ?

(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.

(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.

(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.

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

(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.

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

(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?

(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]