Open Bug 70498 Opened 24 years ago Updated 14 years ago

Middle-click in URL bar, not content area, should go to URI in PRIMARY clipboard

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: deven, Unassigned)

References

Details

Clicking the middle mouse button in a browser window performs one of two VERY
different actions.  If you are on a link, it will open the link in a new
window.  Otherwise, it will use the contents of the clipboard as a new URL to go
to.

I admit, I myself make use of both functions, but they're problematic.

With the left mouse button, missing a link has little consequence -- nothing
happens and you aim better and try again.  Using the middle button, missing the
link has the incongruous effect of replacing the page you're viewing with
something entirely different that's probably unrelated.  While I understand why
this happens, and I know I can hit "Back", this is still disruptive.

Also, it may be difficult to explain to users why the same button does totally
different things.  I realize that the current behavior is consistent with the
way NN4 handles the middle mouse button, but perhaps we should rethink this
point of the design.

I think the middle-button behavior to open a new link is critical and shouldn't
be removed, especially since it's very context-sensitive to where exactly the
mouse is pointing when you press the button.

Perhaps a different interface could be used for the "view URL in clipboard"
functionality?  This clearly isn't relevant to where in the page the mouse is
pointing; it's just nice to allow for consistency with text/editor windows where
you can paste text.

One logical solution would be to have the user click the middle mouse button
OVER THE LOCATION BAR to view the URL in the clipboard.  To different this from
a simple text paste could be done based on focus and/or whether the URL has been
edited but not submitted.  If the URL hasn't been edited in the location bar,
and the location bar doesn't have focus, that would be a good time to invoke
this functionality, replacing the contents of the location bar with the
clipboard contents and immediately attempt to load the page.  Also, in cases
where the entire contents of the location bar is selected, and gets replaced by
the contents of the clipboard, that could also trigger an automatic load.

This brings to mind some issues with the editing of the location bar in general,
but those will have to be the subject of a different bug.  (Whenever I get
around to writing it up!)
What you mentionas as "one logical solution" is already implemented as a pref.
Paste this line into prefs.js while mozilla is closed (linux)

user_pref("middlemouse.contentLoadURL", false);

This will force it NOT to paste when you middle-click in content area.
Middle-click on a link will open in new window as usual.
Middle-click over URL field will paste into it.

This is a dup of bug 57317 "Middle button on blank area opens clipboard contents
as URL"

*** This bug has been marked as a duplicate of 57317 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
I disagree that this bug is a duplicate.  Bug 57317 calls this a bug, but I do
realize that it's a deliberate feature.  I marked this bug as "User Interface:
Design Feedback" because that's exactly what this is.  Okay, maybe I'll disable
the function for myself, but I still want the one-click functionality of being
able to load the contents of the clipboard in one step.

Pasting to the location bar does NOT offer this functionality at present, and
that's something I addressed in my design feedback in this bug.

I object to writing this off as a duplicate; that may get it off the radar, but
it also kills any discussion about the design before it even starts.
I would say that such discussion belongs in the npm.ui newsgroup...  But feel
free to reopen this bug if you disagree.
reopening
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Bug 55704, "Add gui for middle mouse button prefs", would partially alleviate
this problem.  I'd be for changing the Linux default from "go to url in 
clipboard" to "pan (or autoscroll) page", though.
Actually, I'd vote for the pan/autoscroll behavior too -- why should Linux and
Windows behave differently?  Yes, you've got some basic differences in the Linux
and Windows platforms underneath, but Mozilla itself is a platform, and there
shouldn't be any differences in the behavior of the Mozilla platform without
good reason.  If you're used to using Mozilla on one system, you shouldn't have
to be surprised by gratuitous differences in Mozilla on a different system...
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ooooo. I hadn't thought of this problem.

Someone tell me (because I don't have a middle mouse button): when you
middle-click on a link, is the link highlighted in the same way as if you 
clicked on it with the primary mouse button? If not, please file a separate bug 
for that.
Link hightlights when clicked with middle mouse on linux.

Middle-mouse pasting was no little motivation when i trashed Windows and
installed Linux instead, but i still have to use Windows on some PC's at work.
If Mozilla is to ignore standard behaviour on the various OS'es: I suggest that
instead of introducing a panning feature on linux, the middle-mouse paste
feature is introduced on Windows instead. I really miss it there.
The dual behavior of the middle mouse button in browsers is a thing you just need to know if you are on Unix. 
(Just like you just need to know the way double-clicking works in various apps on the Mac.)

Removing either the middle-click opening in a new window or the middle-click paste&go over the content area 
is guaranteed to make hordes of experienced Unix users complain.
> Removing either the middle-click opening in a new window or the middle-click
paste&go over the content area is guaranteed to make hordes of experienced Unix
users complain.

Keeping things the way they are right now is guaranteed to make hordes of users,
including even some experienced Unix users, complain too. Damned if you do,
damned if you don't.

Saying "it's the way it's been since the beginning" isn't enough of an excuse.

You lose no funcionality by demanding the middle-click-paste to be done over the
URL bar.
I don't think it would be that onerous to require the paste-mode to be over the
URL bar.  Besides, the current behavior of simply inserting text into the middle
of the current URL is pretty braindamaged anyhow.

How about this?  For a single click, have the middle mouse button paste-and-go
on the URL bar (replacing the original contents!) or open-in-new-window in the
content area.  For a double click, have it replace the contents in the URL bar
without loading (in case you want to edit the URL), and do paste-and-go in the
content area.

I don't think it would be hard for people to adapt to double-clicking instead of
single-clicking in the content area when they want the paste-and-go function,
and it would avoid the overloading problems...
If you want to keep the overload for certain situations, don't forget to enable
it in text fields as well.

And yes, it *is* a big deal to unix users. The middle click is how interfaces
work in *nix. That's like saying it's not a big deal to require people to double
click to bring up a context menu in windows.
Ok, URL bar it is. To summarize:
(1) Middle-clicking in the URL bar should delete whatever is there and replace
    it with the contents of X's PRIMARY clipboard.
(2) Middle-clicking on a link in the content area should open the link in a new
    window/tab.
(3) Middle-clicking elsewhere in the content area should -- until bug 22775 is
    fixed -- do nothing at all, to minimize the pain when that bug is fixed.

--> XP Apps: GUI.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
QA Contact: mpt → paw
Summary: Should the middle mouse button be overloaded? → Middle-click in URL bar, not content area, should go to URI in PRIMARY clipboard
In a vain attempt to pre-empt the flamewar, here's what will happen if what I 
describe in comment 15 is implemented:
(1) People used to Mozilla on X rage and scream about how middle-click-paste in
    the content area doesn't work any more.
(2) After about six months they get used to it, because what they tried first
    (middle-clicking in content area) does nothing at all, and what they tried
    second (middle-clicking in URL bar) is very easy.

And here's what will happen if what I describe in comment 15 is *not* 
implemented:
(1) As more and more people try to use Mozilla on Linux, the number of people
    complaining about how middle-click-paste in the content area is prone to
    dataloss, and how pan-scrolling would be many times more useful, steadily
    increases.
(2) People used to Mozilla on X flame, `But that's how it's worked for ages! If
    you can't avoid the dataloss, and you can't make sure you're right over a
    link whenever you middle-click, you're too dumb to use a computer', etc.
(3) Linux adoption, freedom, liberation, etc suffers. Nobody cares.
(4) Someone happens to compalain about it to their Linux distributor. Suddenly
    everyone cares.
(5) What I describe in comment 15 is implemented after all, five years later
    than it could have been.
(6) People used to Mozilla on X rage and scream, and take about 12 months to get
    used to it, because the change from something --> something else was much
    more violent than the proposed change from something --> nothing -->
    something else.
> (middle-clicking in URL bar) is very easy.

Wrong - the target is small and difficult to hit. My content area,
in contrast, is of infinite size essentially because my window is
flush left.

You still haven't explained the advantage of removing a hidden
pref that is off by default.

Mozilla should ship with middle-button-scrolls by default, but
the hidden pref to move to the admittedly dangerous url-paste
should remain. Why remove it ?
I so not care if mozilla is improved for everybody if that means it's less
usable for me. I want a browser that _I_ like to use, not the average AOL user.
Thanks for listening.
> (1) Middle-clicking in the URL bar should delete whatever is there and replace
>     it with the contents of X's PRIMARY clipboard.

What if it already has focus? Maybe I want to paste just a filename.

I'm OK with it, if you add "unless it already has keyboard focus".
*** Bug 162859 has been marked as a duplicate of this bug. ***
I just discovered this bug/plan through bug 170861.  Sorry if it's a dead horse
but it's obviously gained new relevance since it doesn't work in Phoenix and we
users are missing it, and this bug is being given as justification for not
fixing it there.

Obviously this is flamewar territory, but I want to add a couple things re:
comment #16 above:

1) He's wrong about people moving to Unix/X complaining more and more if this
isn't changed.  What people switching to X complain about (and have for
literally DECADES; this is one of the top 5 FAQs, right up there with "why are
my fonts ugly") is "how do I cut and paste between foo and bar", especially in
regard to URLs.  The stock answer they always get is "this is really easy in X,
just select and middle click to paste".  Everyone I've ever seen this answer
given to has loved it and never looked back.  Middle click to paste a URL into
the browser body is a favorite "wow this is why X is better" things among those
that do think it's better/switch to it.  So the estimation of "need" for this to
be considered "broken" is completely wrong, and indicates a severe unfamiliarity
with the target audience on at least one platform.

2) People used to the current behaviour will never get used to a change, because
all their other X apps will continue to work as they do now.

3) Simple usability (Fitt's Law) dictates that hitting the URL bar is *not*
easy, especially when compared to hitting the full content area.  And the "easy"
verdict certainly doesn't bother to take into account the fact that window focus
on X works very different than it does on other systems, and it's very normal to
want to paste a URL into a browser window that doesn't have focus and has the
URL bar covered up.  As it is now this is easy to deal with, just as you'd deal
with it for any other X app: you middle click paste into the area of the browser
you can see, it works, and you look at the page when it loads, perhaps giving
that window focus, perhaps not, depending on what you need.  This is another
difference between X and other systems that the people that use it (and switch
to it) consider a major feature and often one of the reasons it's worth
switching to/using it instead of the alternatives.

Whoever said this was something that is just different between the different
operating environments was completely right.  This goes way beyond Moz, and
gratuitously breaking it would be equivalent to changing all file dialogues to
use '\' delimited paths just because that's how it is on Windows and all the
environments should be the same (if anyone actually doesn't know, Unix uses '/'
as the path delimiter, and Classic Mac uses ':').  Ok, that analogy is
hyperbole, but hopefully the point is made.

Comment #17 is an acceptable compromise, though I think the default should be
the inverse of what's stated there.  Leave Moz behaving like other X apps by
default, but allow Windows people a pref to change it if they don't like it
(real money says that over time they'll likely change their mind and change it
back).

#19 is a very, very good point as well.
Wow, I can't believe this is actually being considered.  Cut/Paste functionality
is one of the best parts of Xwindows.  It sure beats the hell out of an extra 4
clicks (or two keystrokes).  I use this feature all the time, and is one of the
primary reasons I find windows next to unusable...particularly for browsing when
using IE.

I find comment 16 almost amusing near the end of the second half.  You seem
fairly confident that the windows concept is somehow superior, and thus it will
inevitably be implemented it's just a matter of time.  I don't think that's the
case, and /I/ think if mozilla switched, you'd see at least a patch, if not a
fork, to reimplement the feature.  I can't see the future any better than you,
but I think my scenario is far more probable.

In addition, you assume the worst about those moving to linux.  If they are
truly converting to use X-windows, they'll have to get used to the concept of
select/middle-click paste in /every other application/.  Now, they have a long
list of apps that work one way, and mozilla which does not.  Explain to me how
this is better?
The content area isn't a big text input box, so I don't think we can really
argue that normal X-Window expectations would be to be able to paste into a
random part of the content area and have it load the URL.  It's a handy feature,
but hardly implied by the platform.

That being said, it's nice to have an easy way to do this, but perhaps it
doesn't need to be the middle-click.  How about allowing middle-click in the URL
bar, as discussed before -- and allow Ctrl-V in the content area?  It wouldn't
be too hard to aim the mouse at any spot in the content area and then type
Ctrl-V -- at least it wouldn't require the URL bar to be visible...

Allowing double-middle-click to "paste-and-go" in the content area might be a
reasonable option as well...
Just stumbled across this bug while looking for something else, and realised why
sometimes a random page loads when I'm trying to open a link in another window.
I didn't know it was pasting a url into the address bar when I middle clicked in
the content pane.

I like the middle click paste of X-Windows, but I assumed that you'd have to
middle click where you wanted the text to be pasted. Mozilla's handling of the
middle click to me is not intuitive.
Re: Comment #23
Depending on focus pref settings in your environment (focus follows mouse, or in
this case "focus not following mouse") if you only pointed at a mozilla browser
window, you'd have to bring it into focus (ie, to the front), press control+v,
then middle click the title bar (if your window manager supports that) to put it
back as the last window (then again, what if it wasn't the last window before?).

All of that that can now be done by simply middle-clicking on a
mozilla/netscape/konqueror/etc browser window.
Product: Core → Mozilla Application Suite
I tried to list all of the existing duplicates (all 21 of them) in bug 135884,
comment 13.

The existence of a workaround (hidden pref) is nice, but most people will not
find it.  This should be disabled by default, and if the pref was made visible
that would be nice too.  The current default behavior is not intuitive: yes,
middle-click is paste in X, but there is no app I know about that (for example)
loads a file from a middle-click.  There is a lot of pain from this feature
being triggered unintentionally (see what users have to say in the duplicate
bugs).  I also agree with comment 15 and comment 16. 

I propose the currently open bug 135884 should be the tracking bug for this
issue.   Let's discuss possible solutions there.
I agree that by default, this feature should be disabled, or restricted to the URL bar.
Assignee: bross2 → guifeatures
QA Contact: pawyskoczka
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.