96645 - Copy Link Address is unreliable

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Henri Sivonen (:hsivonen)]

Build ID: 2001082205 FizzillaCFM

Reproducible: About half of the time.

Steps to reproduce:
1) Browser for a while:
2) Use the context menu to copy a link address
3) Paste somewhere to see what's really on the clipboard.
4) Repeat steps 1 through 3 ten times.

Actual results:
Sometimes the URL is really copied to the clipboard--othertimes it isn't.

Expected results:
Expected the URL to be copied every time when the Copy Link Address context menu
item is used.

Additional information:
This is particularly annoying, when I try to paste an URL to the terminal as an
argument to wget but end up pasting garbage and the shell atteps to interpret
whatever data is on the clipborad as commands. (It could even lead to data loss.)

Comment 1

[sairuh (rarely reading bugmail)]

i also have been seeing this --on both Mac OS X and linux. i'd imagine this is
cross-platform.

blake/kathy/akkana/pavlov, do any of you know of existing bug or a similar bug
like this that has cropped up recently? "Copy Link Address" used to be "Copy
Link Location" --and i don't recall seeing this issue when using "Copy Link
Location"... could this change be the cause of this regression?

Comment 2

[Kathleen :Brade]

sounds like a focus issue to me; I haven't noticed this particular problem but I 
don't use this feature often.

Reporter: when you are doing this 10 times, are you always attempting to copy the 
same link or do you try to copy different links?  I ask because there are known 
bugs with copying some types of links.  A sample file where you see this may be 
useful.

Comment 3

[deej]

I have seen this bug also, on Mac OS 9 and Mac OS X. From my experience it
happens if the mouse drifts outside the pop-up menu. ie:

1. invoke contextual menu
2. scroll down carefully to Copy Link Address
3. paste somewhere

= Works. But:

1. invoke contextual menu
2. with the mouse button still down, move mouse to the left/right/up, outside
the region of the contextual menu
3. now make your way down to Copy Link Address
4. paste somewhere

I noticed this because my mouse is a bit gummed up and lifting it would
sometimes release the ball, causing the mouse pointer to venture outside the
contextual menu. It would sometimes take 3 or 4 shots to copy the same link
address before it would work. However, now I can reliably copy a link address as
long as I maintain control of the mouse.

Comment 4

[Alexandre Barros]

using xclipboard or gclipper ( clipboard buffers on X ) to monitor what's being
*really* copied, shows that after a couple dozen times ( when the copy yet works
) using the "Copy Link Address" option on right-button-menu, the copying simply
ceases for good... the browser needs to be shut down and restarted in order to
have the "Copy Link Address" back to work ( only for some little time, once again ).
that's *really* annoying... i've used a google's search results page, and kept
trying to copy all those links; after a little, the copy process no longer worked.

Comment 5

[Dan Tobias]

It's doing it for me too, in Win98... very annoying.

Comment 6

[lars]

I'm seeing this problem consistently with 1.0rc2 on Linux.  Copying text from
web pages or email works just fine, but selecting "Copy link address" is a noop.
 This is the first time I've run into this problem (maybe rc1 had it too).

-- Lars

Comment 7

[lars]

Okay, actually "Copy link location", but otherwise an accurate report.

Comment 8

[oscar]

Hi

I noticed it on Slackware 8 and mozilla rc2 an also on Debian Woody and the
prepackaged mozilla rc2_2.
Clipboard usually ends up containing the last valid selection.
in most cases anything I selected using the mouse.
Sometimes Copy link address works.
In RC1 this wasn't present

Comment 9

[ixde]

I have the same problem with mozilla rc2 on linux.
When I right-click on a link and drag the mouse pointer over a second link before
releasing the mouse button on "copy link location", the clipboard contains that
second link. This only works when the mouse pointer is on the second link while
entering the popup dialog.

Comment 10

[Sebastian Kanthak]

To problem started appearing with rc2 at my debian woddy box. If I press the
mouse button and release it, after selecting "copy link address", everything
works fine. However, if I press the right mouse button, release it, select "copy
link address" and press it again, nothing is copied into the clipboard.

However, if it does not work, I see something popping up at the mouse pointer
location for a very, very short time. It looks like a little window or another
context menu. But it's definitely too short, to see anything. This could be
another hint at a focus problem...

ciao Sebastian

Comment 11

[Malcolm Ferguson]

This happening for me with Mozilla 1.4 on Win2K.  I don't know how to recreate
it.  It happens several times a day and is very very annoying.  I've started
having to drag the link from the Navigation Toolbar to the edit box on the
Googlebar toolbar, and then copy and paste from there.  Activities such as
navigating to a new location, opening new tabs, browsing elsewhere in a
different tab and then returning eventually resolve the issue, but it comes back.

Comment 12

[Blake Ross]

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). 
If you want this fixed for Firefox, change the Product and Component accordingly
and reassign back to me.

Comment 13

[djstealth]

See bugs 133439, 96645, 278927, 153145, 252084, 196897, 101539

Comment 14

[djstealth]

See bugs 133439, 96645, 278927, 153145, 252084, 196897, 101539

Comment 15

[Jimmy Sieben]

Can we please fix this for FireFox 1.5

It's a terrible issue that plagues many users (including me!)

Comment 16

[Wayne Mery (:wsmwk)]

*windows* users - do see this with a SM TRUNK build or FF 1.5.0.4?  (yes, I know this is a suite bug)

Comment 17

[Wayne Mery (:wsmwk)]

WFM 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061025 SeaMonkey/1.5a

please reopen if you see this on any platform with a current version.