Closed Bug 278290 Opened 20 years ago Closed 19 years ago

Middle-clicking on an inactive area of the page should do nothing

Categories

(Firefox :: Tabbed Browser, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 274773

People

(Reporter: izv, Assigned: bugs)

Details

This is a usability problem.  Normally, a user would open tabs by
middle-clicking on a link.  If the click is not exactly on the link, in Linux
the result is that whatever is in the copy-and-paste buffer is pasted into the
location bar and loaded, so that one ends up on an (essentially) random page. 
Moreover, if what is in the copy-and-paste buffer is confidential information,
that information may get sent to a search engine site.  This is very annoying. 
Middle-clicking on an inactive area of the page should do nothing.

Another way that the same problem can occur is if the user is using middle-click
to paste into a form field.  Middle-clicking just outside the form field by
accident causes a new page to be loaded, and sometimes the form data may be lost.

Note: not sure which component this belongs in? It should be either location
bar, mouse/keyboard navigation, or tabbed browsing.
Dup of Bug 274773 "Middle-clicking non-hyperlinked areas of a page attempts to 
load from clipboard"

I appreciate that the current behaviour is "by design", but how often is it
used/needed for that purpose? In comparison to the 'suprise' caused to 
people who are having difficulties targeting small links or widgets?
Severity: minor → normal
um, just want to mention this is still not fixed.  can we do something about it?
 pretty please?
See the workaround in bug 274773 comment 3. You just need to change pref.

*** This bug has been marked as a duplicate of 274773 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
(In reply to comment #3)
> See the workaround in bug 274773 comment 3. You just need to change pref.
> 
> *** This bug has been marked as a duplicate of 274773 ***

Gavin, thank you, but a workaround is not a fix.  99% of the people who
experience this problem will not ever find the workaround.  Also, the workaround
does not work in Firefox (and maybe not in Netscape either, I haven't checked).
 Why *not* fix it?

I'm going to reopen this (actually I'd rather reopen 274773 but I can't).
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
This is defently a duplicate of bug 274773, resolving as such please do not reopen.

*** This bug has been marked as a duplicate of 274773 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
This is a feature, it's done by design. Please don't reopen this bug.
Status: RESOLVED → VERIFIED
(In reply to comment #6)
> This is a feature, it's done by design. Please don't reopen this bug.

Jamie, Gavin: can you at least explain *why* this is done by design?  Is one
supposed to be able to middle-click anywhere in a page to load a url from the
clipboard *as a feature*?  If it's done by design but nobody can explain it,
maybe the design is wrong.  It just doesn't make sense, and nobody has even
tried to answer that question in any of the threads about this bug.

Meta-comment: mozilla developers seem painfully unresponsive to feedback from
users.  I would have expected better from open source developers.  I know you're
probably deluged with bug reports etc. but this has been reported quite a few
times, perhaps it's time to conclude it is a real problem?  It will take you
less time to change this than to deal with all the people complaining.
(In reply to comment #7)
> Jamie, Gavin: can you at least explain *why* this is done by design?  Is one
> supposed to be able to middle-click anywhere in a page to load a url from the
> clipboard *as a feature*?

Traditional behaviour on Unix is to allow pasting a URL into the content area
to load a URL from the current X11 selection. You're right, there have been a
few complaints about this behavior, that's why a pref to disable it exists. If
you'd like some extra reading, see bug 274773, bug 226747, bug 96972, bug
144260, and bug 85677.

> Meta-comment: mozilla developers seem painfully unresponsive to feedback from
> users.  I would have expected better from open source developers.

No one is paid to respond to bugzilla comments, most people here volunteer their
time to help triage bugs. Even if there were 10 people paid to respond to
comments full-time, there would still be a disproportionate amount of users vs.
developers. Asking developers to respond to each and every comment is asking
them to take time from fixing bugs. Things can (and will) get better, but user
expectations probably need a bit of adjustement in certain cases as well :).
(In reply to comment #8)

> Traditional behaviour on Unix is to allow pasting a URL into the content area
> to load a URL from the current X11 selection. You're right, there have been a
> few complaints about this behavior, that's why a pref to disable it exists. If
> you'd like some extra reading, see bug 274773, bug 226747, bug 96972, bug
> 144260, and bug 85677.

Starting from your pointers, I tried to find all of them: see the full list in
bug 135884, comment 13.  I'm counting 21 so far, with some very
aggravated-sounding comments from users.  That's more than a few complaints.

A pref is great for the 0.01% of people who will look it up, but not useful to
everyone else (and believe me, *everyone* on unix is affected by this, they just
learn to live with it).  There needs to be a real fix.

> Asking developers to respond to each and every comment is asking
> them to take time from fixing bugs. 

I'm not asking for that.  I had not seen any rationale given for this in *any*
of the cases in which people complained, which led me to believe that such
rationale does not exist.  If a bug is marked WONTFIX, the least a developer can
do is take a minute to explain why.  I'm not asking much, just a sentence or two.

In any case I propose that bug 135884 should be a tracking bug for this issue,
it is currently open, has a few votes and quite a few people subscribed to it. 
Thank you for taking the time to look at this and to reply to me.
You need to log in before you can comment on or make changes to this bug.