Open Bug 96972 Opened 23 years ago Updated 3 years ago

Need UI for middlemouse.contentLoadURL

Categories

(SeaMonkey :: Preferences, defect)

Product:
SeaMonkey
Component:
Preferences
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

People

(Reporter: pabloa, Unassigned, Mentored)

References

(
URL
)

Details

(Keywords: good-first-bug, Whiteboard: [2012 Fall Equinox][lang=js/xul])

Attachments

(2 files)

preliminary patch - adds checkbox
2.63 KB, patch
Details | Diff | Splinter Review
help update to complement the patch
2.11 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010803
BuildID:    Mozilla 0.9.3

I've been navigating for an hour with a lot of windows.

Then, I opened the URL http://www.lanacion.com.ar/01/08/25/titulos.asp

I clicked with the medium mouse button (I wanted to open an article in a new
window) in a part without links and I get a javascript alert() with a part of
html text inside it!

Now I have 7 open windows. In a window I've http://lwn.net/daily/ and when I
click on the back of the page with the medium mouse button (click in a part
without text or links), Mozilla open a new window with this URL:
http://www.lanacion.com.ar/01/08/25/titulos.asp



Reproducible: Always
Steps to Reproduce:
1.open a lot of windows
2.open the URL I send 
3.click inside in a part of the page without links or text with the medium mouse
button (I've a 3 mouse button Genius Netscroll+)

Actual Results:  Happened stranges things...: alert( "text of old closed windows
web page in it") 
Or open a new windows witt the URL I send you

Expected Results:  I don't now... a hot menu or nothing...

My mouse is a Genius NetScroll+.
I'm use to navigate with a lot of windows open (10 or more) at the same time. I
have not been using Mozilla Messenger Yet.

My Linux is a Red Hat 7.1 with xFree 4.03. My machine is a Athlon 1Ghz with
256mb of RAM, 11Gb of Free Space. I'm using Gnome 

Now I hav open this web windows:
http://lwn.net/daily/ , 
http://www.lanacion.com.ar/ , 
http://www.jpl.nasa.gov/srtm/ 
http://www.jpl.nasa.gov/srtm/argentina.html
http://www.lanacion.com.ar/01/08/25/de_330240.asp
http://www.lanacion.com.ar/01/08/25/do_330121.asp
http://www.mozilla.org/quality/help/bugzilla-helper.html
http://www.lanacion.com.ar/01/08/25/titulos.asp
WFM 2001082203 on Win2k. Reporter: You may wish to try a more recent build:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/
Confirming -- i've seen this on recent linux cvs builds.  I sort of understand
what's going wrong.

In the past, if you had copied a URL to the X clipboard, you could middle-click
to 'paste' that into the content area; this would load that URL.  Some sort of
logic prevented attempts to load random bogus things in this fashion (presumably
some sanity checking on the copied 'url'.  In this case, it would trigger a
search for the pasted content.).  Whatever this logic was, it's broken now, so
if I select "proposed patch, testcase" up above and try to paste it, "Resolving
proposed patch, testcase" appears in the status bar, and an alert eventually
comes up to tell me that "proposed patch, testcase" could not be found.

Hmm... trying this further, sometimes it still works correctly -- and the
"proposed patch, testcase" example is a bad one, since that text works properly.

Selecting "(proposed patch, testcase, etc.)", however, will trigger the problem.
 In fact, it triggers it as far back as 0.9.3.  Am I imagining that this happens
more frequently in recent builds?

Apologies for this very confused comment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Your comment makes sense.

See: http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDefaultURIFixup.cpp#276

To test: type "(abc)" in the urlbar and press enter, then type "(abc.)" in the
urlbar and press enter.

I guess the problem here (more bugs have been filed recently because of this
feature) is that "middle-mouse click in content loads 'url' in select clipboard"
is unexpected behaviour to a significant amount people. The feature was put in
for compatibility with NS 4.X on Unix platforms, where people seemed to like it
and have requested support for it in Mozilla (I myself for example use it a lot). 

However, the logic of middle-mouse click in content isn't very discoverable:
from the resulting action, where either a page is loaded if you happen to have a
valid URL in your select buffer, or the Netscape search page pops up with the
text in your select buffer, or you get an alert with the text in your select
buffer, it's non-trivial to establish a pattern and trace that back to what you
did (or thought you did, in this case you thought you middle-clicked on a link,
while in reality you middle-clicked on the page).

Suggestions for solutions? (Other than the obvious "turn it off by default, let
those geeks turn it back on in their prefs.js" ;-))
If something has changed recently so that bad urls are no longer detected, and
that's why this is suddenly bothering people, shouldn't we try fixing the
offending regression rather than turning off useful behavior?  Sure, geeks like
myself can easily turn it back on, but let's find out what regressed before
deciding to do that and dealing with the resulting flood of "Why doesn't this
feature work any more?" If we do decide to turn it off by default for some
reason, let's please make it a visible pref so people who have been using it for
years can discover how to turn it back on.  In fact, even if we leave it on, it
wouldn't hurt to make it visible since that also makes it much more
discoverable, and then Win and Mac people who might like the feature can also
find out about it.
All the "faulty url" detection code that gets hit in this case can be found in
nsDefaultURIFixup. There hasn't been any in the middle mouse click code I think.
As far as I know, nothing has regressed, it's just that more people are running
into this "problem" where they miss-click and end up loading a url (or some
random text) instead of opening a new window for the link they were trying to
hit.
adding relnote keyword, cc-ing jatin, marking p5 and future
Keywords: relnote
Priority: -- → P5
Target Milestone: --- → Future
Sarah can you review the bug description I put in the release notes tracking bug
(Bug 96484)?
jatin: i've added a clarification to the relnote bug. thx!
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---
->future
Target Milestone: --- → Future
I used to get these alerts with contents of the X clipboard, but I cannot
trigger this anymore in 2002021208.  Did this get fixed elsewhere?  I bet this
is a dupe.
Was just scanning the release notes and saw this bug and am curious as to why
the workaround of user_pref("middlemouse.contentLoadURL", false); isn't
mentioned anywhere.  If you don't understand why you are getting the alerts, you
aren't using the feature anyway...
Please fix this, as this is a big advocacy issue. I do almost all my browsing in
'tabbed' mode, and it is a feature that impresses the hell out of IE users.
Every now and then, I miss a link and an alert pops up, very embarrasing. 

What's worse, this handicaps Optimoz (mouse gestures), since the middle mouse
button is the natural choice for a gestures modifyer.

I agree that user_pref("middlemouse.contentLoadURL", false); should be the
default. Users who *really* want it can turn it back on this way...
I think this should ideally be off by default for new profiles, but perhaps on for
profiles that have been migrated from previous versions that had this on by
default.  Users who know about and want this behavior are IMO likely to be able
to turn on the pref, as long as we add UI for it.  Typical users who are
encountering it by accident are extremely unlikely to know what is going on, nor
how to turn it off.

Let's get this on the radar for the next release. ->prefs/1.2
Assignee: trudelle → ben
Component: XP Apps → Preferences
Target Milestone: Future → mozilla1.2alpha
> Whatever this logic was, it's broken now, so if I select

No, it's not. Perhaps you turned off your keyword server? WFM with 1.0 branch.

> I think this should ideally be off by default for new profiles

For UNIX, you're going to confuse just as many users if you get rid of this.
It's expected X behavior. Every app does it. I don't understand how you can be
confused by this. It's one of Moz's greatest features.
Jeremy M. Dolan wrote:
> No, it's not. Perhaps you turned off your keyword server? WFM with 1.0 branch.

What kind of "keyword server" is there that can be turned on or off?

> For UNIX, you're going to confuse just as many users if you get rid of this.
> It's expected X behavior. Every app does it.

No, it is not "expected X behavior" (and I am a long time Unix user). This
is not about the URL bar. The content area is *not editable* (note that the
"Paste" menu item is disabled when focus is in the content area), and I
would not expect to be able to paste there.

> I don't understand how you can be confused by this. It's one of Moz's
> greatest features.

Well, I am. It's just that everytime I accidentially "miss" a link when
trying to open it in a new window (as explained above), I get silly alerts
with "www.<whatever>.com not found", which I find very annoying.
This also occurs when using the middle mouse button to close a tab. Truely this
is the most irritating thing I have ever seen in a browser. I have cast my
vote--if it needs to be disabled, so be it! Otherwise, Mozilla is wonderful.
Rather than 'pasting' the URL into the content area, isn't it sufficient to just
support pasting it into the URL bar?
No, because middle-clicking in the URL bar should, under X, paste the clipboard
contents at the click-point, which usually gives you something like:

http://www.befhttp://www.pasted.com/ore.com/old.html

And let's not forget that our handling of newlines-and-such in the URL bar has
traditionally been _like_ a joke, except that people always end up crying at the
end instead of laughing.  Shakespeare would call it a tragedy, I guess, but only
because he wasn't motivated by actual use of the product to coin a stronger phrase.

This is a 4xp/Unix feature, used by Unix browser types since 1996, if not
earlier, and many of us use it very regularly, as a foil to the axis of evil
that is Unix-clipboard-handling + our-URL-bar.

If you don't like it, though, you can always add this line to your user.js:

user_pref("middlemouse.contentLoadURL", false);

Viola, as they used to say in alt.hackers!  (If that doesn't work, please file
another, tightly-focused bug on that specific pref defect.)
Please do not remove this feature. It is one of the all-time top timesaving
features of mozilla/netscape. It would be a tragedy to lose it.
I don't want to lose the feature either, just reduce the incidence of this
failure case. I've been using this since stumbling onto it in '97' and trying to
file a similar bug on it.  My impression is that very few people know about it,
yet an increasing number of others trip over it without ever realizing what is
going on.  There is near-zero chance they will add this pref. Unix users extend
way beyond alt.hackers these days; unless people like Blizzard's Mom used to
lurk there. ;-)  I propose setting the pref to false by default, in new
profiles, to avoid driving these people away from the browser.  Those who know
about it are surely savvy enough to easily enable it if they want it.

I didn't have a Linux box handy to check before spewing comment #18, but Mike is
of course quite right that on Linux (only) clicks in the URL field specify an
exact character position, rather than select the entire field.  I'm not sure
this is optimal from a usability standpoint, but it does seem to be the
'standard' platform behavior.  
If the pref is turned off by default, could it at least be made into a *visible*
pref (somewhere in Advanced, if need be)? Once people stumble onto it, they
rarely want to go back.
That sounds right to me.
It would be great to have the pref exposed in the prefs dialog.  Exposing it
would also make it discoverable for people who don't know about it.  I didn't
find it until Netscape 3.0, and when I did I wished I'd found out about it much
earlier.

Where would it live?  Advanced/Mouse Wheel?  (Should that then be renamed to
Advanced/Mouse, since not all middle buttons are also wheels?)
Here is a little something that should take of the problem.  It adds a checkbox
under Advanced/Mouse, which was formerly known as Advanced/Mouse Wheel but is
renamed by this patch.	The wording could probably be improved a little bit. 
The cleanest solution would probably also rename all those files from
mousewheel to mouse, but this is beyond the scope of my patch.

Please let me know what you think of it.
Comment on attachment 90413 [details] [diff] [review]
preliminary patch - adds checkbox

Looks good to me, r=akkana.
Attachment #90413 - Flags: review+
Akkana, thanks for the quick r= on the patch.  Here is a small help update that
complements my patch.  They should be checked in together.  Now for that
elusive sr= ...
In some cases there seems to be a bit of misunderstanding, though perhaps it is 
mine. Being able to middle-click on a URL is great--it's middle clicking on 
anything else, which causes the current clipboard (which is almost never a URL 
for me) to be loaded as a URL and an error to pop up that is irritating. This 
cannot possible be considered a good thing as far as I can tell. Without at 
least URL parsing, how could this possibly be anything but extremely irritating?
When I middle-click on a tab to close it without first going to that tab, does 
anyone really expect the contents of their last email they highlighted to be 
loaded as a URL while Mozilla closes the tab? I'm all for the middle mouse 
button opening URLs and all, but the middle click (on other than a URL) 
behavior is obnoxious in the extreme. This does not happen using Mozilla for 
Windows.
Comment on attachment 90860 [details] [diff] [review]
help update to complement the patch

r=oeschger
Attachment #90860 - Flags: review+
The patch wording looks good to me.
Hmm, do I have to add an access key for this?

Ben, could you give sr= and decide whether the files should be renamed from
mousewheel to mouse?
This patch is not getting sr. Details why coming this evening, as I need to go
out now. 
Ben: curious now :-)
Ben: ping!
1) This preferences panel is going away.
2) This is a unix only preference (or at least one that we on Windows and Mac
have no interest in), why is there no platform work done to ensure it doesn't
show on affected platforms. 
3) If middle button paste to load URL is causing problems such as this, why is
it even on by default. It doesn't strike me as a particularly useful binding,
given what middle-mouse button would otherwise do (load links in a new tab). 
Also, 

the text in the checkbox is terrible. before you start on how you provided help
text - online help a usable application does not make. 

As I mentioned in my previous comment, there is another preference that fights
for control of the middle mouse button (tab link load in new window). What if
both are set? Should one unset the other? How is this relationship clear when
the two prefs are miles apart in the preferences dialog? How many people would
use this over a (better) defaults change? Why add this clutter when we're
supposed to be simplifying. 
OK, that's a lot, let's see..

> 1) This preferences panel is going away.

Are you serious?  Mouse wheel is going away?

> 2) This is a unix only preference (or at least one that we on Windows and Mac
> have no interest in), why is there no platform work done to ensure it doesn't
> show on affected platforms.

If you mean that it is only on by default on Unix, then yes, it does work on
other platforms, though. I actually like this feature and comment #4 and comment
#24 at least suggest that making this discoverable for other platforms would be
nice.

> 3) If middle button paste to load URL is causing problems such as this, why is
> it even on by default. It doesn't strike me as a particularly useful binding,
> given what middle-mouse button would otherwise do (load links in a new tab). 

Judging by the comments in this bug there are quite a few people that find this
binding very useful.  Middle click only loads links in a new window/tab when
pressed over a link.  If we turn this off by default we should make it discoverable.

> the text in the checkbox is terrible. before you start on how you provided
> help text - online help a usable application does not make. 

OK, so you do not like

  Middle button click on page loads URL from clipboard

what about

  Middle-click on the body of a page loads URL from the clipboard.

> What if both are set? Should one unset the other?

Both prefs can work together.  This is obviously an advanced pref, but it is
dear to some people.
Are those people toggling this on and off so frequently that it warrants UI? I'm
copying some windows and mac people for their opinions concerning their platforms.
Status: NEW → ASSIGNED
Ben Goodger wrote:
> Are those people toggling this on and off so frequently that it warrants UI?

Note: I'm not one of "those poeple", but I'd like to answer anyway...

Some people find it purely annoying while others can't live without it (as you
can see from the comments on this bug). And that's what a preference option is
for. Toggling something on/off frequently is not the typical reason for having
UI for a preference. Do you frequently toggle link underlining on and off?

As an added bonus, making the (currently hidden) pref visible would help those
people who would use this feature if they knew that is was available (even on
other platforms, where it is off by default).

The alternative would be IMHO to only allow pasting of _valid URLs_ (no fixup),
instead of any random text that is then interpreted as a URL.
For Mac: I had no idea this feature existed. Middle-mouse paste is such an alien
behaviour that almost all Mac users won't know that Mozilla has this feature. I
see no problems with it being off for Mac.
> For Mac: I had no idea this feature existed. Middle-mouse paste is such an alien
> behaviour that almost all Mac users won't know that Mozilla has this feature. I
> see no problems with it being off for Mac.

That's not the point.  It _is_ off by default for the Mac and will remain so.
The real question is: Would it be OK to have a pref for this on the Mac?
Elmar, I've been working on this project since 1999. I know what preferences are
for. They're not for this. 

The handful of users that want this can go edit your prefs.js file. If you feel
moved, go make an xpi add-on that adds this checkbox in somewhere. 

We have what must be the world's fattest preferences dialog. This checkbox is
not part of its low-calorie plan. 
Ben Goodger wrote:
> I know what preferences are for. They're not for this. 

Fine. But then I would suggest that either:

- this "feature" should be off by default on all platforms, or

- the pasting should only be allowed when the clipboard/selection contains
  a valid URL (note that text like "cnn.com", "mozilla.org" or "Logo.eps"
  is not a valid URL, since it does not contain a protocol specification),
  or maybe define more complicated rules what may be pasted and what not

> The handful of users that want this can go edit your prefs.js file. If you
> feel moved, go make an xpi add-on that adds this checkbox in somewhere. 

I won't, because I really don't like this feature (see my comment #16), and
I already have this turned off. But this feature is _on_ by default on Unix,
so unless the default is changed, you should say:

"All users on Unix _except_ the handful that want this can go edit your
prefs.js file." Do you really mean that?
Turning this off by default for Unix doesn't seem like a reasonable solution. 
(Turning it on by default for other platforms seems just as silly.)  Comments in
this bug suggest that there are a number of people on Unix who use it and a
number who don't (as for most any feature).  Unix is the only platform with a
standard UI expectation for a middle-mouse click (paste), and the idea that
pasting a URL into the content area loads that URL is well-established from
Navigator 4.x and probably well earlier.

It happens that Navigator 4.x does URI-fixup on the pasted URL (and even uses
search when in doubt), but I suspect this part may not be crucial.  I say that,
though, only since my use of the feature (and I use it tens or hundreds of times
per day, since it's by far the easiest way for me to take a URL from another
program, in particular, a terminal in which I'm reading my email, and open it in
a specific, already-open, browser window or tab) wouldn't be broken by removing
the fixup.
For a brief moment I contemplated making the code smarter so that when we detect
the situation where the "url" can't be loaded as such, we submit it to a search
engine, but then users will complain that we're "randomly" sending web content
to search.netscape.com ;-)
This is *not* paste, therefore not standard UI on Linux or anywhere else.  It is
a Nav4X-specific legacy feature that a few people use a lot and most others trip
over and don't know how to deal with. It is just bad UI to have a different
behavior depending on whether the gesture is made over a link or one pixel off.
Luckily, all the people that want this behavior are quite capable of finding the
UI to enable it, though I'd still rather leave it enabled in existing Linux
profiles.  I don't think there should be UI for this pref on any other platform.
FWIW, although it may have originated with some version of Navigator, it also
works in Opera for Linux, Konqueror, and I *think* Galeon (although I don't have
a working installation of Galeon to test).
If the default behavior for this is changed (and I think it shouldn't be), at
the very least, bug #88093, *must* be fixed. Otherwise, there's no good way to
open a URL from selected text at all.

Note also that the decision on bug #135331 has made "a different
behavior depending on whether the gesture is made over a link or one pixel off"
a standard Mozilla behavior. Perhaps I'm a hypocrite for liking this feature and
hating those super-picky context menus -- I guess one is less likely to hit or
miss a link by accident with the middle button than one is to accidentally hit
an image with  right click. Either way,
super-sensitive-to-context-click-behavior is now the Mozilla norm.
> It is just bad UI to have a different behavior depending on whether the gesture
> is made over a link or one pixel off.

Is it bad UI to follow a link when you click it and not follow it when you click
one pixel off?
The consequences are very different.  With a normal link click, you get feedback
on the mouseover and click, and if you miss you typically just don't get any
feedback, it is a dead click.  In this case, users frequently get an extremely
confusing error alert, and have no idea what happened or how to prevent it. 
Seeing the partial contents of your clipboard in the alert may result in
security concerns as well.  
Just a random thought:

Since we cannot use middle click in the URL bar on Unix (see comment #19),
would it be possible to capture a middle click on the bookmark icon left of
the URL and "paste" in response to that? (Hmm, I'd swear that some time ago
left clicking on this opened the File Bookmark dialog, but that doesn't work
anymore...)

In this way we wouldn't loose this functionality, the click would be close
to where the pasting actually occurs and it could perhaps safely be enabled
on all platforms (if that is desirable, which it may be not).
This discussion is starting to get circular and offtopic...

I will try to summarize the situation and the different proposed solutions and
workarounds to give this a little more direction.  Please bear with me for a minute:

* On the Unix platform we have a - somewhat obscure - feature that integrates
  very well with the X clipboard and allows easy pasting of URLs into Mozilla
  via a single middle button click.

* The feature is currently partially broken, sometime last year somebody did
  something to Mozilla that leads to Mozilla blindly trying to load anything a
  middle click might throw at it without checking if it might be a URL or not.

* If such a rogue load of clipboard contents takes place, Mozilla displays an
  error message saying it failed to load "whatever the contents of the clipboard
  were at that particular moment".  This message is very confusing to those
  people that are not aware of the middle click clipboard loading.  Security
  concerns have been raised over displaying the contents of the clipboard.

There are several different attempts at solving the problem:

- Mozilla should sanity-check the contents of the clipboard and only load URLs,
  not random garbage.

Nobody seems to be against this, but nobody has stepped up to provide a patch
for now so that different workarounds have been proposed:

a) The pref should be off by default on all platforms.
b) The feature should be dropped from Mozilla entirely.

The problem is that this feature is very dear and useful to those people that
actually know and *use* it, Unix users being a somewhat obscure crowd in itself.
It has been argued that these people should be able to turn it back on by hand
and counterargued that we should not break current and expected bahavior.  This
lead to the following alternative workaround:

c) The pref should be added to the preferences panel to make it visible and then 
   possibly be turned off by default.

I wrote a patch for this that is currently being rejected on the grounds that it
adds complexity to the already bloated preferences panel.

d) The pref should be added to the preferences panel for Unix only to make it
   visible and then possibly be turned off by default.

I hope this has been objective up to this point, sorry for any redundancy.

Now let me counter a few of the last arguments that were brought into this
discussion:

- The prefs panel is bloated.

Maybe.  Nevertheless the prefs panels of other browsers (Opera, NN4, Galeon and
even IE6) are no less complex and other applications like M$ Word offer equally
many options.  All of them may be treading down the wrong path but Mozilla is
*not* a browser for the masses.  Let's face it, it is a product for advanced users.

- Middle mouse button also does something different over links / middle mouse
  button is already featured in the prefs panel under tabbed browsing.

Right clicking does many different things depending on whether you are over an
image or not, context sensitive clicks were approved there...

The discussion is currently more concerned with the merits of the feature than
the fixing of the original problem.  We really should not drop this just because
somebody broke it sometime ago.  All the *users* of this feature want it to stay
in after all...

Maybe we should fork this off into different bugs and leave this here for a
solution of the original problem.  Ripping this feature out can be discussed
elsewhere as can the pros and cons of the different workarounds.  Let's not
forget that most of this would probably become pointless if there was a real
solution to the original problem.

Sorry for this long comment, I hope this adds some direction to the discussion.
Diego Biurrun:

> * The feature is currently partially broken, sometime last year somebody did
>   something to Mozilla that leads to Mozilla blindly trying to load anything a
>   middle click might throw at it without checking if it might be a URL or not.

If I recall correctly, Mozilla has always "blindly" tried to load anything a
middle click might throw at it, no checking ever happened before loadURI was
called. If anything changed it's been the way loadURI deals with errors.

As for the URL sanity checking, there are many things we accept in the location
box that may not pass such a sanity check. Sometimes all that can be done is to
try and load it and see whether it is accepted. Of course, that's not really a
solution here. Take for example "let's filter on anything with a space in it".
That would stop "bug 123456" from working (though admittedly I could live
without that one), but also "c:\temp\test file.txt".

Perhaps the best solution is to add a flag to loadURI that allows us to suppress
the dialog (and the search engine fall back)?
Diego wrote:
> - Mozilla should sanity-check the contents of the clipboard and only load URLs,
>   not random garbage.
> 
> Nobody seems to be against this, but nobody has stepped up to provide a patch

Wrong on both counts.  That was bug 85677: I attached several patches to sanity
check in various ways, and everyone connected with the bug decided that they
didn't want any such fix and that doing sanity checking for middlemouse paste
that wasn't done for the normal urlbar was wrong.  Long since closed as wontfix
for lack of interest.

Jag wrote:
> If I recall correctly, Mozilla has always "blindly" tried to load anything a
> middle click might throw at it, no checking ever happened before loadURI was

Correct, and also true of NS4 (see discussion in bug 85677).

> Perhaps the best solution is to add a flag to loadURI that allows us to suppress
> the dialog (and the search engine fall back)?

I always get the search engine fallback anyway.  Just now I highlighted "sanity
check" and middlemoused it into the content area, and I got taken to
keyword:sanity%20check and a google search page.  Are people actually still
seeing "an alert box with web contents in it"?  )The flameage hasn't generally
been about that so I was assuming the summary was just some long-since-outdated
relic.)  Do you have your search pref turned off?  

Adding a flag to suppress the dialog would be fine with me (and I can take the
bug and do the work if it would make people happy), but let's make sure we know
how to test it.

See also bug 135884 (which probably should be duped to this one, or vice versa)
and bug 111337 (requesting what Elmar suggests in comment 51).
OK, so this bug boils down to deciding whether or not to expose this pref and if
yes on which platforms.  I'm willing to update my patch to be Unix only if that
is the consensus.  I still believe this is nice to have everywhere.
Akkana wrote:
> Are people actually still seeing "an alert box with web contents in it"?

You can see diffent dialogs depending on clipboard contents, e.g.:
(note: I have "Internet Keywords" turned off.)

  Summary:   -> "Summary is not a registered protocol."
  happy),    -> "www.happy),.com could not be found..."
  alert box  -> "The URL is not valid and cannot be loaded."

I don't know if disabling all of them would be feasible, though it might be a
simple solution for common cases. I'd still vote for the pref option, though.
My reaction to reading this bug is a HUGE sigh of "OH!"

So THATS what was happening for the last FIVE YEARS or so whenever I'd
accidently click in the white area, and accidently got some recently visited
webpage. Somehow I managed to simply not make the copy/paste connection in my
head, probably because apps under slackware/fvwm/X11 didn't seem to often agree
on what was even in the clipboard, heheh. Could easily get two totally different
results from Netscape and bash with a middle click.

Im not sure exactly what was wrong with my Netscape 4.x (where X is greater than
or equal to 5), but when I migrated all those years ago, instead when I missed,
on certain webpages nothing would happen, and on other web pages, the browser
would seize up then join the Great Walking Undead, consuming all available CPU
cycles and not responding to anything. Yeah, as in needs a kill -9. Eventually I
resorted to a renicing wrapper in /usr/local/bin ... set it to +10, which made
recovery much easier and also eliminated wasted CPU (MP3 encoding took ages back
in the day, at least with a good sounding codec it did..) time if the browser
locked for some other reason while I was away, typically a failed attempt at
email retieval.

1. This bug does not effect Windows 98/ME:
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130
2. Just checked with my Linux (RedHat 7.2, Kernel 2.2.23, yes I backdated it due
to a hardware issue)
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3a)Gecko/20021212

The bug is STILL PRESENT. What gives anyways, that X decides to do this sort of
thing? Its "expected behavior" when text appears underneath the mouse pointer as
a result of a paste, yes, but when I look at a web page I am seeing and thinking
"Nice background graphic" (or "nice crisp clean lack thereof") rather than "this
background symbolizes the URL that metaphorically supports these images and
text" (thats all the rationale I could dream up for it, actually. 

Exactly what *is* the rationale? This is a far cry from any "expected" X
behavior I know of! Just for the sake of making sure I was right, I attempted to
"paste" a path&filename into just about every vacant non-editable space there
was on GiMP, in a variety of GiMP's windows. Nothing Happened. The behavior I
expected, at least. I'm not aware of any, but X has been around for longer than
Win32, so I have to ask: Does ANY other X ap work like this with respect to
pasting in a truly odd place?!?!? Cause I have this *really* strong suspicion
its not any window manager deciding that the background image is a good place to
put text, but rather, Mozilla. It makes about as much sense as parking your car
in the living room for convienence... this is really something that should have
been given a full frontal featurectomy long ago. 

Method A:
1 Clickhold on one end of URL.
2 Drag to other end.
3 "Clickpaste" into the background.

Method B:
1 Clickhold on one end of URL.
2 Drag to other end.
3 Paste into the clearly marked text box, which nicely selects all the text if
you right click for pasting.
4 Hit enter.

Ever been to a web page with forms on it, that is more than just a little bit
incompatible with the normal function of the "Back"? Thats common these days due
to the fact that it creates another page-hit if the page refuses to stay
cached... Basically, what I'm saying is that its just too damn easy to lose a
lot of hard work between a missed click and user-hostile page-refresh scripts.
Besides, its intended use is absurdly counterintuitive. Sure it saves a little
time I spose, but I think a special sweetspot to deposit these loads might be a
better approach. A button or box even. Or if I may be so radical as to propose
the obvious, the address bar? 

Add a pref! This behaviour (being the primary way I can quickly paste in URLs
mentioned on IRC, in README files, etc) is near and dear to my heart, and I'd
hate to deprive those who don't know where to find a list of the possible
settings prefs.js from having the ability to use it.

The address bar doesn't work for reasons suggested in comment#19, and the folks
who object to this feature are primarily doing so because they had no prior
knowledge of it. Adding it to the preferences not only allows those who dislike
this behaviour to disable it, but also makes people more aware of the behaviour,
and so able to make use of it rather than swearing at it. :)
As I mentioned above, there now exists another fix for the handling of the
address bar paste issue...

Besides, for all too many, this "feature" has had all the convienence of an
f-key shortcut for "/bin/rm -rf /&" ... its definitly not something that should
be on by default, even in Linux. Rather, let unix users turn it on themselves.
Blocks: 144260
I completely concur with Jason Kennerly's comment #57.  This "feature" is insane
and I can't believe it's deliberate.  If we're throwing around old ****
credentials, I've been a Unix user since 5th edition on the PDP-11 and was one
of the developers of X11R1.  The middle-button behavior is completely out of the
spirit of anything I've ever seen in Unix or X.  I've triggered it by accident
many times but thought it was a bug caused by some unintentional interaction
between Mozilla and X.  

Middle-clicking in an inactive non-entry area shouldn't paste text into a
completely different area any more than poking your car key into your office
wall should start your car while the car is out in the garage.  Mozilla should
not try to figure out whether the stuff being pasted is a URL; it should just
never paste when you click in inactive areas, period.  The security issue of
having clipboard text appear in the alert box is real.  Navigating to a url that
you didn't intend to can also have bad consequences.  

There's no reason to have any visible pref for this lunacy.  It should just
always be off.  If it's not removed altogether, then anyone perverse enough to
want it can figure out how to edit prefs.js.  

If you REALLY want to have a way to click middle to navigate to a url in the
clipboard without having to select the nav bar text, then at least limit the
behavior to some area of the chrome that's unlikely to get clicked by accident.
The "m" logo that navigates to mozilla.org when you clicked left on it might be
an ok place for that.  Or maybe some kind of toolbar button could be coded in
XUL just for the purpose, and installed on the toolbar by users who want it.
Addendum to above: another reasonable way to implement this feature would be add
an item to the "Go" pulldown menu.  You'd pull down "Go" and select "Navigate to
contents of clipboard".  I like that better than putting it on the "m" logo. 
There could still be an optional XUL toolbar thingy that did it.
Great Feature! Really. I was always looking for something like that and only
stumbled on it because of the release notes.
Yes I am a pervert. I like this feature, and hold it very near to my heart.

I have been using it ever since I discovered it about three years ago. The
feature is not insane and it is certanly not a bug. So what if other programs do
not have this behaviour. It is their _loss_. I think it would be very intuitive
for a prog like gimp to open a file if I pasted a sting looking like a file onto it.

I do not think the feature should be off by default, or if so there should be an
UI element to turn it back on as already suggested, because it has existed for
almost ever. The oldest Netcape I could lay my hands on without spending a lot
of time to find and install was Netscape Communicator 4.76 for UNIX. It has the
exactly same correct behaviour.

To permanently remove it from Mozilla would be insane.

I am just a normal UNIX user on the desktop as well as on servers. If this was
to be ripped out of Mozilla I would stop using it.
Product: Browser → Seamonkey
Assignee: bugs → prefs
Severity: normal → minor
Status: ASSIGNED → NEW
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
Priority: P5 → --
Target Milestone: mozilla1.2alpha → ---
Changed Summary for better bugzilla discovery
Summary: I get an alert message with web contents in it! → Nee UI for middlemouse.contentLoadURL
Summary: Nee UI for middlemouse.contentLoadURL → Need UI for middlemouse.contentLoadURL
Philip, please consider obsoleting the two patches as they don't apply anymore and the review(er)s probably aren't accepted for SM (currently the flags suggest this is ready for checkin). I'd do it myself but I'm neither the author nor the assignee, module peer or Council member.
Comment on attachment 90413 [details] [diff] [review]
preliminary patch - adds checkbox

Obsoleting patch.
Attachment #90413 - Flags: review+
Comment on attachment 90860 [details] [diff] [review]
help update to complement the patch

Obsoleting patch.
Attachment #90860 - Flags: review+
> I'd do it myself but I'm neither the author
> nor the assignee, module peer or Council member.
OK. Done.
Keywords: relnote
The middlemouse.contentLoadUrl feature changed to OFF when I upgraded to ff 5.0 :(

I quickly re-enabled it using about:config and all was fine until I restarted ff, it was off again ? How do I store this permanently ?

ps. And why was the behaviour changed ? I paste URL's in ff/mozilla pages for ages now and find it very convenient. Btw. konqueror also does this right (allowing URL pasting in a page).
(In reply to hans from comment #70)
> The middlemouse.contentLoadUrl feature changed to OFF when I upgraded to ff
> 5.0 :(
> 
> I quickly re-enabled it using about:config and all was fine until I
> restarted ff, it was off again ? How do I store this permanently ?

No idea. For me, with both SM and FF, if I change the pref the change survives a restart. Maybe you have some add-on or user.js entry that affects your results.

The defaults of this pref are (and have been for a long time) "true" for Unix/Linux and "false" for Windows and Mac.

Anyway, this bug is about adding UI to Preferences of SeaMonkey, not about the defaults of that pref (which are currently stored in all.js which is used by FF, SM and TB).
I save prefs I don't want overridden in user.js -- just create a file by that name in the same profile directory where prefs.js lives. See comment 19 for syntax.
So, what's the final decision here? Changing default behavior under *nix is not a good idea, while adding pref to Mouse Wheel page looks right
Whiteboard: [2012 Fall Equinox]
> while adding pref to Mouse Wheel page looks right
I agree.
Whiteboard: [2012 Fall Equinox] → [2012 Fall Equinox][good first bug][mentor=IanN][lang=js/xul]
Depends on: 738786
Mentor: iann_bugzilla
Whiteboard: [2012 Fall Equinox][good first bug][mentor=IanN][lang=js/xul] → [2012 Fall Equinox][good first bug][lang=js/xul]
Keywords: good-first-bug
Whiteboard: [2012 Fall Equinox][good first bug][lang=js/xul] → [2012 Fall Equinox][lang=js/xul]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: