Reproduction: 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.

Testing with a current CVS, Linux: WFM.

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.

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.

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

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

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

Is this a dup of bug 143607?

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)

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!

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).

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 fixed.

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: http://www.freedesktop.org/standards/clipboards.txt This is how both the GTK+ and Qt widget sets handle selections (and consequently, KDE and GNOME also act like this).

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.