Closed Bug 143607 Opened 19 years ago Closed 19 years ago
Right-click menu "Copy Link Location" doesn't work
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.
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. ***
Status: NEW → ASSIGNED
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)
19 years ago
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.
sorry, didn't want to kill the keyword in that midair collision.
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...).
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
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]
*** Bug 145163 has been marked as a duplicate of this bug. ***
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
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!
Checked in on the trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
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 --> email@example.com
QA Contact: paw → sairuh
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
You need to log in before you can comment on or make changes to this bug.