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 wanted. Expected Results: copied the text i selected.
qa --> firstname.lastname@example.org
QA Contact: paw → sairuh
dup of bug 143607?
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
first possible dupe fixed. does this problem still happen to you ? if only part 2 happens , does bug 145011 cover it ?
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 right-mouse-button-menu. 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.
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?
***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: http://bugzilla.mozilla.org/show_bug.cgi?id=145011#c1 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. Graeme. ps. thanks guys for all your work on mozilla, it's a great browser!
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.