(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: 3.0.2 (using KDE 3.0.2 ) Severity: wishlist Installed from: SuSE RPMs Compiler: gcc 2.9.5 OS: Linux OS/Compiler notes: Not Specified The middle mouse button can obviously both be used for opening a link in a new konqi-window or for pasting a URL. The first happens when the mouse is over a link the second if it is anywhere else in the window. Personally I use the middle click much more often for opening a link in a nwe window than for pasting a URL. The trouble is that if you slightly misclick (i.e. not exactly on the link) Konqi assumes you tried to paste a URL. This can be quite annoying - and it took me quite a few misclicks to figure out what was happening. My suggestion would be to have the pasting only work for the URL-bar not anywhere inside the displayed page. This makes pasting in URLs a whee bit less easy but since opening new windows is a much more common thing to do than pasting URLs I think this would be reasonable. (Submitted via bugs.kde.org)
This is bug not a feature request. If the current selection in Klipper is a URL clicking the middle mouse button anywhere on a web page (except for a link) will open the URL selected in Klipper. I think that the result of doing this should be that nothing happens. -- JRT
this is a feature that many like to have.
Ok, I accept people having a taste different from mine (that's why the original report was tagged as wishlist), but I think the point made in Comment #1 is a very valid one and should be dealt with.
Umm - rereading Comment #1, it's different from what I thought it was. I thought is said, konqueror should at least not try to open something pasted into it, that definitely doesn't look like a URL. That would be nice. Otherwise (as always) you could make it configurable.
ok, to summarize: konqueror should only open pasted selections when they look like URLs.
Created attachment 190 [details] Patch for enable/disable mmb paste in khtml
Created attachment 191 [details] Patch for add mmb paste option in kcontrol
The above two patches (that I couldn't add as single comment with two patches) adds the needed things to kcontrol and khtml. In kcontrol it moves the "Right click goes back" option together with mmb option to an own "Mouse Behavior" frame.
*** Bug 49082 has been marked as a duplicate of this bug. ***
*** Bug 57208 has been marked as a duplicate of this bug. ***
actually this is a bug/design flaw. This IS a securtiy breach, because people will accidentaly send their credit card number to google, or similar. ALSO, my bug report witch got marked as a duplicate of this included a coment about how submitting a malformed url causes a search to be performed on that. That is also a privacy/security leak... though it's a bit less severe, it should not be default behavior and it should be a bit smarter/ prompt for a search or pause a couple seconds so that xxx doesn't get searched for when the person meant to go to www.bbb.com (some people use different keyboard layouts that place x and b next to eachother) -AP
Bug 54536 is another duplicate of this wish. This wish is neither a bug in the software nor a design flaw. If you have problems avoiding clicking the mmb while using the wheel it's more like a hardware flaw for which software can't be made responsible for. The feature which people question here works perfectly fine for me and I'm using it all the time. Selecting a url and surfing to them by mmb clicking as well as selecting text and searching for it by mmb clicking rocks. Thus I think removing the whole feature altogether (whether "only" making it optional or not) would be a heavy cripple. My suggestions for improving usability are: - Allow mmb url paste to be opened in a new tab/window. - Make mmb url paste only work when the current widget has the focus. - Allow to choose any search engine and to disable the automatic search which is invoiced whenever a text string is not detected as valid location by any kioslave. Any other problem which isn't solved by those possible solutions?
My personal issue with the 'middle click in konqueror opens the url in the clipboard is the following': - a page I know already is being downloaded by khtml - I spot the URL I want in the left pane (for example) - I middle click to open it in a tab - nothing happens (no new tab) but after some point, I realise that some URL has been pasted in the location bar. It took me a while to figure out what was going on: just at the moment where I wasmiddle clicking, the page was resized by khtml, thus my middle click missed the link, thus, the content was pasted into the location bar. This is why, as the first reporter, I suggest to disable the "middle-click paste the url into the location bar feature". I think the original idea was fine but that it now creates usability problem combined with the "middle click opens new window" and frequent khtml resize. Middle clicking on the Location label could replace this feature without losing too much of the functionality. I also support the guy saying that this is a security problem.
Am I right in assuming that you don't mean "middle-click paste the url into the location bar feature" but "middle-click opens the clipboard content in the konqueror window feature"? The location bar is that little row right above the view area of Konqueror where the path/URL text of the current view is shown. Afaics the suggestion I already mentioned above, making mmb url pasting to be opened in a new (background) tab/window instead the current view, would help in your case as well.
I really mean the location bar, but I don't see the distinction with the thing you describe. Viewing whatever page with Konqueror, if I middle click on the page and there is any selection inside the clipboard (I don't know if it is related to klipper but I would not think so) it will open the URL in the location bar. Even if this URL does not make sense, it will open it by searching it on google. If you really want to keep the "pasting URL in konqueror opens it automatically", I suggest to only allow it when pasting on the location bar (black arrow or label). That way, you are sure that the user has not misclicked. I honestly think that the number of user using middle click to open new pages or new tab is superior to the number of user using the 'paste url trick'. Another solution is to use some 'guards' around links. If somebody middle click very nearby a link or when a page is resizing, one can assume that he was not meaning "open this URL in this window" because he still has not had the time to view the current page. You use this kind of trick with pages you have already read and that you don't want to see anymore, so it is not supposed to be still loading at this time. And you probably won't middle click near a link to avoid confusion.
This bug contains an accessibility problem as people with certain disabilities will have problems to position the mouse exactly on a link. So to speak they will almost always get the wrong result. According to the discussion above there are different opinions about how to deal with this topic: - Allow the "paste" feature only in the location bar - Add some 'guards' around links and additionally ignore all middle clicks before the page has been completely loaded (to avoid clicks when resizing the page). I would prefer the first solution. With the second one you need at lest an option to specify the guard size. Also it might be annoying to see that nothing happens just because some very slow-loading advertisements are not yet there.
What really really needs to be done is AUTOSCROLL that will solve this problem extra regions arround links is a way over engineered solution... though it was worth mentioning, and I tought it was kinda interesting... I know how to middle click and left click and right click... and not do the wrong one... EXCEPT, that I have been conditioned that the middle mouse click (with scroll wheels) is to do the autoscroll feature. I love that feature, and I use it all of the time. I go through the trouble of putting it into mozilla/phoenix with a plug-in The current behavior is just plain wrong, and there are enough people who are defending it as default behavior.. even though there is no way to turn it off... so nobody is turning it off... We need to focus on AUTOSCROLL this feature is needed badly in konqueror... and it will squelch this stupid debate.
We have autoscroll.Try shift-up, shift-down.
I don't think holding the shift key and holding an up button is the autoscroll that I'm talking about. I guess that you are talking about the page scrolling at a certain speed based on shift arrows.. ... and unfortuantely I don't have a better name for what I am thinking of... so I shall describe it. (also what I am talking about is called autoscroll in mozilla/phoenix) middle mouse click on a non hyperlink a white circle appears with the mouse centered in it. This white circle has an up arrow and a down arrow. (sometimes left and right if the page scrolls horizontaly too) The cursor consists of just the arrows. The user moves the mouse outside ofthe radius of the circle and the page starts scrolling. It scrolls very slow when near the circle, and speeds up the further the cursor is from the circle. (The circle stays at the same spot on the screen) The scrolling can be stopped by clicking (also gets rid of the circle) or putting the mouse cursor back inside of the circle. (actually mozilla uses an opaque circle) Why is this a good feature? analog scroll speed. one handed operation no need to switch between keyboard and mouse (the shift arrows seems like it would be very nice... just requries me finding my keyboard!) a bit about good computing environments: I should not have to move my hand between the keyboard and the mouse except for when I want to.. (and I even think there should be a pop up keyboard like on pdas.. but that isn't part of this discussion...) The system should be able to tollerate a cup of coffee frying the keyboard. The system should minimise operator work/seeking... My hand to mouse seek time is... about a second... I use the keybard for selecting text and changing windows etc if I'm typing something... I use the mouse if I'm browsing something... I should not have to touch the keybard. I will not buy a macintosh because their stupid two handed aproach. It is tough enough for me to use one hand. (thinking of their laptops, I refuse to require an external pointing device) I can do something else with my other hand, like drink some coffee, or hold up a document that I am comparing to what is on the screen... I can adjust my monitor setttings, I can scratch myself... This amounts to a large amount of saved time. good day
Middle mouse button click paste is a standardized and widely used behavior within the systems KDE is used on so it makes no sense to give it any other arbitrary behavior in some selected special cases. Clipboard content paste and loading on mmb click is an extension of this existing behavior, the only thing we should do is slightly modifying this behavior in sensible places for improving usability and accessibility (like, my suggestions, mmb click on a still loading page should also stop the loading progress so there won't be any further resizings/movings and spawn a new window/tab instead loading into the current view). An "internet explorer alike autoscroll" feature on mmb however will be confusing as hell since there simply is no indication of it whatsoever, it breakes consistency of mmb behavior between the selected web browser and the rest of the system (and don't suggest replacing mmb paste again, it saves me and others a large amount of time as well so why removing it). I think a better (ie. more obvious and direct) solution for this would be a "overview scroll area" in the bottom right between the horizontal and vertical scroll bars similar to the one offered by many image manipulation programs like the Gimp etc. But this is a whole different topic and I hope I'm the last one contributing to this off topic aspect. This kind of feature request should be filled separatelly. > Viewing whatever page with Konqueror, if I middle click on the page and there is any selection inside the clipboard it will open the URL in the location bar. No, it will try to open the string in your clipboard in your current view, the location bar is just displaying the result, the location of your current view. Whatever protocol is applicable will be used (think http, ftp, file etc. and web shortcuts like gg, dmoz, atw etc.), and if none is the string will be sent to google for doing a search for it. "middle-click paste the url into the location bar feature" is what you get when you do just that, mmb clicking into your location bar will paste the clipboard content into your location bar, nothing else, just like mmb clicking will paste the clipboard content into any other text interface you use.
actually, all of KDE needs this autoscroll feature. good point. It's also kword, kwrite... etc.. and HEY FOLKS, IT SHOULD BE TURN OFFABLE or heck, even off by default if you want... but pasting into the main frame of an html document, causing it to send the contents of the clibpoard to a search engine should be off by default... and possibly hard to turn on. -AP
You know I have a hard time taking this kind of calls serious. > and HEY FOLKS, IT SHOULD BE TURN OFFABLE It is, rip off your middle mouse button and there you go. > or heck, even off by default if you want... No, I and many others don't want that at all so it won't become a default ever. > but pasting into the main frame of an html document, causing it to send > the contents of the clibpoard to a search engine should be off by default... Middle mouse button clicks always pastes the clipboard content, and your browser is your window to the whole wide internet world. Why would you want to use middle click pasting into the window to the whole wide internet world if you don't want it explicitly? Because you are still stuck in your "internet explorer autoscroll" expectation and resist even to try to know better, to know that you a using a completely different system, completely different applications, altogether with a completely different history? Sorry, your kind of arguments doesn't make any of the widespread mmb paste users a convert. I suggested quite some solutions which I'm sure would satisfy most people's remaining concerns. But you keep pushing full force for drastic changes, and I'm already pretty sure this is leading nowhere since everyone gets fed up by this topic even before touching it. > and possibly hard to turn on.
Datschge, I agree with your point about consistency. I personally hate the autoscroll feature of IE. It may be acceptable on windows where the middle mouse button has never had any signification but on Unix, mmb means pasting since ages and it would be a mistake to change its behaviour too much. That said, middle mouse button in konqueror is "open page in new window/tab" when you click on a link. > > Viewing whatever page with Konqueror, if I middle click on the page and there is any > > selection inside the clipboard it will open the URL in the location bar. > No, it will try to open the string in your clipboard in your current view, the location bar is just displaying the result, Is it in CVS ? I am running kde 3.1.1a and I don't experience the behaviour you describe. Using mmb in konqueror will make it immediately load the new url, or search the file on google if it is not an URL. If we don't have the same behaviour already, it is very difficult to communicate on how to improve it. I think we should all calm down here. I am just trying to present argument why the mmb behaviour is a problem in certain circumstances and that this should be taken into account. > Why would you want to use middle click pasting into the window to the whole > wide internet world if you don't want it explicitly? A few reasons have been given already: - you come from the windows world and are used to another behaviour from the mmb, so you use it all the time. I agree that we should not enable the IE feature but it does not mean that Windows habbits should be completely ignored. Transition should be as smooth as possible. This is why we allow double-click for example. - you are a normal legitimate user but at the time you clicked on a URL, khtml just resized and you clicked on an empty field - you suffer from carpal tunnel or other handicap and you are not very smooth with your mouth handling so you may miss a link - [just happened 3 seconds ago while filling this field] you want to paste some text into a field box on a html page but you miss the edge of the box because it is not displayed. - you are scrolling strongly with the mouse wheel but do it too strongly and you misclick. So, as you see, middle click in a web page happens for users, for a wide variety of reasons. It may not happen to you but it happens to many users, whether they are normal users, or whether they suffer from carpal tunnel or simply are converts from windows. I don't think we should simply ignore those users. The goal of KDE is to be a friendly user desktop. The current behaviour I am experiencing (direct opening into internet, not the one you describe) does have problems because the content of the clipboard might be sensitive data: a password or a credit card number. > If you have problems avoiding clicking the mmb while using the wheel it's more > like a hardware flaw for which software can't be made responsible for. I don't blame the software, but intelligent software should take it into account. My suggestion is to make something explicit "you want to open an URL with konqueror by pasting it" even more explicit by allow it only under location bar. Another possiblity is the one you describe, where it pops up klipper. But I am afraid people won't notice the klipper popup. Another solution is to popup a dialog to ask the user what he intends to do. That way, misclick have an instant feedback so you don't have the "I click on a link and wait but nothing happens because I did not realise that I did not click exactly on the link".
> That said, middle mouse > button in konqueror is "open page in new window/tab" when you click on a link. And that won't be removed for sure. > Is it in CVS ? I am running kde 3.1.1a and I don't experience the behaviour you > describe. Using mmb in konqueror will make it immediately load the new url, or > search the file on google if it is not an URL. If we don't have the same behaviour > already, it is very difficult to communicate on how to improve it. No, we are talking about the same behavior. You described the behavior perfectly this time, my only point was that the location bar, a text field, is only indirectly involved with this behavior. > - you come from the windows world and are used to another behaviour from the > mmb, so you use it all the time. I agree that we should not enable the IE feature but > it does not mean that Windows habbits should be completely ignored. Transition > should be as smooth as possible. This is why we allow double-click for example. My suggestion above was opening the pasted clipboard string in a new window/tab ideally in the background which would allow people to continue surfing on the current page. An unexpected new window/tab but nothing destroyed, how much smoother do you want it? > - you are a normal legitimate user but at the time you clicked on a URL, khtml just > resized and you clicked on an empty field My suggestion above was stopping the loading progress of the current page on mmb clicks for avoiding that the page gets resized. As for "clicked on an empty field", again let it open in a new window/tab instead in the current view like it's the case right now. > - you suffer from carpal tunnel or other handicap and you are not very smooth with > your mouth handling so you may miss a link You are not any more likely to miss a link when the mmb click paste feature gets removed. A way better solution for these kinds of handicaps would be zooming targets so the link is in original size before hovered but increases its size which makes it more unlikely that the mouse pointer accidentally leaves the target again since it's normally so small. This is completely unrelated to our topic though so please fill a separate wish report for it. > - [just happened 3 seconds ago while filling this field] you want to paste some text > into a field box on a html page but you miss the edge of the box because it is not > displayed. Again, let mmb paste open a new window/tab and this isn't a real issue anymore. > - you are scrolling strongly with the mouse wheel but do it too strongly and you > misclick. Misclicking can happen everywhere, that was never an excuse to remove functionalities. I mean how many windows users are complaining that their mice got stuck in internet explorer due to autoscroll? How come suddenly so many people are pressing that hard on the wheel while scrolling, or are those hardware problems I myself was lucky not to experience so far with my three mice? > I don't think we should simply ignore those users. The goal of KDE is to be a friendly > user desktop. And I'm suggesting possible solutions for all problems mentioned, why do I get the impression they are completely ignored? *sigh > The current behaviour I am experiencing (direct opening into internet, > not the one you describe) does have problems because the content of the clipboard > might be sensitive data: a password or a credit card number. I agree that at that point a dialog window should appear warning you that you are about to send possibly sensitive data into the internet, just like with unencrypted data transfers. This would also be a chance firstly for the user to cancel that action and secondly for educating him about that particular behavior. > I don't blame the software, but intelligent software should take it into account. Intelligent software is not software where popular features get removed since few don't like it, it's where features are kept but tweaked until ideally everyone is happy. > My suggestion is to make something explicit "you want to open an URL with > konqueror by pasting it" even more explicit by allow it only under location bar. I don't know what you mean with "under location bar". When you do a mmb click paste while hovering the mouse pointer over the location bar, a simple text field, you're only simply pasting text into the location bar without further effects. If you meant restricting the ability to do mmb paste to a small part of the whole khtml view, I can only say that that would be a usability horror par excellence since how do you want to make it obvious where mmb paste is supposed to work and where not? > Another possiblity is the one you describe, where it pops up klipper. But I am afraid > people won't notice the klipper popup. I never mentioned Klipper. Also I deactivated Klipper actions and use it only as clipboard history list. > Another solution is to popup a dialog to ask the user what he intends to do. That > way, misclick have an instant feedback so you don't have the "I click on a link and > wait but nothing happens because I did not realise that I did not click exactly on the > link". This is no solution, this is a try at a workaround trying to make the computer look smarter than the user using it. Imagine you'd get message dialogs like "You just clicked on the link but I think you didn't intended to do so. Did you really want to click the link? Yes No Cancel"...
***** > Viewing whatever page with Konqueror, if I middle click on the page and there is any selection inside the clipboard it will open the URL in the location bar. No, it will try to open the string in your clipboard in your current view, the location bar is just displaying the result, the location of your current view. Whatever protocol is applicable will be used (think http, ftp, file etc. and web shortcuts like gg, dmoz, atw etc.), and if none is the string will be sent to google for doing a search for it. "middle-click paste the url into the location bar feature" is what you get when you do just that, mmb clicking into your location bar will paste the clipboard content into your location bar, nothing else, just like mmb clicking will paste the clipboard content into any other text interface you use.****** Well then... isn't that confusing? I'm not asking them to remove a "feature" from existance, I am asking the developers to put a non standard, highly unexpeted, dangerous, utterly confusing, WORK LOOSING (oops my form that I started filling out was wiped out by one measly mouse click!!!!! (I have an urge to call you a name... but am filling it with this) (rem this sentance continues with asking developers to put ... ("feature") in some advanced tab under Konqueror behavior. I know of no other application that blows work away so quickly (some websites don't let you go back!!), is a security hasard (sends stuff to the internet... and I guess if it's not a URl it sends it to a SEARCH ENGINE IN PLAIN TEXT!!!!, and leaves the user wondering what the heck happened... and that a cat can do in one step! I guess kamil is the next closest.. a distant 2nd... with all of the single button short cut keys... and the bug that KDE applications keep focus when switching to a gtk application... and typing a command can DELETE all of your email (the command had a y in it... luckilly it went to the trash can rather than deleting it... I shudder what would have happended if my caps lock was on.. Oh, it also didn't send email half the time... with no error messages, and everything else worked... (I remember something about strict email address formatting... that is rediculous and wrong, I don't want my email to say it went to joe --rant ended-- (middle mouse click paste makes sence in umix on text fields ONLY (where the text cursor is shown(or mouse becomes I cursor..)) (I mean what I'm used to.. and what other people I know expect/majority of the people use...(windows mozilla, macintosh) and they all have the middle mouse button scrolls the page feature) anyway... call me up or something 509 332 7697 I want to help, and flaming isn't exacly helping... but i'm on fire man.!
Subject: Re: middle click behavior: open link in new window or paste a url Let me try to re-summarize what really makes up the problem. I'm sure not everybody will agree - but I'll give it a try: mmb has two different functions in konqi: 1) pasting stuff 2) opening a link in a new tab/window actually it has three quite different uses: 1 a) pasting a URL/search-string 1 b) pasting text in a form 2) opening a link Now that in itself is not the problem. And I'm not arguing to _remove_ any of these features. The problem is, that those three uses live in potentially very close vicinity: You can have a textfield in a form next to a link, next to a non-link. Where exactly you click may produce extremly different results. Some have argued, that this is potentially hazardous especially if you accidentally paste a URL/search-string (or konqueror believes, that's what you were trying to do), while actually you were trying to paste something into a form. So how to resolve this? My favorite approach would be to separate the three uses in space. One way of doing this would be to e.g. make the URL-pasting work only on the arrowish button to the left of the location-bar. Yes, that would mean, that if you want to paste a URL via mmb, you need to position your mouse over that button instead of just clicking anywhere in the window. However, since at least in my personal use of konqueror, mmb-pasting URLs is much less common than uses 1b) and 2), that would seem more than acceptable to me. It will mean, that use 1 a) will be slightly harder to accomplis, but certainly performing the mmb-click on a button instead of in the main window is not exactly a big deal to those claiming "I never misclick ever". (As rather personal remark, let me add, that it never seemed entirely logical to me, to be able to drag-and-drop or paste to an inherently _read-only_ viewing-area. Yes, you should be able to paste in the location-bar, and yes, we might automate pasting and opening a URL by allowing mmb-clicks on the arrow-button, but really, what's the logic in pasting something into the rendered view of an HTML-page?) Thomas
In reply to Datschge #24: > My suggestion above was opening the pasted clipboard string in a new window/tab > ideally in the background which would allow people to continue surfing on the current > page. An unexpected new window/tab but nothing destroyed, how much smoother do > you want it? Sorry for not replying to this one. The problem with this solution is that when you middle click on a link, you expect a new window/tab to open. If you miss the link, y ou will still have window/tab opened, so you have no clue that you missed the link and what was opened is not the new page but the content of the clipboard. This is why I think this solution is not appropiate. > You are not any more likely to miss a link when the mmb click paste feature gets removed. Indeed, however, the absence of feedback informs you that you missed the link. Maybe another way to tackle this problem is to add more visual feedback on link clicking, so that you know when you missed it. > If you meant restricting the ability to do mmb paste to a small part of the whole khtml view Not on the khtml view but on the label "Location" (not the content, the label) and the black arrow. Pasting on the displayed page would have no effect.
I'm glad to see that there is a good discussion on this, and that a good number of people, like me, are against the current behavior. I have made the mistake many times myself of accidentally middle clicking while I had a URL (or something Konq thought was a URL) selected. I have a few points to make. First, make it a configurable option. We already have the option to make a right click go back in history. Don't give me any of this hypocritical nonsense about how adding configuration options is bad. Second, the issue of "standard" behavior. Perhaps Mozilla/Netscape and some other browsers implement this "feature." That doesn't entail in any way that the feature is standard. According to Datschge, middle button click on most of the systems Konqueror runs on has as its "standard" behavior some sort of clicking. Not so. As pointed out above, that behavior is only expected of MMB clicks in *text fields*. MMB clicking and dragging has many different uses in non-text widgets in X, none of which could reasonably be called "standard." Third, autoscrolling is useful, regardless of whether it comes from the taboo Windows world or not. I would also like to see it in KDE as a whole, not just Konqueror, although I don't have any good idea of what gesture/action/etc. should evoke it, since many apps are taken up mostly by text areas, where the MMB paste behavior is expected and established behavior.
Philippe Fremy and I moved this discussion to the mailing lists where following patch comitted to CVS was considered a sufficient solution us as for now: http://lists.kde.org/?l=kfm-devel&m=105325573004120 Please check it out, depending on the response I suggest closing this wish. Unrelated wishes like autoscrolling should be opened in separate wish reports.
*** Bug 62004 has been marked as a duplicate of this bug. ***
*** Bug 61771 has been marked as a duplicate of this bug. ***
[MMB Google Search comments] The patch is welcome but IMO it would be best to disable mmb google search completely by default. The confirmation dialog can still be very annoying. Now think disabled people with eyesight or hand problems! If it is a problem to many people there should be strong justification to keep it, I don't see one. - Most of the time you will want to type what you want to search. - Even if you can copy your search, if it is a whole sentence most of the time you'll want to quote it ("sentence"). - It doesn't gives you the chance to add other words/senteces to the search, or options like "site:.de". So it can only be usefull in certain *very particular* cases, and you can still get along fine by using your general search method (and that's what most people will do anyway). [MMB paste Url] I don't find it that important either, you can use "Alt+F2 and paste", "Ctrl+O and Paste", "Klipper"... BUT this is less of a problem, since you don't have urls on your clipboard all the time. So I'd say keep it but add the "confirmation menu" similar to "drag and drop copy, move, link, cancel" one. Confirmation is very important for the user to understand what is going on, and to avoid unfortunate pastes. [Final Thoughts] MMB Google search: Disable it completely by default. MMB Url paste: Add a confirmation menu.
> > My suggestion above was opening the pasted clipboard string in a new > > window/tab ideally in the background which would allow people to continue > > surfing on the current page. An unexpected new window/tab but nothing > > destroyed, how much smoother do you want it? Confirmation dialog: ------------------------------------ Paste to background tab Paste to current tab Cancel ------------------------------------ I know the wording is terrible but you get the picture. This feeback is very important, it gives you a chance to cancel it and the user will have a better understanding of what's going on. J.A.
I still believe that this is a bug, not a feature. It still does this in 3.1.4 + so I have updated this. I am currently building 3.2RC2 (it takes a while) so I will test that later. -- JRT
I'm using latest CVS (13th December 2003), there's still this bug - ie. when I middle-click, tries to go what's pasted in the clipboard. And I agree, autoscroll is needed, in all KDE applications, not just Konqueror. Mozilla FireBird has autoscroll by default now, so why can't Konqueror?
Why are so many people against middle click = go to clipboard? This is something that has been in Mozilla for ages and ages, and something I use every single day in both Konq and Mozilla and could not do without. Please please please do not consider removing this feature.
One shortcut I would considering changing is making shift+LMB to also be able to open the selecting link in a new windows (or new tab, which I would prefer). Currently there is control+LMB, but shift+LMB is more in lines with mozilla/IE.
I don't get why just highlighting text automatically copies it to the clipboard. I don't see the point of that. eg. sometimes in Konqueror, when you open the properties of a file, the window that opens has some text in a text box which is highlighted and that automatically goes to the clipboard. With middle-click pasting, the problem with that is that the middle-mouse button is one of those buttons which is easy to accidentally press, and so you can mess up a lot just by pressing it. To add to the confusion, CTRL+C and CTRL+V also work, but they seem to sometimes add to a seperate clipboard. So personally I think middle-click pasting and just highlighting to copy should be disabled (although there should be an option to switch it on.) To copy, you press CTRL+C. To cut, you press CTRL+X . And to paste, you press CTRL+V. And clicking the middle mouse button will bring up an autoscroll feature which _is_ useful because it allows you to quickly go through a page without having to hold down a button/key. The autoscroll Konqueror has at the moment isn't good enough.
Correction on comment #1: > If the current selection in Klipper is not a URL, clicking the middle ... That is, it should not envoke a search engine to do a search unless you click on/in the Location window. Perhaps it should be possible to turn this automatic search engine envocation off. Myself: I never use this "feature" and I would like to be able to turn it off so that an accidental MMB click will not change the URL in all cases unless it is on/in the Location window. Re #38: To try to clear this up: "highlighting text" does not copy it to the clip board. It copies it to a buffer. Then if you execute a copy command with a menu or <Crtl>c, the text in the buffer is copied to the clipboard. You can observe this if you open the applet: "xclipboard". I believe that since X works this way that it has to work this way. The problem comes with MMB clicking to paste. A MMB click will paste what is in the buffer which is the last text highlighted unless you use Klipper to select something from the history list -- this changes the content of the buffer. If changes are needed, it is the MMB paste behavior that needs to be changed. -- JRT
Please, don't take that feature away! When I first discovered it (by accident), I thought ``it's ingenious!'' (and it was just about a few weeks after I stopped using IE). You could make it possible to turn off, but don't take it away altogether. And don't make it open a new tab instead (although that behaviour could be made an option). OTOH, opening clipboard in new tab by pasting (I mean middle-clicking) it over the ``new tab'' button would be useful (I have filed a wish report for that already). And target zooming (growing hovered links, perhaps just a semi-transparent (more transparent than semi ;-) oval around them to give feedback), as someone suggested, would be really useful not only to disabled people but also those that use very small fonts and often do misclick (like me ;-).
I agree with the previous post. It's also great to search in google on the fly. This is maybe the best thing in konqueror.
Subject: Re: middle click behavior: open link in new window or paste a url "If the same point is made twice by the same person, the thread is over" Well, then, to end(?) this thread, let me re-summarize comment #26: The problem is not so much about removing certain features, but rather about separating certain features associated with a mmb in space. Those functions are: 1) Opening a URL in a new window 2) Paste text into a form 3) Open a new URL/search string from the primary clipboard (mmb paste) Since especially 1 and 3 and 2 and 3 might potentially interfere, one of the most natural solutions would be to move 3 a bit away, spacially. I.e. allow mmb-paste operations only on the URL-bar, or possibly also on the "Clear location bar"-button, or some other place except the _view_-window itself.
Subject: Re: middle click behavior: open link in new window or paste a url > ------- Additional Comments From jsvrp.gw@myrealbox.com 2004-01-22 01:54 > ------- I agree with the previous post. It's also great to search in google > on the fly. This is maybe the best thing in konqueror. Umm... it's also available in Mozilla Firebird and Internet Explorer Firebird is easiest: google blah searches for blah In IE you have to install a power toy then it works the same as Firebird in Konqueror its gg://blah which requires hitting 3 key combinations... which is less convenient. 8 keys for konqueror and 6 keys for everything else... er 7 because you need a space... but they are easier to press
you should prolly try gg:blah ...muesli
> It's also great to search in google on the fly. Yes it is a *great* feature. You are scrolling through a web page with the mouse wheel and press a little too hard and BOOM you are now searching for something in Google -- great feature. NOT! This is not a great feature, it is a serious bug. -- JRT
Subject: Re: middle click behavior: open link in new window or paste a url > > It's also great to search in google on the fly. > > Yes it is a *great* feature. You are scrolling through a web page with the > mouse wheel and press a little too hard and BOOM you are now searching for > something in Google -- great feature. NOT! This is not a great feature, > it is a serious bug. Yeap, and come on, we have web shortcuts. Web shortcuts are more general in the sense that you can use them for non-google stuff, and more general in the sense that you can do any kind of search. It's quite easy to use to (gg:). Middle button click, may be a little more simple, but it works for google only, and only to google things you copied! It's such a particular case! Most searches cannot simply be copied, even if you have the stuff written somewhere many times will need to add at least quotes... Why keep a solution that is valid only for a *very particular case* and that has proved itself to be quite bad usability wise, when there is already far more general, quite confortable, solution? J.A.
I agree. For people who want to highlight a term and search for it, they should be able to just highlight it, right-click on it, and in the actions submenu there should be another submenu that says 'Search for on...' and in that menu there should be all the web shortcuts. Middle-clicking for it is bad usability.
The biggest problem is when browsing on pages with css. When you find a link you want to open in a new tab (with the MMB) and the page loads the CSS in that moment, all text (and links) jump around because the font sizes change and you miss the target and land somewhere you didn't want to go. Please at least let users turn off url-pasting completely. IMO it's a completely useless feature.
Why could we not simply make this configurable? Menu clutter is a good point, but this is obviously causing SERIOUS problems, while other people find it very useful. In my opinion, it warrants a configuration option. Of course, I would suggest it be off by default because it is inherently "dangerous". Personally, all *I* want is the ability to turn it off because of the trouble it causes me, but I've watched several green-user-type persons become very confused and frustrated when they browse the web and have this happen to them. Hey, in my car I have to depress the brake before I can pull the shift lever out of park, too.
The ideal solution in my opinion would be to have an option for the MMB with 4 choices: 1) No action (my favourite ;-) 2) Paste URLs only (current behaviour) 3) Paste URLs and search on Google for non-urls (old behaviour) 4) use scrolling (like in IE) With those choices, I think everybody would be happy.
> With those choices, I think everybody would be happy. I'd be happy! What dialog/ control panel module should have them? and how will we get the 4th one implemented? KDE Components (has file manager settings) or Peripherals (one is using the mouse, and the IE/Mozilla Fireforx autoscroll feature would hopefully work everywhere) or Internet & Network (the web browser is most affected by this) or Regional & Accessibility (this is an accessability issue)
Re: Comment #51 > What dialog/control panel module should have them? Internet & Network -> Web Browser -> Web Behavior -- JRT
Mozilla has this feature. However, it can be disabled by setting "middlemouse.contentLoadURL" to false. It is not a bad feature - what makes it so controversal - it *cannot be turned off*. The only fix to make everyone perfectly happy, is to make it configurable. ON or OFF. Simple. Don't worry about what the default should be - having it configurable is already an order of magnitude better than the current situation. Where should we put it, you ask? Easy. Right under "Right click goes back in history" under Web browser behavior. It's only logical to put them together because they both govern mouse button behavior when you are browsing the web. I don't think anyone cares about turning the feature off under File browsing mode.
> turned off*. The only fix to make everyone perfectly happy, is to make > it configurable. ON or OFF. Simple. Don't worry about what the default > should be I am worried. I think it should be off because there is a security issue with it. You could very well be pasting a complicated password in a html form and you don't want that to go to google. I personally prefer the situation where both the feature and a reasonable behaviours survives : - middle click in the html does nothing - middle click on the location bar label looks for the content in google But anything better than the current behaviour is welcome. Philippe
Agreed. My point is, supporters of the 'feature' bring up a point that this feature is also supported by Mozilla - it's fine - but they fail to mention that in Mozilla it can be turned off, but in Konqueror it cannot. I counted. Today I mis-middle-clicked once. It seems that I do it once or twice per day (when I slightly missed middle clicking a link for a new tab). So from this moment I'll be exclusively using Mozilla until this defect has been resolved.
An autoscroll feature is in Mozilla FireFox, but I'm not sure if it's in Mozilla. But KDE needs autoscroll, even if it's off by default.
I've been burned by many other mouse/keyboard incidents in KDE.. 1. single click mayhem ... oops, I opened that trojan! (konqueror file manager) ... oops, i just overwrote my homework (kio save as dialog, location) ... oops, I just searched for my password on google (konqueror web browser) ... oops, my cat just deleted all of my email (kmail has this fixed now, no single key shortcuts) ... oops, the directory that I was typing in got autocopleted as something entirely different than what I was working on, and now I have to backspace (path completion in file dialogs) This is a common theme across kde, but I still think gnome has us beat (just look at a window wrong and your applications will fail... example gdm settings) There are many reasons to double click. Your cat does not double click very often Still, KDE being the best is not enough, we need to strive towards perfection. These are all reasons why people don't use KDE.. they just go back to windows... there are a few of us submiting bugs of this type after loosing lots of work who are staying with the project. I have been attempting to fire up kdevelop and other development tools, but they are tough to use to actually start hacking on existing projects! If we had a bounty system, I'd pay the fixer a few bucks.. it should only take like 5 minutes to turn off the middle mouse button pasting for the right developer... and autoscroll would take some time... but these things would save enough of my time, that I'm willing to pay for them... The reality is that I am not free to change this software, because it would take too much of my time/effort to do so. Nevertheless, we should attempt to learn it, and lower the bar for succesive generations of users to learn how to hack^H^H^H^HDesign
I find that the "paste absolutely anything that is in the clipboard to the URL bar/search website" feature highly irritating, but this is a personal preference. However, I find it completely asinine that this behavior is forced "on" whether wanted or not. It surprises me to no end that anyone could actually argue against this with a straight face. My reasoning and refutations for arguments against: 1) It is completely obvious that this feature is a big problem for many people, either because it is irritating or because it is a security risk. This alone should be reason enough to make it optional, if not off by default. 2) The argument that adding another option to a configuration menu is unsound. First of all, there exists plenty of unused space in the Web Behavior menu to the right of "Change cursor over links" and the options below it. Even if this was not the case, this problem is controversial enough that the option should be added even if it requires enlarging the window, or even completely redesigning it. Further, there are a number of options that already exist which are almost certainly less important, such as the "Maximum completions" bar, which could be completely removed since a combobox already exists which controls this behavior. 3) Ignoring the many requests to make this feature optional due to the user's background being from Microsoft Windows, or using Mozilla, is little more than elitism. The argument that this is the default behavior in Linux is debatable at best. The web browser is not a text editor, and the cursor is not visible unless it is in a text box. With the middle-paste-is-unix reasoning, middle pasting in the clock on the lower right should change the time to whatever is in the clipboard (even if the clipboard stores a password or a doctoral thesis--who cares, they middle clicked it). How many parts of KDE really assume that you want to paste something? Not the desktop. Not any of the icons. Not the KDE menu. Not the taskbar. Why random blank areas in a website? 4) If there is a problem implementing the middle-click-to-scroll feature, fine, it can wait. 5) Suggestions like "rip out your middle mouse wheel" are indicative of the level logic being used to defend forcing this feature to on. Why not suggest that the user buy new hardware for every related problem? KDE too slow? Don't attempt to optimize its performance -- tell them to buy a faster computer. Volume control defaults to almost "mute" on KDE startup? Don't correct the problem -- Tell the user to just keep their system running 24/7, or to buy an amplifier powerful enough so that they can hear it anyway. Many people do like the feature in question., and that's fine. Do not assume that because you like a feature, everyone else should be forced to use Konqueror as you do, especially if a large number of people find it about as useful as an F-key macro to "rm -rf /"
I agree with Charles Burns and the many others who feel this feature/nuisance should be optional and defaulted to off at least. I know I've had trouble many times with pasting a large amount of text into the URL from some non-URL source. Especially with the 2 clipboards that X/KDE have, its very easy to have selected something none URL and then accidently paste it when you went to middle click on a link. I love being able to middle click to open a new window, but I find myself using control+left click more and more to keep from having the undesired behavior pop up. I too can wait on the middle click scrolling feature. Heck, its only useful to me when I have to scroll left/right on a improperly designed webpage, but the current paste from anywhere behavior I much want to see gone, or option/off by default.
It's been a while since this "middle mouse paste" flame had any more wind added: I'm still not using konqueror, except for when the easy to get nightly build of firefox doesn't work, in which case I use... opera... these issues are still plaguing KDE: 1. middle mouse clicks now pop up "malformed URL" dialogs, and make an annoying sound. -- averages about twice per page view, untill it's in my short term memory that I'm using a broken browser. and then I get another browser working. Please just make it do nothing!!! at least i won't post so much to the list if that were the case... It's passively annoying to not have autoscroll... but konqeuror is ACTIVELY annoying when trying to simply navigate a page! 2. wakky filemanager/content browser interaction but that's another issue --- More rant to express the pain of the plenthora of users who just go back to windows: ----- middle mouse clicks now pop up "malformed URL" dialogs, and make an annoying sound. This is an improvement over previous behavior, except.. Middle mouse button (or scroll wheel) == navigation button for practically every other system. I will not buy a laptop without 3 mouse buttons because of this. (I just got one that has it, i might trade it for a way lighter and faster one with a wireless mouse.. but that's so I can trade it again for a 3 mouse button one)
This bug is not even an issue anymore. In HEAD if you select non-URL text, and middle click, it prompts you with "Do you want to search the internet for "Foo"?, and a do not ask me this again checkbox. If you click yes, it searches Google for the text. if you click no, it does nothing. If you check the box and then click no, it will do nothing and *never ask you that again*, it will always do nothing. So everyone has what they want, at least from what I have been reading above. You can still middle click + paste URLs to navigate them, you can still middle click + search, you will never "accidentally submit your credit card number to Google" because you are prompted, and if you don't like middle click + search at all you can completely disable it. So if everyone is happy, can this bug be closed now?
Yes, it seems like the bug can be closed!
I'm compiling 3.3 alpha1 now. I hope it's fixed. It probably can be closed, it'll be reopened if there are problems. now, may I direct your attention to bug: we also need to check up on the middle mouse click on tab bug. Bug 48417 might really need our attention. I think I might have been having this bug confused with the middle click doesn't close tab bug... this bug looks interesting, as it would be a system wide setting: Bug 78571:
What do you mean by head? is that after kde 3.3alpha1? or is that kde 3.2.3 material? I don't see how to disable the loading of a new url in kde 3.3 alpha1... so I'm not seeing how it's fixed.. *********** middle click is PASTE, NOT LOAD !! in TEXT AREAS and middle click can be LOAD on toolbars and icons/designated areas and middle click can be NOTHING, or NAVIGATE in content areas. *********** Most of my friends have already switched to xfce4... I'm just looking for the best file manager, and best taskbar... well.. and best control pannel.. with acceptable behavior... Kicker is pretty high up on the good list, and konqueror does many weird things with URL's.. so it's kinda fuzzy, and kde's control pannel is really really good... and I gotta love spell checking in the web browser...
Do NOT close this bug. This bug is NOT fixed. We don't want _any_ middle-click pasting whatsoever. Autoscroll is needed. And that search thing when highlighting has been around for ages, and it's just stupid.
I'm sure that maxo doesn't care what you do with your system and the pasting... and I'll shutup if I can just turn it off easily. I think I don't understand what you mean by HEAD... and I don't just want middle-click pasting to do nothing, i NEED it to do nothing. I've been planning/proceeding to make kde be the desktop environment for a public cyber cafe, where people who need accessability features come to use the internet. and people with broken computers, who can be sold on Linux...and KDE I know that kde just does not work for these people, because if this problem.. and I really hope that it's fixed. I do actually want to get rid of firefox... just because it could be redundant if we actually had all the usability of mozilla. Oh, if I figure out file actions, I could make it load firefox instead... which would be not as unexpected...
I think the fix is the typical case of a configuration option added because a usability choice could not be made. I still think that my proposed solution that retained both features would have been better but I am ok for closing the bug.
> I think the fix is the typical case of a configuration option added > because a usability choice could not be made. What's so complicated about it? I understand that some people like it, hey you can say that for almost anything, but it just shouldn't be implemented the way it is. It's really annoying to load some web page because you missed the link you wanted to right click or the (multi)line edit you wanted to paste to. Notice it's even possible to load urls by middle clicking tabs, so it's not like this feature would be completely removed! Only unavailable when no tabs are present. Anyway why not simply allow middle click in "Location:", right before the address bar? Should be possible and I guess everybody would be happy. J.A.
> What's so complicated about it? I understand that some people like it, hey you > can say that for almost anything, but it just shouldn't be implemented the > way it is. It's really annoying to load some web page because you missed the > link you wanted to right click or the (multi)line edit you wanted to paste > to. If it were like this, it weren't really that bad. However because many webpages have stylesheets and a stylesheet that is loaded *CHANGES FONTS* and therefore *MOVES ALL LINKS*, this mis-feature will happen for everybody who uses the MMB to open new tabs. I still don't get why such a feature would need claim the full browser window.
Why not just make it configurable as per: ------- Additional Comment #6 From Per Winkvist 2002-10-11 16:02 ------- Created an attachment (id=190) Patch for enable/disable mmb paste in khtml ------- Additional Comment #7 From Per Winkvist 2002-10-11 16:03 ------- Created an attachment (id=191) Patch for add mmb paste option in kcontrol ? The code is already written and would solve this usability problem for many (including myself).
For those that are using KDE 3.2 or higher there is another way to disable the "search on mmb feature". Simply set the "Default Search Engine" to "None" in the web shortcuts config dialog. Searching Google is not hard coded despite what is stated in a previous comment nor does one type gg://blah to search on google which btw is completely wrong and won't work as expected. The proper syntax is either "gg:blah" or "gg blah" based on the config setting in the same config dialog. Anyways, you can prevent accidental search this way, but not opening of a new URL if the pasted text is a valid URL... BTW the purpose of the "default search engine" is to allow you to quickly search for non-URL words or phrases by simply typing them into ALT+F2 or konqueror's location bar...
On Tuesday 08 June 2004 10:21, Clarence Dang wrote: > > Hi, > > http://bugs.kde.org/show_bug.cgi?id=44931 > > May I take the action I've proposed in Comment #70 i.e. apply Per Winkvist's > patch to make the behaviour configurable? [*] This would increase usability > (at least for a fair number of users) and resolve the 14th most hated bug in > KDE. > > Please CC replies to me as I'm not subscribed or apply the patch yourself. > > Thanks, > Clarence > > * I'll update the patch if neccessary since it's 2 years old. The problem is > that I wrote another patch a week ago before realising that someone else had > already written one. The code is almost the same. The added configuration item sounds good to me, I see no way to "improve the feature so that no configuration is needed". Either MMB pastes or it doesn't. But I guess the whole debate continues on whether the feature should be on or off by default... On one hand it's an advanced feature so it's ok if people have to turn it on, on the other hand it used to be enabled so the change in behavior might make people think it's broken in the next release... Let's just say I'm surprised that the patch deactivates MMB-pasting by default (but if everyone is okay with that, I'm not objecting). I'm rather among the ones who never really used MMB to paste, and only activated it by mistake.
Am Dienstag 08 Juni 2004 17:12 schrieb David Faure: > [...] it used to be enabled so the > change in behavior might make people think it's broken in the next > release... Indeed. What I hate most about KDE version transitions is the changing of defaults. That already made me report bogus regressions on kmail. > Let's just say I'm surprised that the patch deactivates MMB-pasting by > default [...] Agreed. I fear that defaulting to off will make it virtually nonexistent for most users. That only raises the pressure from some self proclaimed usabililty experts to remove it alltogether during the next "reducing clutter" operation because "it is a feature not used by anybody". mfg Leo
> > Let's just say I'm surprised that the patch deactivates MMB-pasting by > > default [...] > > Agreed. I fear that defaulting to off will make it virtually nonexistent > for most users. That only raises the pressure from some self proclaimed > usabililty experts to remove it alltogether during the next "reducing > clutter" operation because "it is a feature not used by anybody". Bulshit. There *is* a usability problem here, even a accessibility one. This feature *does* get in the way of many users, therefore the bug reports and votes. If you cannot see that read the posts. For the record, I use mmb to paste text all the time, I kept using this accidently in the browser all the time and not once did I suspect what was going on. Find out what it was on bugs.kde.org. And yet I do agree with you "defaulting to off will make it virtually nonexistent for most users", it would be nice if a compromise could be achieved, or some alternative non-intrusive solution. However, given the current state of affairs, if one has to choose simply between having it on or off, the decision should be pretty simple really. It gets way to much in the way of users. ------------------- SUGGESTION: ------------------- You can already: - drag and drop urls on konqueror tabs - drag and drop urls on "Location" (behind konqueror address bar) - use mmb on konqueror tabs **It's inconsistent not to allow mmb on "Location".** If we add that, with this 4 alternatives, I think we'd have a pretty good compromise. Comments? J.A.
I can't have middle mouse button on tabs load a url... I'm used to middle mouse clicking to close tabs.. however, middle mouse clicking on tabs to open a url is a better default operation than closing tabs... so I won't fight for middle mouse button closing tabs by default.. but I NEED the option to do so for me to use konqueror. If middle mouse clicking gets fixed, and there is a mouse operated autoscroll (I just love the shift up/down arrow) and kde somehow has it's wakky non distint web and file browing.. then I will use it, and drop mozilla firefox even!!! I just need a couple features that will make it be usable for me. right now, I basically only use firefox.. and.. i guess konqueror because kmail has konqueror as it's default browser.. I gotta figure out how to change that... anyway.. I so want to use konqueror, it's not funny. If I use konqueror, i end up having a browser session with 18 trillion tabs open, and it's really hard to tell which tab i'm currently using (I think I'm using the default theme) and I have to navigate all the way over to the little [X] window.. in firefox, I middle mouse click on a tab, and it goes away.. (note, *********** You can already: - drag and drop urls on konqueror tabs - drag and drop urls on "Location" (behind konqueror address bar) - use mmb on konqueror tabs **It's inconsistent not to allow mmb on "Location".** If we add that, with this 4 alternatives, I think we'd have a pretty good compromise. Comments? J.A.
CVS commit by dang: Make MMB-in-konqueror-view-pastes configurable Part 1/2. This is an update of Per Winkvist's patch. CCMAIL:44931@bugs.kde.org M +7 -0 khtml_part.cpp 1.1004 M +10 -0 khtml_settings.cc 1.103 M +1 -0 khtml_settings.h 1.39 M +1 -0 khtmlpart_p.h 1.54 --- kdelibs/khtml/khtml_part.cpp #1.1003:1.1004 @@ -351,4 +351,5 @@ void KHTMLPart::init( KHTMLView *view, G // set the default java(script) flags according to the current host. + d->m_bOpenMiddleClick = d->m_settings->isOpenMiddleClickEnabled(); d->m_bBackRightClick = d->m_settings->isBackRightClickEnabled(); d->m_bJScriptEnabled = d->m_settings->isJavaScriptEnabled(); @@ -5116,4 +5117,5 @@ void KHTMLPart::reparseConfiguration() d->m_doc->docLoader()->setShowAnimations( settings->showAnimations() ); + d->m_bOpenMiddleClick = settings->isOpenMiddleClickEnabled(); d->m_bBackRightClick = settings->isBackRightClickEnabled(); d->m_bJScriptEnabled = settings->isJavaScriptEnabled(m_url.host()); @@ -5789,8 +5791,13 @@ void KHTMLPart::khtmlMouseReleaseEvent( #ifndef QT_NO_CLIPBOARD if ((d->m_guiProfile == BrowserViewGUI) && (_mouse->button() == MidButton) && (event->url().isNull())) { + kdDebug( 6050 ) << "KHTMLPart::khtmlMouseReleaseEvent() MMB shouldOpen=" + << d->m_bOpenMiddleClick << endl; + + if (d->m_bOpenMiddleClick) { KHTMLPart *p = this; while (p->parentPart()) p = p->parentPart(); p->d->m_extension->pasteRequest(); } + } #endif --- kdelibs/khtml/khtml_settings.cc #1.102:1.103 @@ -65,4 +65,5 @@ class KHTMLSettingsPrivate public: bool m_bChangeCursor : 1; + bool m_bOpenMiddleClick : 1; bool m_bBackRightClick : 1; bool m_underlineLink : 1; @@ -291,4 +292,8 @@ void KHTMLSettings::init( KConfig * conf { config->setGroup( "MainView Settings" ); + + if ( reset || config->hasKey( "OpenMiddleClick" ) ) + d->m_bOpenMiddleClick = config->readBoolEntry( "OpenMiddleClick", true ); + if ( reset || config->hasKey( "BackRightClick" ) ) d->m_bBackRightClick = config->readBoolEntry( "BackRightClick", false ); @@ -597,4 +602,9 @@ static const KPerDomainSettings &lookup_ } +bool KHTMLSettings::isOpenMiddleClickEnabled() +{ + return d->m_bOpenMiddleClick; +} + bool KHTMLSettings::isBackRightClickEnabled() { --- kdelibs/khtml/khtml_settings.h #1.38:1.39 @@ -151,4 +151,5 @@ public: bool autoLoadImages() const; + bool isOpenMiddleClickEnabled(); bool isBackRightClickEnabled(); --- kdelibs/khtml/khtmlpart_p.h #1.53:1.54 @@ -246,4 +246,5 @@ public: KLibrary *m_kjs_lib; int m_runningScripts; + bool m_bOpenMiddleClick :1; bool m_bBackRightClick :1; bool m_bJScriptEnabled :1;
CVS commit by dang: Make MMB-in-konqueror-view-pastes configurable Part 2/2. This is an update of Per Winkvist's patch. The behaviour defaults to on for compat for the time being (I will later propose a patch that keeps it on for existing settings but for new users, off by default). CCMAIL:44931@bugs.kde.org M +18 -8 htmlopts.cpp 1.85 M +1 -0 htmlopts.h 1.34 --- kdebase/kcontrol/konqhtml/htmlopts.cpp #1.84:1.85 @@ -97,10 +97,9 @@ KMiscHTMLOptions::KMiscHTMLOptions(KConf row++; - // Misc + // Mouse behavior - m_cbCursor = new QCheckBox(i18n("Chan&ge cursor over links"), this); - lay->addMultiCellWidget(m_cbCursor, row, row, 0, 1); - row++; + QVGroupBox *bgMouse = new QVGroupBox( i18n("Mouse Beha&vior"), this ); + m_cbCursor = new QCheckBox(i18n("Chan&ge cursor over links"), bgMouse ); QWhatsThis::add( m_cbCursor, i18n("If this option is set, the shape of the cursor will change " "(usually to a hand) if it is moved over a hyperlink.") ); @@ -108,12 +106,21 @@ KMiscHTMLOptions::KMiscHTMLOptions(KConf connect(m_cbCursor, SIGNAL(clicked()), this, SLOT(slotChanged())); - m_pBackRightClick = new QCheckBox( i18n( "Right click goes &back in history" ), this ); + m_pOpenMiddleClick = new QCheckBox( i18n ("M&iddle click opens URL in selection" ), bgMouse ); + QWhatsThis::add( m_pOpenMiddleClick, i18n ( + "If this box is checked, you can open the URL in the selection by middle clicking on a " + "Konqueror view." ) ); + connect(m_pOpenMiddleClick, SIGNAL(clicked()), this, SLOT(slotChanged())); + + m_pBackRightClick = new QCheckBox( i18n( "Right click goes &back in history" ), bgMouse ); QWhatsThis::add( m_pBackRightClick, i18n( "If this box is checked, you can go back in history by right clicking on a Konqueror view. " "To access the context menu, press the right mouse button and move." ) ); - lay->addMultiCellWidget( m_pBackRightClick, row, row, 0, 1); - row++; connect(m_pBackRightClick, SIGNAL(clicked()), this, SLOT(slotChanged())); + lay->addMultiCellWidget( bgMouse, row, row, 0, 1 ); + row++; + + // Misc + m_pAutoLoadImagesCheckBox = new QCheckBox( i18n( "A&utomatically load images"), this ); QWhatsThis::add( m_pAutoLoadImagesCheckBox, i18n( "If this box is checked, Konqueror will automatically load any images that are embedded in a web page. Otherwise, it will display placeholders for the images, and you can then manually load the images by clicking on the image button.<br>Unless you have a very slow network connection, you will probably want to check this box to enhance your browsing experience." ) ); @@ -194,4 +201,5 @@ void KMiscHTMLOptions::load() // *** load *** SET_GROUP( "MainView Settings" ); + bool bOpenMiddleClick = READ_BOOL( "OpenMiddleClick", true ); bool bBackRightClick = READ_BOOL( "BackRightClick", false ); SET_GROUP( "HTML Settings" ); @@ -208,4 +216,5 @@ void KMiscHTMLOptions::load() m_pAutoLoadImagesCheckBox->setChecked( bAutoLoadImages ); m_pAutoRedirectCheckBox->setChecked( bAutoRedirect ); + m_pOpenMiddleClick->setChecked( bOpenMiddleClick ); m_pBackRightClick->setChecked( bBackRightClick ); @@ -258,4 +267,5 @@ void KMiscHTMLOptions::save() { m_pConfig->setGroup( "MainView Settings" ); + m_pConfig->writeEntry( "OpenMiddleClick", m_pOpenMiddleClick->isChecked() ); m_pConfig->writeEntry( "BackRightClick", m_pBackRightClick->isChecked() ); m_pConfig->setGroup( "HTML Settings" ); --- kdebase/kcontrol/konqhtml/htmlopts.h #1.33:1.34 @@ -55,4 +55,5 @@ private: QCheckBox* m_pAutoLoadImagesCheckBox; QCheckBox* m_pAutoRedirectCheckBox; + QCheckBox* m_pOpenMiddleClick; QCheckBox* m_pBackRightClick; QCheckBox* m_pShowMMBInTabs;
--- Jorge Adriano <jadrian@mat.uc.pt> wrote: > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching > someone who is. > > http://bugs.kde.org/show_bug.cgi?id=44931 > > > > > ------- Additional Comments From jadrian mat uc pt > 2004-06-08 22:30 ------- > > > Let's just say I'm surprised that the patch > deactivates MMB-pasting by > > > default [...] > > > > Agreed. I fear that defaulting to off will make it > virtually nonexistent > > for most users. That only raises the pressure from > some self proclaimed > > usability experts to remove it all together during > the next "reducing > > clutter" operation because "it is a feature not > used by anybody". > > Bullshit. > > There *is* a usability problem here, even a > accessibility one. This feature > *does* get in the way of many users, therefore the > bug reports and votes. > If you cannot see that read the posts. > There are actually a few accessibility issues. The most obvious one involves users who have problems with mobility. In particular this behavior could be a source of great frustration for people who have some type of limited fine-grain motor control and/or muscle twitching. Either of these condition could make aiming the pointer on the intended text nearly impossible while constantly having to go back to the page they were on after konqueror had loaded google each time they accidentally clicked on some text. This sudden and unexpected page change could easily confuse people those who have perceptional disabilities leading headaches in some cases. This "feature" has probably and will continue to turn off a number people with disabilities from konqueror/KDE and possibly linux itself. Turning it off will make konqueror more accessible to those with minor disabilities by default. The mmb search option should continue to be available to those want to use it. -Ian A person with autism and a college student studying computer science and usability/accessibility Ramapo College of NJ > For the record, I use mmb to paste text all the > time, I kept using this > accidentally in the browser all the time and not once > did I suspect what was > going on. Find out what it was on bugs.kde.org. > > And yet I do agree with you "defaulting to off will > make it virtually > nonexistent for most users", it would be nice if a > compromise could be > achieved, or some alternative non-intrusive > solution. However, given the > current state of affairs, if one has to choose > simply between having it on or > off, the decision should be pretty simple really. It > gets way to much in the > way of users. > > ------------------- > SUGGESTION: > ------------------- > You can already: > > - drag and drop urls on konqueror tabs > - drag and drop urls on "Location" (behind konqueror > address bar) > - use mmb on konqueror tabs > > **It's inconsistent not to allow mmb on > "Location".** > > If we add that, with this 4 alternatives, I think > we'd have a pretty good > compromise. > > Comments? > J.A. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Just the other day, I was surfing around, and tried to find the tab that I was looking at... I couldn't find it! And then I realized that I might have accidentally middle mouse clicked on my tab, and it has a "valid" (*cough*) URL, and made me loose the page that I had spent quite a bit of time searching for.
This bug should NOT considered fix until it is configurable to disable ALL middle mouse button actions on non-editable areas. If you can take away non-URL text, why don't make it not do anything for any text, including URL? I often have URLs in my clipboard, and even mmb URL paste is not a good idea. Just make it configurable: Enable: Do whatever you want Disable: No action whatsoever. Zilch. Nil. Nada. Zero. Even for URL. Everyone will be happy.
I've already made it configurable in CVS. It's just that I haven't had time to write a kconf_update script to migrate settings so that I can default it to off and then close the bug report. On Thu, 15 Jul 2004 04:46 pm, wy2lam@yahoo.com wrote: > This bug should NOT considered fix until it is configurable to disable ALL > middle mouse button actions on non-editable areas. > > If you can take away non-URL text, why don't make it not do anything for > any text, including URL? I often have URLs in my clipboard, and even mmb > URL paste is not a good idea. > > Just make it configurable: > Enable: Do whatever you want > Disable: No action whatsoever. Zilch. Nil. Nada. Zero. Even for URL. > > Everyone will be happy.
Marking as "Junior Job": Your mission should you have time to accept it is to write a kconf_update to script to allow this option to default to off (as per comment #81) and to make the existing option affect FTP. Should you be caught or killed, there is no secretary anyway. This message cannot self destruct in 15 seconds but it will be "bug history" (get the pun? :)).
re comment #82 : What if it was left on by default?
So, the Junior job should also look into, making the middle mouse button not open URL's, except for on the Go button, and close a tab when that tab is middle clicked on. and possibly autoscroll... ;) (of which there is already a neat, undiscoverable feature that is better than autoscroll in some ways, by holding shift and an arrow key... but that requires two hands and a keyboard.. so it doesn't work for accessability-feature-needing people. *editorial* Konqueror rocks because of it's inline spell checking, If the middle clicking on tabs didn't open the contents of my clipboard, I'd be using it a lot more... and if tabs closed when middle clicked on, because presently, it's like navigating a maze 30 times to close 30 tabs... I would use konqueror even without autoscroll, because spell checking has made it to my required feature list. good job Konqueror developers
On Sat, 11 Sep 2004 07:04 am, Aaron Peterson wrote: > So, the Junior job should also look into, > making the middle mouse button not open URL's, except for on the Go button, > But you can already (but not for FTP). "Go to Configure Konqueror ... / Web Behavior / Mouse Behavior / Middle click opens URL in selection" and uncheck it. I just want to see this option default to off because it's just too confusing and unexpected but this would require the writing of a settings migration script. > and close a tab when that tab is middle clicked on. > You'd have a better chance of this getting implemented if you filed a separate wishlist.
On Sat, 11 Sep 2004 02:49 am, maxoshea@gmail.com wrote: > ------- Additional Comments From maxoshea gmail com 2004-09-10 18:49 > What if it was left on by default? It will continue to drive people crazy and they just can't sleep.
>> ------- Additional Comments From maxoshea gmail com 2004-09-10 18:49 >> What if it was left on by default? > >It will continue to drive people crazy and they just can't sleep. Personally, I think middle-mouse button actions should be disabled by default, before any new users get used to this action being enabled. So by default, middle-mouse-clicking has to be off.
I am for solution from #80. so my suggestion: 'Middle click opens URL in selection' should be renamed 'mc goes to URL/searches for text in selection' and if activated, it should work regardless which KPart view is open (maybe not possible, but atleast in local filesystem and image view => http://bugs.kde.org/show_bug.cgi?id=96692) and if turned off, do not a thing. IMHO this would make everybody happy; my personal preference is to have it on and it is a very useful feature so I think new users _should_ stumble about it and use it, or turn it off. But then again, that's just my 2 cent.
> ------- Additional Comments From mpartap gmx net 2005-01-10 10:27 ------- > I am for solution from #80. so my suggestion: 'Middle click opens URL in > selection' should be renamed 'mc goes to URL/searches for text in > selection' and if activated, it should work regardless which KPart view is > open (maybe not possible, but atleast in local filesystem and image view => > http://bugs.kde.org/show_bug.cgi?id=96692) and if turned off, do not a > thing. IMHO this would make everybody happy; my personal preference is to > have it on and it is a very useful feature so I think new users _should_ > stumble about it and use it, or turn it off. But then again, that's just my > 2 cent. Hi there! I've been using Linux since RedHat 5.2, so I wouldn't classify as a newbie. I've stumbled upon this plenty of times, all I could see was that suddenly my konqueror had some random search url. Call me stupid, but I didn't figure out what was going on until I saw someone complaining about this behaviour. It just didn't even cross my mind. Expecting user to accidently use it, understand what's going on, and either like it or know how to change it, IMO is to much wishful thinking. Besides all that, if we're expecting users to find out about it and eventually understand it, simply by accidently using it, we're acknowledging that it's quite common for users to use it accidently! That by itself sugests it is a bad feature in terms of usability. And indeed, I know I keep using it accidently, just miss a middle click on a link, or on a line-edit. I have no problem with obscure (in the sense that they are not easy to find out about) features, as long as they are useful and ***do not have serious drawbacks in terms of usability***, that is the difference between, say middle mouse click to paste text, and this. Now something I do wonder is why doesn't the "Location: "area, right before the adress bar, accepts middle click to paste urls (eventualy searches), because it does accept them by drag and drop. That is inconsistent and should be fixed not matter what the decision about the rest is. With that fixed, seems to me like we would have a sensible default, everybody would have a place to middle click, and it would even work with other kparts on! And please, if you're thinking that is to god damn small, many links are much harder to middle click, at least missing "location" won't result in some other random behaviour. Ok, I think I've talked to much about this bug, and I'll stay quiet unless I'm directy adressed by someone. If you think if any of what I said doesn't make sense, do argue. Don't just say "I don't agree". Cheers!
The option to disable the behaviour that the reporter of the problem was complaining about is already implemented ("Go to Configure Konqueror ... / Web Behavior / Mouse Behavior / Middle click opens URL in selection"). Taking that into account, shouldn't this bug be closed and separate ones opened for each issue that people still have? (e.g. default to off, closing tab when middle-clicking in it, autoscrolling, etc.). This bug has so many comments discussing so many different things that it becomes difficult to manage.
On Tue, 11 Jan 2005 03:24 am, Ismael Juma wrote: > The option to disable the behaviour that the reporter of the > problem was complaining about is already implemented ("Go to Configure > Konqueror ... / Web Behavior / Mouse Behavior / Middle click opens URL in > selection"). Option doesn't work for FTP IIRC - needs to be fixed. > Taking that into account, shouldn't this bug be closed and > separate ones opened for each issue that people still have? (e.g. default > to off, closing tab when middle-clicking in it, autoscrolling, etc.). This > bug has so many comments discussing so many different things that it > becomes difficult to manage. I agree but you would have the not so fun job of moving around votes and CCs.
Why not just leave this as it is, and on by default, but add in a dialogue box when first used that asks if the user really wanted to do that - just like the one that asks if you really wanted to search when whatever was pasted isn't a URL. That way it's still possible for new users to discover this feature, but won't upset them when they do. It would also then be easier to turn off without having to know where to look for the option. I can't really see how anybody would find that behaviour problematic.
I am not very happy to be asked for many things when starting using features... I think that an easily-found configuration would do.
This bug report is suffering from long thread syndrome. On Sunday 30 October 2005 21:52, Pavel Simerda wrote: > I am not very happy to be asked for many things when starting using > features... > > I think that an easily-found configuration would do. There is an option already: Untick "Settings / Configure Konqueror... / Web Behavior / Middle click opens URL in selection". Having said that, someone hijacked it so if you untick it, you get an IE-style scrolling thing if you middle mouse click and it doesn't turn off if you middle click again in the wrong place. I will file a separate bug report for that. The bug is still open to change the option to off by default and migrate the existing users' setting and fix FTP.
Ok... I didn't explore so much. I just wanted to say that I don't like the idea of programs asking me questions on first startup.
"Having said that, someone hijacked it so if you untick it, you get an IE-style scrolling thing if you middle mouse click and it doesn't turn off if you middle click again in the wrong place. I will file a separate bug report for that." That's definitely a candidate for removal, if you ask me. Anyways, I have a seperate but related middle-click question/issue: When pasting a URL w/ embedded CR/LF, Konqueror will receive the correct URL without the embedded CR/LF. This feature I love. But who is doing it? Klipper before Konqui gets it, or Konqui after receiving from Klipper? I bring this up because I noticed when utilizing Klipper actions, to select a URL broken across two lines, the URL received by Konqui via Klipper (when choosing "Open with Konqueror") will now have a %0A instead of the original CR/LF stripped. Who's most likely responsible, Konqueror or Klipper?
There has been nothing really new for more than one and a half year. What about closing this bug? In case there are still minor issues open related to this filing a new bug report is still possible. I don't think this bug in its current form will result in any further code changes.
The problem which I stated in Comment #1 still exists. If you have a URL selected in Klipper and you center button click anywhere in the Konqueror window, that URL will be opened. I still feel that this is a bug. So, if we feel that this isn't a bug, then the bug should be closed.
See comment #94. I'll implement it within a year if no one else does.
I suggested to restrict the current behaviour (middle click open current clipboard url) to a specific area of konqueror, for example the location bar. You do not middle-click here by mistake, and you still get the convenience that a middle click opens an URL directly. I still think this is a good idea that keeps the good of both worlds, without a need for an additional configuration option. Or you could have the configuration option as "rectrick middle click opens url to location bar".
I personally use middle click to paste URLs all the time, and I think its the only way to go. I would think that the suggestion above to restrict the middle click behavior to a very small area of the browser has grave usability issues, namely Fitts law. I don't think that the hassle of occasionally missing a link when middle clicking to open a new tab (and then just hitting STOP, Back and trying again) is worth the much more useful ability (IMHO) to paste a URL anywhere I can point my mouse at. Also, middle click pasting to the location bar is already supported through the time honored mechanism of PRIMARY selection, and overloading that with "also clear anything previously there and activate the URL" would cause much confusion and mayhem :-)
To #98: As stated in #94 there is already an option to turn that behaviour off. Also many suggestion have already been implemented (e.g. restictions to URLs and so on). It is also comparable to certain other Drag&Drop behaviours in other programs. To #100: The restrictions of the middle-click-URL problem to specific areas very likely will not be implemented. This behaviour exists for other browsers as well and I known lots of people using it a lot (including myself). You have the option to turn it off and most of the users are happy with its current form. To #99: I don't think it is hijacked, but probably another behaviour configurable somewhere, which is a layer below and gets activated in case you turn off the higher layer :-) Please open a new bug report for this if necessary. If there are other open aspects please file specific bug reports for these (refer to this bug in the description text if necessary). Please do not reopen this one. Closed.