Closed Bug 78021 Opened 21 years ago Closed 21 years ago

Copy Link Location broken for image maps and LINK elements

Categories

(Core :: XUL, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla0.9.5

People

(Reporter: ian, Assigned: hjtoi-bugzilla)

References

()

Details

(Keywords: regression, top100, Whiteboard: PDT+,[Hixie-P0][fixed on trunk and 0.9.4])

Attachments

(1 file)

STEPS TO REPRODUCE
   1. Go to http://www.planetarion.com/
   2. Right click on "Log In".
   3. Choose "Copy Link Location".
   4. Paste the clipboard into the location bar.

ACTUAL RESULTS
   Old contents of clipboard will be pasted.

EXPECTED RESULTS
   The Copy Link Location option should copy the link location to the clipboard.

I need this for day to day use of the browser.
Severity: normal → major
Whiteboard: [Hixie-P1]
Keywords: mozilla0.9mozilla0.9.1
There are a bunch of minor correctness issues with the code in PresShell that
figures out whether you're in an image or link, or not. This is probably the
most major of those. This will probably morph into the inevitable task of
splitting the helpers out of PresShell into a separate interface and making them
more correct.
Status: NEW → ASSIGNED
Component: XP Apps → XP Toolkit/Widgets
OS: Windows 2000 → All
Priority: -- → P2
QA Contact: sairuh → jrgm
Hardware: PC → All
Target Milestone: --- → mozilla0.9.1
->future, per trudelle
Target Milestone: mozilla0.9.1 → Future
Copy link location is also broken for ftp listings.  To reproduce:

1. Go to ftp://ftp.linux-wlan.org/pub/linux-wlan-ng/
2. Right click on (say) linux-wlan-ng-0.1.7.tar.gz
3. Choose "Copy Link Location".
4. Paste the contents somewhere.

The old contents of the clipboard will be pasted, instead of the URL for
the link you selected.

Based on the comments from Dan Rosen, which indicates it is a general problem, I
added this to the comments of this bug instead of creating a new bug report for
it.  Summary should be changed to add "and ftp" to the end, but I don't have
sufficient permissions to do that.

I'm seeing this on the linux build;  platform's already been set to "All" so I
suppose the same sorts of things happen on other platforms.
Context menu 'copy link location' with an ftp listing worksforme on win2k
and linux (rh6.1). I don't know what specifically dr was referring to above,
but if it were the case that this did not work for ftp listings, it should 
still go in as a separate bug (if for no other reasons than I personally 
could punt on fixing this bug, but not on something as bread and butter as 
copying a simple link in HTML content).
cananian, jrgm: the ftp problem is bug 77171. cananian, we don't have a
xul-based ftp view anymore, we use html to view ftp directories. so i won't fix
that bug until we start using xul to view ftp directories again. it's related,
though...
Depends on: 80116
<spam>

Netscape 6.0 went out with Copy Link Location working with imagemaps. The next
Netscape RTM should not go out with it broken. Bug 80116 and bug 78021 should be
fixed for 0.9.2.

This should be a simple task of filling in a new XPCOM API with Bill Law's
content-sniffing code in nsContextMenu.js. (More content analyzing APIs should
be filled in post-RTM as needed).

</spam>
Keywords: nsdogfood
Target Milestone: Future → mozilla0.9.2
->0.9.3, could possibly still take a fix during 'limbo'
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Priority: P2 → P1
Keywords: nsBranch
Priority: P1 → P2
dr, are you actually committing to fix this by 0.9.3? If not we need a new
target milestone.

Also keywords should be fixed.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
[spam] -> 0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Another page to verify when this is fixed:

http://cartoonnetwork.com/toonami/signal/dragonballz/garlic_jr.html

Back to show and Episode Guide at the bottom... one is javascript. This is
pretty annoying since I have window.open disabled, so I have to dig through view
source for the URL to get at the content.
I have a fix, taking, trying to get onto the 0.9.4 branch as the fix is safe.
This can be fixed even without 80116, although fixing that can make the code
cleaner.

This seems to be fallout from bug 64313. dr only made the new copy things work
for A elements, regressing AREA, XLinks and maybe something else as well... are
there other "link" elements in HTML besides A and AREA? I am at a loss as to
explain why the reviewers okayed the change even though it regressed everything
else beyond A.
Assignee: dr → heikki
Status: ASSIGNED → NEW
Keywords: nsbranchnsbranch+
Target Milestone: mozilla0.9.5 → mozilla0.9.4
the <link> element
*** Bug 98322 has been marked as a duplicate of this bug. ***
How can the user right-click on a LINK element (that is hidden inside HEAD), and
do a Copy Link Address from the context menu? I don't think we have UI for
prev/next links, and even if we did I don't see how you could right-click on a
UI button or something and expect to copy the link location...
Status: NEW → ASSIGNED
He can't choose "Copy Link Location", cos it doesn't appear. It should, though.
As to how he can right click on a <link> element... See:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link2.html
Whiteboard: [Hixie-P1] → [Hixie-P0]
Wow, I didn't know that! This is cool.

Ok, I now have a patch that fixes the context menu for AREA (image maps), LINK
and simple XLinks as well (Copy Link Address item and other context menu items
dependent that are link specific). 

A was working already. There is one bug with the LINKs: if you right-click on
the label, it does not work. Clicking on the image or anywhere else does work.
DOM Inspector thinks the element is <browser> which completely whacks up the
whole context menu - it thinks this is a frameset document, even. I don't really
know how to go after that, but I'll file a new bug on context menu experts.

While testing, I noticed the LINK links do not actually work; if you click on
them nothing happens. Sometimes they depress as buttons when you click, but
usually they don't. Just opening that page, and mousing over and clicking the
buttons produces a bunch of assertions:

###!!! ASSERTION: aOuter is not an nsILink: 'link != nsnull', file c:\builds\moz
illa\content\html\content\src\nsGenericHTMLElement.cpp, line 1289
###!!! Break: at file c:\builds\mozilla\content\html\content\src\nsGenericHTMLEl
ement.cpp, line 1289

Is that a regression, and is there are bug already filed?

Also, mousing over the LINK buttons does not show anything in the statusbar. Is
that a regression, any bugs open?

Btw, IE6 displays the page funny: it adds a new non-functional scrollbar to the
right, and does not display the LINK links.
Summary: Copy Link Location broken for image maps → Copy Link Location broken for image maps and LINK elements
Heikki Toivonen 2001-09-06 11:51 - "There is one bug with the LINKs: if you
right-click on the label, it does not work.": I had recently filed this one
(#98322) - which someone marked as duplicate of this one. Works correctly in
Netscape Communicator 4.7.
manojd, and others: I may have caused some confusion with terminology, so let me
try to clear it up. Currently we get the correct context menu items for <a> and
<area> (imagemap link) elements. Copy Link Address does not work for the <area>
element, though.

After my fix, Copy Link Address works for <area> (imagemap link) as well.
Additionally, after the fix, the context menu will have the correct entries and
works correctly for <link> elements (this is the weird element in HTML <head>
that most people don't know can be used for linking purposes). Look at the page
Hixie provided; I bet you have never seen anything like that before. There is
still a bug with <link> elements, though: right-clicking on the button label
(like 'index') will not give you link-specific context menu items and therefore
you cannot even try to do Copy Link Address. Also the <link> links do not seem
to work, but that is a different bug.
Comment on attachment 48445 [details] [diff] [review]
Proposed fix 1

r=harishd
Attachment #48445 - Flags: review+
Comment on attachment 48445 [details] [diff] [review]
Proposed fix 1

sr=vidur

A couple of nits:
1) In DocumentViewerImpl::GetPopupLinkNode, you could do atom comparisons on the local name instead of QIs.
2) In the PresShell patch, you can use the inline function NS_NewURI instead of invoking the service directly.
Attachment #48445 - Flags: superreview+
1. I decided not to; the benefit is not that much in speed.
2. I also decided against this; NS_NewURI expands into the same code.
This affects top100 sites, including http://home.netscape.com "Autos", "Browser
Central" etc. are actually made with image maps and Copy Link Address does
currently not work for them.
Keywords: top100
Fixed on the trunk, leaving open for checkin on the 0.9.4 branch.
Whiteboard: [Hixie-P0] → [Hixie-P0][fixed on trunk]
Seems like 0.9.4 went/is going... moving on. This should still get on the branch
after mozilla.org is done with it.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Please check it in by 3 p.m. today. PDT+
Whiteboard: [Hixie-P0][fixed on trunk] → PDT+,[Hixie-P0][fixed on trunk]
Fixed on 0.9.4 branch as well, although I couldn't land it before 3 pm. That
would have required me to go back in time, seeing that the PDT+ was given after
4 pm ;)
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: PDT+,[Hixie-P0][fixed on trunk] → PDT+,[Hixie-P0][fixed on trunk and 0.9.4]
verified fixed for branch 10/1 builds on linux/mac/win32.
Keywords: vtrunk
You need to log in before you can comment on or make changes to this bug.