I had thought bug 6085 covered this, but it turns out it doesn't. Middle-mouse into the content area when there's a url on the clipboard should load the url in the current window, like it does in 4.5.
Marking M12 because it seems at least equal in importance to 6085, which is currently marked M12.
I think this should be pushed to post-beta. It is a very obscure (undocumented?), and Unix-only feature. moving to m14
I really like this feature. It is important but I agree with trudelle this is not a beta requirement.
*** Bug 10492 has been marked as a duplicate of this bug. ***
mass moving m14 bugs to m15
Don says that Bill Law was planning to look into this; adding him to the cc list. Browser guys: this doesn't seem like it should be all that hard to add. My question is: if I were to add a mouse event listener on the browser window's content area, where would be the right class to add it? There doesn't seem to be an event listener there currently.
Assigning to law, per akkana/don's comments. Pavlov, steal this back if you are looking at it.
Any code would likely have to be added to mozilla/xpfe/browser/src/nsBrowserInstance.cpp. I don't know the subtleties of "event listeners." Since the content area can contain things for which you might not want this behavior (e.g., form fields) we'll have to make sure we don't intercept "pastes" aimed elsewhere. I'm not sure about the XP ramifications, also. I don't think we want middle-mouse button on Windows to necessarily "paste."
Summary: "paste" of url into content area should load that url → [4.xP] "paste" of url into content area should load that url
Why not assume that pasting an address into a window, when the Web content has focus (except into form fields and applets on the page), means the user wants to go to that address? That behaviour would solve this bug -- it would be exactly the same as in 4.x, as far as *nix users were concerned, because clicking the middle mouse button in X equals pasting anyway. And it would make it quicker for users of other platforms, too, as they wouldn't have to go through the process of (1) selecting the current address (2) pasting the new address (3) hitting Enter. The context menu item would need to be changed from `Paste' to `Paste and Go', to reflect the different behaviour. (It would still be `Paste' when focus was in a form field or applet.)
Thanks to a little help from Alecf and Pavlov, I got this working in JS. Hope to check it in tomorrow after a review. Grabbing this bug ...
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Fix checked in. Hooray!
A few days ago I posted bug 24026 which I just found out is an effect of the fix to this bug. Briefly, your fix has the effect of making paste-by-middle-mouse-button unusable for filling in forms: if you paste into a text entry field, the browser will now interpret the contents of the clipboard as an URL and transport you to some arbitrary site.
And when I suggested this, I *specifically* said `except into form fields and applets on the page' ... Come on, Akkana, do what you're told. :-)
Bug 23669 covers the problem with middle-button paste into text fields loading a page. Aside from that issue, can we make the function a little more intelligent. Eg, we shouldn't interpret something on the clipboard as an URL if it's more than a line long. Maybe the URL loader will eventually do this automatically, but if the text on the clipboard contains spaces, we should load the search function for that as search text instead of trying to load it as an URL. (NS 4.7 does all that)
I agree, it would be nice to make it smarter, and I hope to figure out how to do that in JS sometime soon (if anyone knows, please comment here or just send me the patch). But I fear we may have to turn this feature off again for M13 due to the event problems pasting into text fields. :-(
This feature still isn't working right. If you paste when your cursor is over text, it doesn't load the url, as it does in 4.x. Tested with a linux cvs build from today.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
There are various problems with it, due to the hacky workaround we've put in due to 23669. Marking a dependancy on that bug.
Status: REOPENED → NEW
Depends on: 23669
Summary: [4.xP] "paste" of url into content area should load that url → "paste" of url into content area should load that url
Updating QA Contact.
Component: Browser-General → Editor
QA Contact: leger → sujay
I'm not sure why Jan mademoved this to component editor -- it's not an editor thing (in fact, it doesn't even work in the editor). Changing component back, but I'll let Sujay decide who should be the QA contact.
Component: Editor → Browser-General
I've checked in some fixes that should make this better (alas, we're still using the hacky workaround, until the event bug is fixed). Let me know of cases where you're still seeing problems.
Marking fixed. If there are other cases where this doesn't work, please file them separately.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago → 20 years ago
Resolution: --- → FIXED
QA Contact: sujay → elig
Verified fixed in 3/28/2000 AM Linux build. Specifically: - middle-button mouse pasting a URL into the content region loads the URL - middle-button mouse pasting into a text field pasted the content into the text field. - pasting into the content region on Mac OS/Windows does nothing at all.
Status: RESOLVED → VERIFIED
On Linux build 2000.04.14.09, I can't open a URL by middle-click. This worked two days ago. Has it regressed for anyone else?
Indeed, this has regressed. Pavlov changed the clipboard API last night (to support X CLIPBOARD selection), and I bet that's related.
Talked to Pavlov (yup, he changed the API), and we have a trivial fix ready to check in whenever the tree opens. This will work again in tomorrow's build.
You need to log in before you can comment on or make changes to this bug.