143607 - Right-click menu "Copy Link Location" doesn't work

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Richi Plana]

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

Right-clicking on a web link and selecting "Copy Link Location" doesn't copy the
URL to the clipboard as expected

Reproducible: Always
Steps to Reproduce:
1. Go to any website (ie. http://www.mozilla.org/)
2. Right-click on a HREF link
3. Select "Copy Link Locatioin"
4. Try pasting X clipboard contents

Actual Results:  Clipboard contents do NOT change

Expected Results:  URL should go to X clipboard

Comment 1

[Bradley Baetz (:bbaetz)]

Confirming with rc2. Also see bug 98984. edit->paste (and context menu paste) no
longer work, so this is more than just that bug. This apparently works on windows.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This works in 2002-05-09-07 and does not in 2002-05-09-21.  I'm now backing out
checkins one by one...

Note that a _second_ menu comes up when any menu option is selected (very
briefly).  The console shows:

###!!! ASSERTION: ACK, BAD TARGET NODE: 'targetNode', file nsMenuPopupFrame.cpp,
line 600
###!!! Break: at file nsMenuPopupFrame.cpp, line 600
###!!! ASSERTION: ACK, BAD TARGET: 'targetDocumentWidget', file
nsMenuPopupFrame.cpp, line 623
###!!! Break: at file nsMenuPopupFrame.cpp, line 623
An error occurred executing the cmd_copyLink command

Comment 3

[Boris Zbarsky [:bzbarsky]]

This was caused by the checkin for bug 140767 (and so is on the branch and in
RC2, unfortunately).  Backing out that patch fixes all the problems I observe
(assertion, extra context menu, failure to copy).  ccing various people who may
know what's going on here.

Comment 4

[Boris Zbarsky [:bzbarsky]]

*** Bug 143619 has been marked as a duplicate of this bug. ***

Comment 5

[Christopher Blizzard (:blizzard)]

Looking.

Comment 6

[Christopher Blizzard (:blizzard)]

OK, I have no idea why removing that bit of code would cause this problem.  The
only difference in the types of events that are sent to layout are that there
are some motion notify events sent to the content window underneath the popup. 
That's it.  As near as I can tell, there are no other changes to event flow. 
Why this causes this bug, I have no idea, it's all happening down in layout land.

The assertion in question is happening on the button release, not the motion
event or even the button press event.  The assertion itself happens when the
reflow state is flushed because the popup is being dismissed and there's no
popup there anymore.

This is going back over to layout since I'm pretty sure it's evil that's
happening there and not here.  Must be some strange side effect and I can't back
out that patch since it's the way that it should be working if you want menus to
work.

Comment 7

[Boris Zbarsky [:bzbarsky]]

One other interesting piece of information.  If I open the context menu then
click-hold the mouse on the "copy link location" item for two seconds or so and
then release, I see no second menu and the location is copied correctly.  Could
the problem be us tearing down the popup before the action is complete?  If I
recall correctly the popup is what carries the state information that says what
context we are in.  So if we destroy the popup before the action is done then
the action can fail.....

Comment 8

[Richi Plana]

I don't know anything about the underlying code, but here's an observation that
might help: the bug only manifests itself if the right mouse button-on brings up
the context-sensitive menu AND a button-off is generated without selecting an
item (leaving the menu on). If you then select one of the items, it seems to
popup another menu (slightly offset from the first). This weird behavior happens
for all the menu items but the only obvious effect is on "Copy Link Location"
(which doesn't work. It (second menu popping in briefly) also seems to happen
whether the context-sensitive menu is brought up on a link or anywhere else on
the page.

Comment 9

[Martin Macok]

Confirming the problem on Mandrake 8.2 Linux with current (20020511) branch1.0.
I also confirm that leaving mouse down for 2 seconds when click on "copy link
location" workarounds the problem.

The second context right click menu (mentioned by Richi in comment #8) strange
appereance is covered in bug 124939 (with screenshot) and bug 129887. (but I
don't know if it is related)

Comment 10

[Robert Kaiser]

Further observations:

The second popup is always shown if I ever have released the right mouse button
from which I invoked the context menu, and any item of the context menu still
appears highlighted (even when I just close the context menu with a click
outside it). It's not shown when I manage that no item is highlighted when
closing the context menu.
It's also not shown in the case where I get copy to work, that is, when holding
right button down and releasing it when the copy item is highlighted.
The second popup is offset to the left and top, and always is identical to the
first, it also has the same item highlighted as the first contect menu popup.

Comment 11

[Robert Kaiser]

sorry, didn't want to kill the keyword in that midair collision.

Comment 12

[Blu3]

For a mid-air, all you need to do is hit [Back] and [Reload] then commit. 
Mozilla and bugzilla will have kept your changes and merged the updated data
(unless you modified something that the mid-air is also modifying)

Comment 13

[Matthias Versen [:Matti]]

*** Bug 143984 has been marked as a duplicate of this bug. ***

Comment 14

[Jonathan Wilson]

Confirming that this doesnt happen on RC2, windows XP
Looks like this is linux only

Comment 15

[Panagiotis Issaris]

*** Bug 144289 has been marked as a duplicate of this bug. ***

Comment 16

[Boris Zbarsky [:bzbarsky]]

"Copy Image Location" is also broken.  Interestingly, "Copy email address" sorta
works -- the address is copied, though the "extra menu" flashing business still
happens.

Nominating -- this makes a very commonly used context menu item unusable, as
well as creating a thoroughly bad impression due to the extra flashing menu. 
The problem is exacerbated on slower machines (eg a P2-400 where the extra menu
stays up for on the order of a second...).

Comment 17

[Blu3]

Keep in mind that on slow machines you also must hold the right mouse down for
5-8 seconds to get a reliable object copy.  Still can't copy image locations
when they come from <input type=image ....>, bug 77122.

It's very aggravating, I use the context menu -well- over a hundred times a day.

Comment 18

[chris hofmann]

who is working on this?  what are the chance of a fix in the next couple of days.
need to move quickly and safely for resolution in RC3.

Comment 19

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 144545 has been marked as a duplicate of this bug. ***

Comment 20

[Boris 'pi' Piwinger]

*** Bug 144526 has been marked as a duplicate of this bug. ***

Comment 21

[Jeremy M. Dolan]

If it's any help, I now notice the context menu jostle a bit after I click 'copy
link location'. The whole thing redraws higher then it was for an instant after
click.

<whine>Due to other bugs with downloading (mainly permissions and cache, and now
my complete lack of trust in mozilla to not corrupt the file which stems from
the old gzip issue, and the new DOM one) I'm not able to use left click or save
link as to retrieve files. I've been using copy link location and pasting to
'wget' for a year or so. This bug makes it impossible for me to download at all,
or for anyone to download to another machine (which I do all day long for
work).</whine>

Comment 22

[Dawn Endico]

shaver thinks this is a layout bug and will chase this tomorrow.

Comment 23

[Mike Shaver (:shaver emeritus)]

bryner says it's blizzard, blizzard says it's layout, neither are looking at the
bug, I'm going to make it someone's problem tomorrow.  Heaven help us all if
it's mine.

Comment 24

[ken_kizaki]

There's another nasty side effect: because copying doesn't work it causes
Downloader for X (http://www.krasu.ru/soft/chuchelo) to fail

Comment 25

[Reid Sutherland]

If you select and click "Copy Link Location" quickly serveral times, it will
copy the link to the clipboard.

Comment 26

[Boris Zbarsky [:bzbarsky]]

*** Bug 144760 has been marked as a duplicate of this bug. ***

Comment 27

[R.K.Aa.]

*** Bug 144833 has been marked as a duplicate of this bug. ***

Comment 28

[Joseph Elwell]

Just a mention that this is Mac as well according to one dupe : bug 144289

Comment 29

[Boris 'pi' Piwinger]

*** Bug 144982 has been marked as a duplicate of this bug. ***

Comment 30

[peter]

Can confirm it does not work with Mozilla rc2-1 and rc2-2 from the Debian
unstable tree. Using KDE3.0.0 and X 4.1.

Comment 31

[Dmitry Potapov]

I can confirm it does not work with Mozilla rc-2, Debian 3.0 (woody)

But I was able to copy link location by keyboard:
 1. Right-click on link 
 2. select 'Copy Link Location' by keyboard 
   (it seems significal that you don't move mouse)
 2. Press Enter.

Comment 32

[Brian Ryner (not reading)]

patch coming up

Comment 33

[Brian Ryner (not reading)]

Attachment: patch

don't clobber the document's popupNode in the tooltip timer callback... talked
with hewitt and this is left over from when the popup and tooltip listeners
were one and the same.

Comment 34

[Boris 'pi' Piwinger]

*** Bug 145163 has been marked as a duplicate of this bug. ***

Comment 35

[Christopher Blizzard (:blizzard)]

Comment on attachment 84010 [details] [diff] [review]
patch

sr=blizzard

Looks fine to me.

Comment 36

[Joe Hewitt (gone)]

Ack.  This patch won't work, I just remembered why.  See here:

http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuPopupFrame.cpp#599

nsMenuPopupFrame grabs document.popupNode to determine the target to position
itself relative to.  tooltips use nsMenuPopupFrame, and so that's why I was
setting  popupNode for them.  So, you now need to also add code in
nsMenuPopupFrame::AdjustClientXYForNestedDocuments to check if the frame's tag
is tooltip, and if so check document.tooltipNode instead of document.popupNode

Comment 37

[Brian Ryner (not reading)]

Attachment: patch #2

Ok.  This one doesn't break tooltips :)

Comment 38

[Joe Hewitt (gone)]

Comment on attachment 84105 [details] [diff] [review]
patch #2

r=hewitt

Comment 39

[Johnny Stenback (:jst)]

Comment on attachment 84105 [details] [diff] [review]
patch #2

sr=jst

Comment 40

[Mike Shaver (:shaver emeritus)]

Comment on attachment 84105 [details] [diff] [review]
patch #2

a=shaver for the 1.0 branch.  Woot, and things.

Comment 41

[Peter Trudelle]

nsbeta1+/ADT1 per Nav triage team.
ADT1.0.0+ on behalf of ADT, go ahead and land this puppy!

Comment 42

[Brian Ryner (not reading)]

Checked in on the trunk and branch.

Comment 43

[Boris 'pi' Piwinger]

*** Bug 145487 has been marked as a duplicate of this bug. ***

Comment 44

[Boris 'pi' Piwinger]

*** Bug 145480 has been marked as a duplicate of this bug. ***

Comment 45

[R.K.Aa.]

*** Bug 145514 has been marked as a duplicate of this bug. ***

Comment 46

[Matthias Versen [:Matti]]

*** Bug 145700 has been marked as a duplicate of this bug. ***

Comment 47

[Paul Wyskoczka]

qa --> [e-mail]

Comment 48

[Boris 'pi' Piwinger]

Works in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020522.

pi

Comment 49

[Matthias Versen [:Matti]]

*** Bug 147257 has been marked as a duplicate of this bug. ***

Comment 50

[sairuh (rarely reading bugmail)]

works fine --vrfy'd fixed using 2002.06.10.0x comm branch bits on linux, win2k
and mac os x.