Closed Bug 143607 Opened 23 years ago Closed 23 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: RichiPlana, Assigned: bryner)

References

(Blocks 1 open bug)

Details

(Keywords: platform-parity, regression, useless-UI, Whiteboard: [driver:shaver] [ADT1])

Attachments

(1 file, 1 obsolete file)

patch #2
2.44 KB, patch
hewitt
: review+
jst
: superreview+
shaver
: approval+
Details | Diff | Splinter Review 
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0, pp, regression
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

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.
Assignee: sgehani → blizzard
*** Bug 143619 has been marked as a duplicate of this bug. ***
Looking.
Blocks: 143200
Status: NEW → ASSIGNED
Blocks: 143630
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.
Assignee: blizzard → blaker
Status: ASSIGNED → NEW
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.....


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.
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)
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.
Keywords: useless-UI
sorry, didn't want to kill the keyword in that midair collision.
Keywords: useless-UI
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)
*** Bug 143984 has been marked as a duplicate of this bug. ***
Confirming that this doesnt happen on RC2, windows XP
Looks like this is linux only

*** Bug 144289 has been marked as a duplicate of this bug. ***
"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...).
Keywords: nsbeta1
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.
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.
Whiteboard: no patch.
*** Bug 144545 has been marked as a duplicate of this bug. ***
*** Bug 144526 has been marked as a duplicate of this bug. ***
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>
shaver thinks this is a layout bug and will chase this tomorrow.
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.
Assignee: blaker → shaver
Whiteboard: no patch. → no patch. [driver:shaver]
There's another nasty side effect: because copying doesn't work it causes
Downloader for X (http://www.krasu.ru/soft/chuchelo) to fail
If you select and click "Copy Link Location" quickly serveral times, it will
copy the link to the clipboard.
*** Bug 144760 has been marked as a duplicate of this bug. ***
*** Bug 144833 has been marked as a duplicate of this bug. ***
Just a mention that this is Mac as well according to one dupe : bug 144289
*** Bug 144982 has been marked as a duplicate of this bug. ***
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.
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.

patch coming up
Assignee: shaver → bryner
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla1.0
Attached patch patch (obsolete) — — Splinter Review 
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.
Status: NEW → ASSIGNED
Whiteboard: no patch. [driver:shaver] → [driver:shaver]
Blocks: 145011
*** Bug 145163 has been marked as a duplicate of this bug. ***
Attachment #84010 - Flags: superreview+
Comment on attachment 84010 [details] [diff] [review]
patch

sr=blizzard

Looks fine to me.
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
Attached patch patch #2 — — Splinter Review 
Ok.  This one doesn't break tooltips :)
Attachment #84010 - Attachment is obsolete: true
Comment on attachment 84105 [details] [diff] [review]
patch #2

r=hewitt
Attachment #84105 - Flags: review+
Comment on attachment 84105 [details] [diff] [review]
patch #2

sr=jst
Attachment #84105 - Flags: superreview+
Comment on attachment 84105 [details] [diff] [review]
patch #2

a=shaver for the 1.0 branch.  Woot, and things.
Attachment #84105 - Flags: approval+
nsbeta1+/ADT1 per Nav triage team.
ADT1.0.0+ on behalf of ADT, go ahead and land this puppy!
Keywords: nsbeta1 → adt1.0.0+, nsbeta1+
Whiteboard: [driver:shaver] → [driver:shaver] [ADT1]
Checked in on the trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
*** Bug 145487 has been marked as a duplicate of this bug. ***
*** Bug 145480 has been marked as a duplicate of this bug. ***
*** Bug 145514 has been marked as a duplicate of this bug. ***
*** Bug 145700 has been marked as a duplicate of this bug. ***
qa --> sairuh@netscape.com
QA Contact: paw → sairuh
No longer blocks: 143200
Works in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020522.

pi
*** Bug 147257 has been marked as a duplicate of this bug. ***
works fine --vrfy'd fixed using 2002.06.10.0x comm branch bits on linux, win2k
and mac os x.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: