Closed Bug 366945 Opened 18 years ago Closed 7 years ago

middle-clicking on a page starts a load based on clipboard contents (on unix-like hosts)

Categories

(Firefox :: General, defect)

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 57
Tracking Flags:
Tracking Status
relnote-firefox --- 57+
firefox57 --- fixed

People

(Reporter: michael.s.gilbert, Assigned: kiril)

References

Details

(Keywords: dataloss, privacy, ux-error-prevention, Whiteboard: [parity-chrome] workaround: set middlemouse.contentLoadURL to false in about:config)

Attachments

(1 file, 2 obsolete files)

Disable middlemouse.contentLoadURL by default on UNIX and Android
970 bytes, patch
Gijs
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061205 Iceweasel/2.0.0.1 (Debian-2.0.0.1+dfsg-1)
Build Identifier: Firefox 2.0.0.1

the middle-click behavior in firefox is mind-boggling...even for those who fully understand the unix middle-click.  

first of all, it does makes sense that middle-clicking in a form pastes the clipboard contents into that form.  it also makes sense that middle-clicking on a link opens that link in a new tab.

however, it makes absolutely no sense that middle-clicking in arbitrary space on a page attempts to load a url based on the text in the clipboard.  oftentimes i am trying to middle-click on a link, but miss slightly, and am taken to a 404 not found because the clipboard text is not a url.  i hadn't meant to use the clipboard text to take me anywhere, but inadvertently, i was.

i really think that middle-clicking within a page should not attempt to parse the clipboard text as a url.  instead, that click should just be ignored.  let the user middle-click in the address bar, then press "go" to use clipboard text as a url.  that makes sense.

thank you for your consideration.

mike

Reproducible: Always
You may want to go to about:config and set middlemouse.contentLoadURL to false
it's great that there is a setting to disable this behavior, but i'm more concerned about the impact to the user's psyche.  i mean it seems to make no sense what is going on.  i think that middlemouse.contentLoadURL should be set to false by default (preferably starting with firefox 3 because i that it is bad to change functionality in the stable release).  thanks.

mike
I like the current behavior, though I mostly use Konqueror so I can't tell if it's for some reason a big usability issue in Iceweasel (Firefox); in Konqueror I haven't perceived it as a problem and use the feature frequently.
ok, i tried out the middle-click in konqueror, and i agree, it does work very well.  when the clipboard text is a valid url, konqueror takes the user to that url.  however, if the clipboard text is empty or contains non-url text, then it does not do anything.

if firefox behaved this way, i would be very happy.  my primary issue with the functionality is what happens with non-url text.

so, my request is that firefox not do anything for a middle-click with non-url text on the clipboard, and to load the url if the clipboard text contains a valid url.

mike
I think it'd be *brilliant* for Firefox to check if the pasted text is a valid URL.

My main peeve is that it's a bit hard to middle click accurately on some mice. With a "rigid" scroll wheel, it's easy to end up scrolling up or down before middle clicking. This can move the page and so if you were trying to middle click on a link, you not only *miss* because the page scrolls (not Firefox's fault), but you get an annoying pop-up dialog box to click through (click-through dialog boxes bad!).

Just checking for illegal characters (line breaks, especially) would be awesome.
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2007122004 Minefield/3.0b3pre

This behaviour is still present in latest cvs, and is very annoying. 

middlemouse.contentLoadURL should be left true, but (I agree with john), Firefox should check to see if the clipboard contents are a valid url, as often I have random snippets of code in my clipboard.
My experience (Ubuntu 9.4, FF 3.5.1): 
If you set middlemouse.loadcontentURL to false, you will be able to open sites in a new tab/window with the Middle Mouse Button and be able to paste the market text where you have your mouse pointer.

Just like it was in firefox 2 or 3.

Hope that helps.
i've just tested the latest firefox.  the behavior is much improved (compared to 2.0.0.x), but not as good as other browsers (webkit, konqueror, etc.).  if a non-url is on the clipboard, you will now get a popup saying that is the case.  however, that is really unnessary.  it would be much cleaner if the invalid url were just ignored (like webkit, konqueror, etc.).  thanks.
Whiteboard: [CLOSEME 5-15-2010]
Version: 2.0 Branch → 3.6 Branch
appologies, i must correct myself, there is no improvement.  the text i tested with had a slash in it, but wasn't a valid url, which generated that error.  however, using a simpler text without slashes, firefox still attempts to load that text as url.  so, there has been no progress on this bug.  thanks.
This is back on FF4 B2 and FF4 B3, the middlemouse.contentLoadURL option is enabled by default, disabling it does disable it as expected.
middlemouse.contentLoadURL is great but it should be disabled by default. Pasting on content area is anything but "open new URL here", and middle-clicking on the tab is the "close tab" action.

And all that on-the-fly URL parsing should be disabled too: it's useless (due to many different forms of valid URL including just selected [a-z]+) and brings uncertainty to all actions. If if thinks this time URL is valid it acts one way, if it does not -- it acts another way for same user action.

Mozilla is not M$ to take away the freedom of choice ;)
Older Mozilla Suite bug: Bug 135884
(Don't know is it a dupe or See also.)
As I said in https://bugzilla.mozilla.org/show_bug.cgi?id=135884#c64, this bug is known for a long time now.

People who are annoyed can disable this behavior via middlemouse.contentLoadURL but disabling it by default is the way to go.

As Ben Bucksch said in https://bugzilla.mozilla.org/show_bug.cgi?id=135884#c62, the minority who prefers the current behavior could simply enable it.

For the others (the majority), the current behavior is surprising, confusing, not handy and is even security relevant (noticed by Ben Bucksch) when a user is pasting a password in a field but misses it by a pixel, sending the password through the network.

He wrote a patch but has never been commited.
Can someone review his patch ? (and possibly commit it ?)
>> https://bugzilla.mozilla.org/attachment.cgi?id=504212

Having this long standing bug fixed in Fx4 would be really, really great.
I disagree about disabling it by default. The common use case for this feature is where an URL is contained in a page text without a link (this is frequent e.g. in blog comments). For most cases, you can simply double-click on the URL, followed by a middle click (though it would be a nice feature to be able to open the page in a new tab).

Without this helpful feature, you would have to manually open a new tab and then move your mouse to the URL field and insert the text by middle-click there. Note that you cannot use Ctrl-V to do that. It is also not possible to easily insert the URL into the current tab's address bar, because you would first have to empty it. Double-clicking for selecting all text and pressing del/backspace won't help, as it overwrites the clipboard's content.

The security concerns are IMO indeed valid (I think it even happened to me at one time), but this can easily be fixed by allowing only valid URLs (but allowing for a missing http://), maybe additionally disabling the feature in close proximity to input fields.

As for the claim in comment #17 about only a minority wanting this feature: Can you back this up? Ben Bucksch in your reference certainly doesn't state that. And it obviously _is_ handy for the frequent situation I described above.
(In reply to comment #18)

> And it obviously _is_ handy for the frequent situation I described above.

And it is obviously (I believe) that full content area is not required for recent/frequent pasting URLs. We already have a web site icon area to paste URLs over it. And the new upcoming "Paste&Go" URL bar feature (in context menu). It's enough for opening links and not interferes with the loaded page active content.

I'd suggest to add this paste&go behavior (like web site icon has) to the 'Open new tab' button. Sure it have to open pasted text in a new tab (maybe not only URLs for the "URL bar search").
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: middle-click behavior makes no sense (on unix hosts) → middle-clicking on a page starts a load based on clipboard contents (on unix hosts)
Whiteboard: workaround: set middlemouse.contentLoadURL to false in about:config
Version: 3.6 Branch → Trunk
(In reply to chAlx from comment #19)
Yes, what about adding this function to:
* the former site icon area (load in the current tab),
* the Go button (load in the current tab)
* the New Tab button (load in a new tab)?
(In reply to Aleksej [:Aleksej] from comment #22)
The Go button suggestion would work only for an empty URL field.  I thought of it because of “Paste & Go” which uses the clipboard and doesn’t work with the PRIMARY selection.
> Yes, what about adding this function to:
> * the former site icon area (load in the current tab),

Actually, this works, with some exceptions (bug 759060).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
It is the opposite, marking opposite bugs as duplicate makes it look as if one was in support of another.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
See Also: → 667340
That bug is now about the fact that the behavior for loading URLs from the clipboard with middle click is inconsistent. Some people request it to work one way, other the other way.

It would make a lot more sense for the people in this report to support their request there, where a decision about how this should work should be taken than let it separated and harder to hear. The reason I marked this one as a duplicate and not the other way around is that the other bug already has the attention of some developers.
In that case I'd suggest to make this bug depend on bug 667340 rather than making it a duplicate, or to retarget that other bug by changing its summary to reflect what it's about. I agree with Aleksej that a straight duping isn't applicable.
(oh, I see - you've renamed the summary already...)
Component: General -> Tabbed Browser. [bugday - 20131021]
Depends on: 939447
Summary: middle-clicking on a page starts a load based on clipboard contents (on unix hosts) → middle-clicking on a page starts a load based on clipboard contents (on unix-like hosts)
I suggest middlemouse.contentLoadURL should be false by default.

I guess (without any data) that the majority of Linux/*nix users would find the middlemouse.contentLoadURL=true behaviour surprising and confusing; only a minority will expect it. Anecdotally, I've used Gnome since 2006; I often use middlemouse.paste, but I still find this surprising. I think this will be true of other people who've started using Linux in the last 10 years, and who aren't familiar with conventions of older Unices.

Do we have or can we get data on how many users actually use middlemouse.contentLoadURL versus how many have flipped the pref to false? If more people have flipped the pref than actually use the default, we should flip the default.
(In reply to Greg K Nicholson [:gkn] from comment #34)
> Do we have or can we get data on how many users actually use
> middlemouse.contentLoadURL versus how many have flipped the pref to false?

I believe the Telemetry team has an option to measure it.
While the idea behind middlemouse.contentLoadURL is useful, the reality is that 90% of the time you do not want to use it. I often misclick a link with middle mouse and then I get thrown to another page which is totally unexpected and undesirable behavior. You should be able to click on empty places on a page without something seemingly random happening.

The option should be set to false by default and power users who actually want the functionality can turn it on manually. For the majority of regular people it is simply annoying when you misclick. 

Hopefully it won't take another 9 years for this to be changed. :)
I also think this behavior is just useless and annoying.

When I need to copy and open a link, I will always paste it in address bar. I never click middle button to do that. It is strange: you click button on this page, but it open another page which is totally non-related to this page.

Mis-clicking is very often. I want to open a link in a new page, but it give me another page that I didn't remember what it is.

It is better to remove this function or turn it off by default.
middlemouse.contentLoadURL should default to false.  Otherwise a middle click missing the link, common due to a scroll-wheel nudge, attempts to open the paste buffer.  This may be a valid URL but one that the user doesn't want to open at all costs.  Perhaps it's from a Private Window and mustn't be associated with this non-private window and all its identifying cookies.  Or it's NSFW and is in the paste buffer after being transferred from email to IRC;  an employer may have alarms for attempts to access certain sites, e.g. 4chan.  This option must simply default to false.  Discovery that there is an option can happen after it's all gone horribly wrong!

Those that would miss double-clicking on a URL and then middle-click to open, even though it's restricted to just this tab, can set the option true.  Or type Ctrl-C-L-V Enter.

(xfce4-terminal had a similar bit of brain damage where middle click pasted, except if the pointer was over a URL when it opened that instead.  This trains the user to middle click for two distinct actions.  Where an IRC client is running in the terminal, the text can scroll just before the click, the click misses the URL, and much private stuff is pasted to IRC!  They've fixed this recently to need Ctrl-Button2.)
I just bumped into this issue.

In some web applications, (ex GQueues), middle click on a task leads to focus being given to a task.
However, since I had some URL in the clipboard, instead FF randomly opened some webpage. 

Me like: "What da heck?"

It took me some time to figure out why the heck my middle click was broken, until I learned that it was opening the URL from clipboard instead of doing what I wanted in GQueues.

This behaviour conflicts with webapps and should be disabled by default. Maybe keep it as an option for people to find in 'advance' settings, but definitely should be off by default as it's not intuitive that FF would do that.
I've been using Firefox for years and occasionally (i.e. when I miss a link when middle clicking) run into this issue, and it wasn't until today that I finally spent time to figure out what was going on.

I think this should default to false as it's very surprising and completely not intuitive. Now that I know about it, I'll probably use it, but it cause quite a bit of frustration when my browser was seemingly loading random pages.
Any chance this feature will be disabled per default any time soon?

All people arguing they used this for centuries, it helps avoiding repetitive strain injuries, .. can easily turn it back on. The main problem is that forgetting to turn it back on is simply a nuisance. However, forgetting to turn it back off can lead to rare but security issues (internal URL unintentionally blasted out in non-private window, password paste & instant send to Google, ...) so I don't understand why this is not simply disabled by default. Also see here: https://trac.torproject.org/projects/tor/ticket/10089

To make matters worse, some mouses and also Thinkpad trackpoints make it VERY EASY to accidentally middle click when attempting to scroll. You can argue all the way that this is a hardware design problem if you want, but that doesn't change the fact that lots of people have such hardware.

Also, the Linux desktop is more and more approaching a common design and input language with Windows and Mac OS X which I think is good. Why not finally let go of this after 10 years and keep it for those who still use it as an option, and stop making people unintentionally paste-blast things out into the internet?
This should be awarded the prize to the most obscure *feature* ever. I'm one of those people with super sensitive touchpads (I configured it so myself) and for years I could not understand why firefox would randomly take me to some page I *have* seen before. So it was because I was middle clicking somewhere in the page. So annoying ! 

These days, in 2017, all other applications support opening URLs in the browser. Even my terminal can open URLs in the browser. This renders the current "feature" obsolete, since you never have to copy an URL you have *not* already seen. On the contrary, you copy URLs *from* the browser, so you have already visited them. Abandoning the current page in favour of some URL in the clipboard is against this common flow, since it is 99.99% sure that the link has been visited already.

For the sanity of future users, please make these obscure features disabled by default, as they serve a very limited and specific purpose.
(Cannot believe it is 11 years old!)

As Firefox is a cross platform web browser, it should have same default behavior among Windows, macOS and GNU/Linux.

Also, this might be a security issue.

Sometimes you just copied some sensitive URL, like a secret share link that only valid for once. You copied it and send to your friend by email or IM, but by accident opened it by wrong middle button click. Then your friend can not use this link anymore.

Or you have a very important link that should only be opened in a secure network. But when you are using airport free wifi, you opened it by mistake. Then you probably leak your important token or other valuable data.

Or you have copied a link of porn video, and opened it in front of your classmates with an unexpected middle button click. This what really happened with me. Though it doesn't hurt me, I thought people would be fired if they do the same thing in their presentation. XD
https://discourse.mozilla-community.org/t/middle-click-on-non-link-opens-recently-closed-tab/16635/4

Please set middlemouse.contentLoadURL to 'false' by default (also on Linux!). This 'feature' is totally obscure. I was considering changing to Chrome just because of this: Firefox was randomly loading old pages. Total nuts. 

As noticed in the above post, I wonder if there's telemetry data for such a usage pattern:

> 1. User hits white space with middle-click
> 2. New URL is pasted
> 3. User immediately presses "Back" or "Close" button (because it was all an accident)
4. User goes crazy and switches to Chrome on Linux

FWIW, I love the middle-mouse-pastes-on-Linux feature, but what Firefox does here was totally driving me nuts. I wonder how many more people feel are affected by this?
AWFUL, AWFUL, AWFUL *default*.

It shouldn't need "we have to have telemetry evidence" navel-gazing in this case to figure out that this is *not* a sane default across Firefox's *NIX user base (and yes, I agree there are plenty of cases where telemetry gathering first is justified - this is absolutely not one of them).

Someone with commit rights and a tiny bit of UX insight please kill this *utterly trivial*, *eleven-year-old* bug and change the *default* for this.

*Eye-roll*

/rant
> Someone with commit rights

Besides agreeing with the rant I guess it is up to anyone to fix this ;) 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction

In the end I guess it is a matter of changing the default value. Then finding someone to review it, the above documentation has all about it. So someone on a spare evening might do this, hopefully...
Might be a good idea. If nobody fixes this till February, I'll do it in my vacation time. In the meantime, I will pay 20€ to anyone getting the patch through.
Attached patch disable-contentLoadURL.patch (obsolete) — — Splinter Review 
This patch doesn't enable `middlemouse.contentLoadURL` on `XP_UNIX` by default.
Attachment #8904525 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 8904525 [details] [diff] [review]
disable-contentLoadURL.patch

Review of attachment 8904525 [details] [diff] [review]:
-----------------------------------------------------------------

Please include a bug number in the commit message, configure hg to use more context for its unified diff (you probably want to just run ./mach mercurial-setup ) and please also remove the same line in the android block.
Attachment #8904525 - Flags: review?(gijskruitbosch+bugs)
Attachment #8904533 - Attachment is obsolete: true
@Gijs thanks for the feedback.

I've uploaded a new patch generated with `hg bzexport -e`.

- "Bug 366945 - " is added at the beginning of the commit message (after looking at `hg log` it looks like this is the used convention, but feel free to correct me if I'm wrong).

- Removed the line from the android block (I wasn't sure initially how is this being used under android and honestly was scared to remove it).
Comment on attachment 8904534 [details] [diff] [review]
Disable middlemouse.contentLoadURL by default on UNIX and Android

Review of attachment 8904534 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. I'll push to try shortly to see if there's any tests we need to update expectations in.
Attachment #8904534 - Flags: review+
Attachment #8904525 - Attachment is obsolete: true
Assignee: nobody → kiril
Status: REOPENED → ASSIGNED
Whiteboard: workaround: set middlemouse.contentLoadURL to false in about:config → [parity-chrome] workaround: set middlemouse.contentLoadURL to false in about:config
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8ec11dc8ccc4
Disable middlemouse.contentLoadURL by default on UNIX and Android, r=gijs
https://hg.mozilla.org/mozilla-central/rev/8ec11dc8ccc4
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 7 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Depends on: 1397845
It would be nice if you announce this change in the release notes,
ideally with a link to a page explaining how to turn it on again.
Users of this feature will be rather surprised and think Firefox
is broken otherwise.
Release Note Request (optional, but appreciated)
[Why is this notable]: Changing a longstanding default
[Affects Firefox for Android]: Um... in theory yes, in practice I don't know how many people connect a middle-mouseclick-enabled mouse device to their android tablet/phone/thing. Probably fine to leave it out, tbh.
[Suggested wording]: Middle mouse paste in the content area on Unix systems no longer navigates to URLs by default. Users who depend on the old behaviour can middle click the identity icon instead, or toggle middlemouse.contentLoadURL to true in about:config .
[Links (documentation, blog post, etc)]: None yet. I can write something if necessary.
relnote-firefox: --- → ?
This change seriously disturbs my workflow, but I understand that FF just opening urls can be surprising (and unwanted). Still needing two clicks is much worse usability than just selecting a link somewhere in a terminal and clicking a firefox window to open it.

I also cannot find the identity icon in empty tabs (like a newly opened Firefox).

Would it be possible to make Firefox open the pasted URL in a new tab when middle-clicking the new tab button in the tab bar (the +)?
@Arne I believe you mean 3 clicks for your use-case: 2 to select the link and one middle-click to open it. How about enabling your terminal to open links directly in the default browser ? Most terminals support such a feature (e.g. the popular gnome-terminal on Ubuntu and iTerm2 on Mac), and it would bring it down to exactly 1 click (optionally with a key press).

I hope this helps and we leave this old bug dormant. Cheers !
@Arne and everyone else not liking the new behaviour :)

This is just a change of the *default* behaviour (because many users including myself found it severely disturbing/confusing).

But you can easily re-enable the old behaviour if it is important to you :)

1. Enter "about:config" in the address bar
2. Search for "middlemouse.contentLoadURL" and set it to "true"
(In reply to Arne Babenhauserheide from comment #68)
> Would it be possible to make Firefox open the pasted URL in a new tab when
> middle-clicking the new tab button in the tab bar (the +)?

This is covered by bug 694825, though as others said you can also just flip the preference in about:config.

Going to mark this verified as clearly the change in default has taken effect.
Status: RESOLVED → VERIFIED
@ciprian.tomoiaga: Just replace terminal with text editor, or any other document which includes links: It’s much more efficient to change the one tool which accepts links than to change every tool which might contain them. And clicking in Firefox means that I have control over where (and in which window) the link opens.

@Jens: Does re-enabling the old behavior come with the guarantee that it will keep working (at least as long as it took to change the default)?

@:Gijs: Thank you for the link! I prefer something which gets the best of both worlds over something which only helps me. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1418462 includes a patch which would help me.
(In reply to Arne Babenhauserheide from comment #72)
> @Jens: Does re-enabling the old behavior come with the guarantee that it
> will keep working (at least as long as it took to change the default)?

I am not a mozilla developer, just a Firefox enthusiast and Nightly user (we all should be ;) That having said, it took 11 years to fix this simple "flip-the-defaults" bug. And out of experience and seeing Mozilla's priorities I think you can rest pretty assured that it is not going to "break".
> I am not a mozilla developer, just a Firefox enthusiast and Nightly user (we
> all should be ;) That having said, it took 11 years to fix this simple
> "flip-the-defaults" bug. And out of experience and seeing Mozilla's
> priorities I think you can rest pretty assured that it is not going to
> "break".

And mozilla wonders why no one wants or uses firefox anymore.
(In reply to illumilor.e from comment #74)
> > I am not a mozilla developer, just a Firefox enthusiast and Nightly user (we
> > all should be ;) That having said, it took 11 years to fix this simple
> > "flip-the-defaults" bug. And out of experience and seeing Mozilla's
> > priorities I think you can rest pretty assured that it is not going to
> > "break".
> 
> And mozilla wonders why no one wants or uses firefox anymore.

Well, I do not understand this comment. What I meant is that it is unlikely that mozilla puts effort (time, money, developer ressources) into removing (breaking) this feature. Also no other browser has this feature and is extremely unlikely to implement it (I mean come on, come on, Chromium/Chrome does not even have proper UI/GTK integration). Your comment seems to imply that mozilla should put effort into removing the feature completely.

In the end there's enough reasons why this was changed in this bug's history, also Ubuntu had changed this already before. 

Flipping the defaults can be easily undone as said in Comment 70 and you have the old behaviour again. (Even despite this, in the end, this looks like a whatever-you-do-you-cannot-please-everyone-bug)
(In reply to illumilor.e from comment #74)
> And mozilla wonders why no one wants or uses firefox anymore.

Since I do want and use Firefox, I strongly reject that statement.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: