145011 - "copy" and "copy link" screwed up

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Graeme]

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.

Comment 1

[Paul Wyskoczka]

qa --> [e-mail]

Comment 2

[R.K.Aa.]

dup of bug 143607?

Comment 3

[Graeme]

This is not a repeat of 143607.

143607 - they believe copy link is screwed.

145011 - I believe "copy" is screwed.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Michael Gabriel]

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

Comment 6

[Graeme]

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.

Comment 7

[Kenneth Herron]

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

[Graeme]

***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!

Comment 9

[Kenneth Herron]

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.

Comment 10

[Wayne Mery (:wsmwk)]

dupe of bug 98984?

reporter address is dead