Copy Link Location does no X copy



MailNews: Message Display
17 years ago
10 years ago


(Reporter: BenB, Assigned: (not reading, please use instead))


Firefox Tracking Flags

(Not tracked)




17 years ago
1. Open msg with URL
2. Right-click on recognized URL, select Copy Link Location
3. Switch to Emacs, middle-click

Expected result:
URL is pasted into Emacs

Actual result:
Previous content of X clipboard is pasted, i.e. URL is not pasted.

Comment 1

16 years ago
Testing with a current CVS, Linux: WFM.

Comment 2

16 years ago
Ben, can you try this again with a current build and let us know if it's still a
bug for you.  It was tried recently and was not reproducible, we may need more
steps if you still have a problem. 

Comment 3

16 years ago
I tried this today at work, interestingly enough, the problems occurs in the
full message window (when double clicking the message), but not in the preview pane.

Comment 4

16 years ago
I have noticed this same problem in the browser.  It's been happening ever since RC1

Comment 5

16 years ago
I have noticed this same problem in the browser. I use Mozilla build 2002051507
with PinBall theme on Mandrake 8.0 with kde 2.1.1 and 3.0.
This was OK for a long time and since 1.0RC1 the bug is here again.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020517

Comment 7

16 years ago
I have noticed this same problem in the browser. I use Mozilla build 2002051507
with PinBall theme on Mandrake 8.0.

Comment 8

16 years ago
Is this a dup of bug 143607?

Comment 9

16 years ago
Ok. How I feel this bug is wrong:

1. Select (highlight) any text in the browser window.
2. Right-click on a link, pick "copy link location"
3. Middle-click on some text entry box or a terminal or such...

Actual result: The highlighted piece of text is pasted.

Expected result: Location of the link is pasted. Eventually, after finishing
with pt. 2) the highlight vanishes. (it's confusing as to what is in the
clipboard - you never know if that's the highlighted text or something else.
Highlight should vanish if you select something in any X window outside mozilla
too, as the default X behavior is. (one selection at a time)

Comment 10

16 years ago
Okay... here's the reason why this doesn't work for everyone.  Some click and
hold down the button and select the copy link location menu item when hovering
over a link.  Others do a full click and the menu pops up and then they click
the copy link location.  Notice a quick blink of the menu after you select the
menu item.  I think this has something to do with it.  This is definately a bug!

Comment 11

16 years ago
I can confirm Jeff's observation in Mozilla 1.0 rc2 on an i386 Gentoo linux
system, when you click on anything in the right click pop up (most noticable in
copy link location) another menu briefly pops up and the action doesn't behave
as you would expect. This appears to all right click context menus in all windows.

This bug looks like a big step backwards as this functionality worked just fine
pre rc1. Also the briefly appearing menu is worrying as it looks like its
contending with the "copy link location" action since the action does actually
work sometimes (the link does get copied).

Comment 12

16 years ago
I believe this is a dup of bug 143607, which was fixed on trunk and branch on
2002-05-17, so it's in RC1 and RC2, but not in more recent builds.

In fact, this is working for me on yesterday's branch build on Linux. Can
someone please try to reproduce the bug on a recent build? I suspect this bug is

Comment 13

16 years ago
In response to comment 9, that could be considered to be the correct behaviour.

When you select any text, the app is supposed to claim the PRIMARY selection. 
When you middle click somewhere, the contents of the PRIMARY selection should be
inserted at the cursor.  If some other app/widget claims PRIMARY, the old text
should be deselected (you should only ever see one bit of selected text on your
screen, and that is PRIMARY).

When you use the cut and paste menu items (and copy link location, etc), the app
should be using the CLIPBOARD selection.  Selecting a bit of text on the screen
does not obliterate the CLIPBOARD selection and conversely, putting something on
the clipboard won't affect PRIMARY (so the currently selected text doesn't get
deselected).  The handling of the CLIPBOARD selection should feel just like
clipboard on windows or mac (no funny surprises).

These are the semantics defined in the ICCCM, and clarrified here:

This is how both the GTK+ and Qt widget sets handle selections (and
consequently, KDE and GNOME also act like this).

Comment 14

16 years ago
I can confirm this is fixed.

On RedHat Linux 7.2:

 - could reproduce this bug on rc2, but...
 - works on nightly build (mine is 20020521)
worskforme; not marking dup since the original issue was obviously different from 
the bug 143607 all the recent commenters are seeing. 
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.