Closed Bug 216899 Opened 21 years ago Closed 18 years ago

middle-clicking functions ContentLoadURL and autoscroll conflict

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: loonxtall, Assigned: pkasting)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 1 obsolete file)

Don't include crap from another bug
991 bytes, patch
mconnor
: review+
mconnor
: approval-branch-1.8.1+
Details | Diff | Splinter Review 
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: asa → davidpjames
Summary: middle-clicking page to deactivate autoscroll also activates normal middle-click function → middle-clicking functions ContentLoadURL and autoscroll conflict
Blocks: 212273
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.
.
Assignee: blake → bryner
fixed, branch and trunk
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Flags: blocking1.0?
Flags: blocking1.0? → blocking1.0+
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.
Flags: blocking-aviary1.0RC1+
->P4, which means this is likely cut. Succinctly explain the remaining problem,
contribute a patch, and we may reconsider.
Priority: P3 → P4
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
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
*** Bug 266517 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
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
Flags: blocking-aviary1.1? → blocking-aviary1.1-
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. ***
Assignee: bryner → nobody
Status: REOPENED → NEW
Priority: P4 → --
QA Contact: davidpjames → general
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.
Attachment #224002 - Flags: superreview?(bugs)
Attachment #224002 - Flags: review?(mconnor)
Oops.  Try a version of the patch without a bunch of stuff from another bug in it.  Thanks to ispiked for the catch.
Attachment #224002 - Attachment is obsolete: true
Attachment #224006 - Flags: superreview?(bugs)
Attachment #224006 - Flags: review?(mconnor)
Attachment #224002 - Flags: superreview?(bugs)
Attachment #224002 - Flags: review?(mconnor)
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.
Attachment #224006 - Flags: superreview?(bugs)
Attachment #224006 - Flags: review?(mconnor)
Attachment #224006 - Flags: review+
Attachment #224006 - Flags: approval-branch-1.8.1+
Fixed on trunk and 1.8 branch.
Status: NEW → RESOLVED
Closed: 21 years ago → 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Assignee: nobody → pkasting
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.
Depends on: 340320
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]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: