415665 - Turn autoscroll on by default for Linux

Status: NEW

(Firefox :: General, defect)

Description

[Michael Ventnor]

Currently middle-clicking the page in Firefox on Linux does a very stupid thing. It will try to take whatever is stored in your primary clipboard and navigate to it as a URL, even if the pasted text isn't a URL at all.

We should instead replace this silly behaviour with default autoscroll.

a) It won't affect middle-click pasting in textboxes or editors
b) It allows for platform parity, better expectations, and makes Firefox on Linux more sane
c) We were fretted enough about dataloss to disable backspace going back on Linux only (which I still disagree with, but thats another tale...), so this should seem like a no-brainer since just middle-clicking is enough to lose your page.

Comment 1

[Michael Ventnor]

Attachment: Patch

Hmm, this didn't get attached for some reason.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

This will surely be controversial. Don't a lot of linux users use this behavior?

Comment 3

[Michael Ventnor]

I've actually found the opposite. A lot of autoscroll bugs are found by Linux users, and I've seen quite a few requests to turn this on by default.

Primary is used for pasting in textboxes, not this.

Comment 4

[Michael Ventnor]

I'm thinking to compensate for this by changing the behaviour of the URL bar somewhat: if primary is pasted into it while the URL bar does not have focus, then primary will replace it rather than be appended.

Comment 5

[Michael Ventnor]

Also, Epiphany doesn't show that behaviour.

Comment 6

[Michael Ventnor]

Attachment: Patch 2

I'm going to leave the contentLoadURL pref on. The autoscroll pref overrides it, but leaving this pref on ensures that you only need a trip to the preferences dialog rather than about:config to switch the functions.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Need approval on this from mconnor or beltzner.

Comment 8

[Michael Ventnor]

I remember beltzner giving the OK on IRC before I filed this bug, but thats fine.

Most of the arguments are in comment 0. But the main one is that this is much saner behaviour, this change is easy to revert, and a large portion of users do want this since I've found that a lot of autoscroll bugs are found by Linux users and I've had numerous requests to turn this on by default.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

I don't disagree with your arguments, but I just have the feeling that a lot of Linux users that use the middleclick-in-content to browse to primary feature are going to complain. I'm not sure either of us has a really good idea of which group is larger: linux users who expect to be able to autoscroll and/or don't care about middle click, and linux users that want the middle click to load primary feature.

Comment 10

[Michael Ventnor]

This is why I got rid of one of the changes in the first patch. Instead of going to about:config a user needs now to only untick the autoscroll option in the Advanced dialog to bring back the behaviour.

Comment 11

[Elmar Ludwig]

I agree with Gavin here that this is probably going to be at least somewhat controversial, given the discussion about this is the past:

bug 70498 – middle-click in URL bar should go to URI in PRIMARY clipboard
bug 85677 – middle-click in the content area thinks everything is a URL
bug 96972 – I get an alert message with web contents in it!
bug 135884 – Middleclick on browser content area loads clipboard as URL
bug 216899 – middle-clicking functions ContentLoadURL and autoscroll conflict

That said, I still think that turning on autoscroll - and thereby disabling contentLoadURL - by default is the right way to go. The biggest problems of contentLoadURL in my view are:

- It's not very discoverable by new Unix users. We regularly get reports like
  bug 406561 from users why are completely puzzled by this feature.

- It's easy to miss a link you'd like to open in a new tab and hit the blank
  space around it, effectively loading some random page in the current tab.

Note that I'm using the middle-click feature to load URLs a lot myself, and really don't want to lose it completely. But I finally got so annoyed by the consequences of problem #2 mentioned above that I filed bug 291768 (back in 2005) to enable pasting on the site icon in the location bar. Since then, I never felt the need for middle-clicking on the content area to load URLs.

(In reply to comment #4)
> I'm thinking to compensate for this by changing the behaviour of the URL bar
> somewhat: if primary is pasted into it while the URL bar does not have focus,
> then primary will replace it rather than be appended.

The problem with this is that is breaks platform conventions on Unix.

Comment 12

[Jason Brown]

(In reply to comment #11)
> > I'm thinking to compensate for this by changing the behaviour of the URL bar
> > somewhat: if primary is pasted into it while the URL bar does not have focus,
> > then primary will replace it rather than be appended.
> 
> The problem with this is that is breaks platform conventions on Unix.
> 

Maybe so, but given the context here, I'd argue that the convention can safely be broken in this specific instance.

The normal use for the convention is to allow highlighting and pasting text with a minimum of mouse clicks. The append/insert convention makes sense when editing the text of a file, but how often is the average user going to want to append to or insert text in the middle of a URL? In the years I've been a Linux user, I've only wanted to do it a handful of times and in nearly every instance, it's been in the context of hand-typing a URL, so the location bar already had focus.

In my experience as a user, rigidly following the convention results in unnecessary extra steps. Say I have a README file with a URL in it I wish to visit. Under the current system, I switch to Firefox from my text editor, delete any existing text from the location bar, switch back to my text editor, highlight the URL, switch back to Firefox, then middle-click in the location bar. With the proposed system I could simply highlight the URL, switch to Firefox and middle-click.

A default replace action, while absurd in many contexts, seems the most rational for the specific instance of a location bar. The "if ... the URL bar does not have focus" constraint sounds like an excellent compromise between the two functionalities.

Comment 13

[Mark]

I'm heavily in favor of the porposal made by the bug creator!
+1

Can this go in the next FF 3 update? or do we need to wait till FF 3.1?
As everyone that commented seems to like this general.autoScroll set to true.

Comment 14

[Leszek Matok]

(In reply to comment #11)
> - It's easy to miss a link you'd like to open in a new tab and hit the blank
>   space around it, effectively loading some random page in the current tab.
I admit, that happened for me a few times (in thousands of middle-clicks, but still). What's really needed is a simple fix to not load something that's not an URL. If it doesn't contain any dots, display "yellow bar" saying "The middle button tries to load an address that you've copied earlier. The text "d" doesn't look like an URL, though." or something.

Has the advantage of not destroying anything in case of mistake, and also explaining users what they were trying to do (because some of them are new to Unix). You don't have to change the convention for all of us, informing newbies about it should be enough.

Too bad there are only positive votes for a bug :)

Comment 15

[Ray Van Dolson]

Please don't change this.  Middle click should default to paste in a Unix environment as it always have.  Many of us love being able to copy a URL in an xterm or another window, focus follows mouse on firefox and middle click somewhere in the page to head quickly to the new URL.

We don't need to regress to inferior Windows UI ways here. :-)

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 301730 [details] [diff] [review]
Patch 2

This certainly does what it's meant to, and there are no technical problems with the patch.

If we're going to do this we should do it now on trunk, I guess. I'm still not confident that we have enough data to be able to make the right call here, though.

Comment 17

[Leszek Matok]

I understand that my solution would be a little harder to code, but the currently proposed patch changes the whole idea and the Unix way (TM). Can someone please advise a way to vote against this change? :)

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 301730 [details] [diff] [review]
Patch 2

Not sure if this is still relevant, am sure I'm not the right reviewer :)

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:mossop, could you have a look please?
For more information, please visit auto_nag documentation.