"paste" of url into content area should load that url

VERIFIED FIXED in M15

Status

defect
P3
normal
VERIFIED FIXED
20 years ago
15 years ago

People

(Reporter: akkzilla, Assigned: akkzilla)

Tracking

Trunk
x86
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Assignee

Description

20 years ago
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.
Assignee

Updated

20 years ago
Target Milestone: M12
Assignee

Comment 1

20 years ago
Marking M12 because it seems at least equal in importance to 6085, which is
currently marked M12.

Updated

20 years ago
Target Milestone: M12 → M14

Comment 2

20 years ago
I think this should be pushed to post-beta. It is a very obscure
(undocumented?), and Unix-only feature. moving to m14

Comment 3

20 years ago
I really like this feature.  It is important but
I agree with trudelle this is not a beta requirement.

Comment 4

20 years ago
*** Bug 10492 has been marked as a duplicate of this bug. ***

Comment 5

20 years ago
mass moving m14 bugs to m15
Assignee

Comment 6

20 years ago
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.

Updated

20 years ago
Assignee: pavlov → law

Comment 7

20 years ago
Assigning to law, per akkana/don's comments.
Pavlov, steal this back if you are looking at it.

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 8

20 years ago
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."

Updated

20 years ago
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.)
Assignee

Updated

20 years ago
Assignee: law → akkana
Status: ASSIGNED → NEW
Assignee

Comment 10

20 years ago
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 ...
Assignee

Comment 11

20 years ago

Comment 12

20 years ago
I tried mouse-wheel scrolling with this patch, and it worked fine, on linux. On
windows, most users will expect the middle mouse click to bring up the special
windows mouse-scroll ui, and will be confused when their clipboard data gets
loaded by the browser (i guess it would result in an internet search or dns
error).

Middle-button pasting works fine as well, but, if there's nothing in the
clipboard, I get this error:
->>>>>>>>>>>>>> Read Clipboard from memory
JavaScript Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE) [nsITransferable.getTransferData]"
nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://navigator/content/navigator.js :: readFromClipboard :: line 1238"
data: no]
Assignee

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Assignee

Comment 13

20 years ago
Fix checked in.  Hooray!

Comment 14

20 years ago
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. :-)

Comment 16

20 years ago
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)
Assignee

Comment 17

20 years ago
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. :-(

Comment 18

20 years ago
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 → ---
Assignee

Comment 19

20 years ago
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
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Keywords: 4xp
Summary: [4.xP] "paste" of url into content area should load that url → "paste" of url into content area should load that url

Comment 20

20 years ago
Updating QA Contact.
Component: Browser-General → Editor
QA Contact: leger → sujay
Assignee

Comment 21

20 years ago
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
Assignee

Comment 22

20 years ago
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.
Assignee

Comment 23

20 years ago
Marking fixed.  If there are other cases where this doesn't work, please file
them separately.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED

Comment 24

20 years ago
updating qa_contact.
QA Contact: sujay → elig

Comment 25

19 years ago
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

Comment 26

19 years ago
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?
Assignee

Comment 27

19 years ago
Indeed, this has regressed.  Pavlov changed the clipboard API last night (to
support X CLIPBOARD selection), and I bet that's related.
Assignee

Comment 28

19 years ago
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.