"copy" and "copy link" screwed up



UI Design
16 years ago
10 years ago


(Reporter: Graeme, Assigned: jag (Peter Annema))


Firefox Tracking Flags

(Not tracked)





16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    2002051009

Try selecting some text. Now right click on a link and select copy link. now
right click on the text and select copy. you get the link now, instead of the text.

It also happens the other way around on some pages, I believe.

Reproducible: Always
Steps to Reproduce:
1. open page. 
2. select text
3. right click on a link somewhere else, select copy link location.
4. right click on the text you selected, select "copy"
5. paste the text into a terminal . 

Actual Results:  you will get the link location stuff instead of the text you

Expected Results:  copied the text i selected.

Comment 1

16 years ago
qa --> sairuh@netscape.com
QA Contact: paw → sairuh

Comment 2

16 years ago
dup of bug 143607?

Comment 3

16 years ago
This is not a repeat of 143607.

143607 - they believe copy link is screwed.

145011 - I believe "copy" is screwed.
"all context menu operations are screwed and operate on the wrong context" is my
conclusion based on the patch in that bug....  I'm fairly certain that that
patch will fix this problem.
Depends on: 143607

Comment 5

16 years ago
first possible dupe fixed.
does this problem still happen to you ?
if only part 2 happens , does bug 145011 cover it ?

Comment 6

16 years ago
This bug is still present. I just checked it in Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.0.0) Gecko/20020529.

Again, this is what I did.

1) Select some text. A middle mouse click in an xterm pastes the text.
2) Right click on a link, and select "copy link location" . A middle mouse click
in an xterm pastes the link.
3) Right click on the text [which is still selected], and select "copy". A
middle mouse click in an xterm produces the link. It should however produce the
text, since my most recent action was "copy" from the text's

so mozilla is failing to do the "copy" from the text's context menu thingy.

this should be reproducible on any page, I'm guessing.

can't get it to produce the bug the other way round just now, so ignore that for
the moment until i can confirm it.

Comment 7

16 years ago
Linux 2002102605. I can't reproduce this. Graeme, in comment #6 you say you
could reproduce this on July 18, but you were apparently using a copy of mozilla
from May 29 at the time. Bug 143607 was fixed in June, so the fact you could
reproduce it using a build from may isn't necessarily meaningful.

Can you reproduce this with a current copy of mozilla?

Comment 8

16 years ago
***The bug is still present*** 

Here is which version of mozilla I am using for the current example of
the presence of the bug :

Mozilla 1.1

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826


Here is what happens when I follow the instructions in the bug report I
filed: (using the bug report page as an example!)

1. Left click over the text "Try selecting". It's background is now black
to show it is selected.

2. Leaving the text selected in black, right click on the link "Additional
comment ---->#1<---- from Paul Wyskoczka", and select "copy link
location" from the context menu.
3. (middle click into a terminal at this point produces :
http://bugzilla.mozilla.org/show_bug.cgi?id=145011#c1). This is good.

4. Now right click on the still selected, black backgrounded text
phrase "Try selecting". Select "copy" from it's context menu.

5. Middle click in terminal produces:


This is bad. We were expecting "Try selecting".

***Therefore the bug is still present.***

I have reproduced this on many other pages. If you are have had trouble
reproducing it, you may not have accurately followed the steps above.


ps. thanks guys for all your work on mozilla, it's a great browser!

Comment 9

16 years ago
Okay, I can reproduce this. I'm currently using solaris nightly 2002120522.

My understanding of X cut & paste is based on
<http://www.jwz.org/doc/x-cut-and-paste.html>. After going through the steps to
reproduce (and using xclipboard), it seems the highlighted text is CLIPBOARD and
the link is PRIMARY.I expect the following is happening:

1) Drag-selecting text causes it to become PRIMARY.
2) Right-clicking on a link and selecting "copy link" is apparently making the
link both CLIPBOARD and PRIMARY.
3) Right-clicking highlighted area and selecting "copy" makes it CLIPBOARD.

My interpretation of jwz's doc is that one of the following would be more
correct behavior:

* At step 2, the text highlighted in step 1 should be deemphasized since it's no
longer primary.

* At step 2, the link location shouldn't become PRIMARY. (probably not the most
preferred solution.)

* At step 3, the copy operation should make the text both CLIPBOARD and PRIMARY,
to be consistent with the copy link behavior.
Ever confirmed: true
Product: Core → Mozilla Application Suite

Comment 10

10 years ago
dupe of bug 98984?

reporter address is dead
Assignee: samir_bugzilla → jag
QA Contact: bugzilla
You need to log in before you can comment on or make changes to this bug.