Open Bug 96972 Opened 24 years ago Updated 4 years ago

Need UI for middlemouse.contentLoadURL

Categories

(SeaMonkey :: Preferences, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

People

(Reporter: pabloa, Unassigned, Mentored)

References

()

Details

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

Attachments

(2 files)

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: