33583 - Image map <area> context menu should be for a linked image, not for a link

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Brad Nixon]

Overview Description:
The View Image context menu item is not appearing in the context menu for the
header image.

Steps to Reproduce:
1)load given url.
2)right-click "News.Com" header image

Actual Results:
there is no View Image element in the menu

Expected Results:
a View Image item should appear.

Reproducibility:
always

Build Date & Platform Bug Found:
Build ID 2000032708, Win95

Additional Builds and Platforms Tested On:
none

Additional Information:
none

Comment 1

[Mike Pinkerton (not reading bugmail)]

not xpmenus.

Comment 2

[Stephen P. Morse]

The reason the block-image menu item does not appear is because those items are 
not images.  If you look at the html for that page you will see that the 
news.com header image is not an image but rather html text fetched from yet 
another page.  Here's the html source for both the c/net red circle and the 
"news.com" that appear on the first orange line of this page:

<area shape="circle" coords="28, 27, 25" 
   href="/frontdoor/0-1.html?st.1003.1003-ron.yhed.1">
<area shape="rect" coords="53, 0, 215, 54"    
href="/news/0-1002.html?st.ne.1003.hdgif.1002">

Comment 3

[:deanis74]

The HREF parameter of the AREA tag specifies the link to follow when that 
portion of the map is clicked, not any sort of source fopr the map.  The map 
name "redball" that you're referring to in this page is used a few lines down, 
as part of an IMG tag.  

Looks to me like there should be a View Image (as per the original bug report) 
context menu item and this bug should be reopened.  Oh, and such a menu item 
appears in 4.x.

Comment 4

[Bill Law]

It appears that the problem is that clicking on a client-side image map now 
associates the <area> element with the context menu rather than the underlying 
<img>.

On the one hand, this is good because it might provide a means of fixing a 
different bug relating to image maps not surfacing their links properly.  
Unfortunately, I'm not sure how to get from the <area> back to the image.

Comment 5

[Stephen P. Morse]

Sorry, I guess I jumped the gun here in closing it out as invalid.  First, I 
didn't see that the image tag was actually a few lines lower and, second, I 
looked quickly and thought that the bug was assigned to me.

The good news is that I'm glad that the bug is not assigned to me because I have 
no idea how to fix it. ;-)

Comment 6

[Gervase Markham [:gerv]]

Confirming - but if morse can't fix it, well, who can? ;-)

Gerv

Comment 7

[sairuh (rarely reading bugmail)]

strangely, this wfm...then again, i'm using today's commercial bits --perhaps
this is mozilla only?

another easy place to check (just another testcase) would be:

1. go http://www.mozilla.org/
2. move mouse over to topbanner, specifically, over Mozilla's grinning red head.
3. bring up context menu.

result: i see View Image in the context menu (mac, linux and winNT).

Comment 8

[Bill Law]

I'm going with the WORKSFORME.  I think the "bug" I noted previously (see my 
comment of 03/28) was a temporary thing.

Comment 9

[Brad Nixon]

I'm testing this with the 2000051012 build...the View/Save image items are 
showing up in the menu for that image, but they're not doing anything. Strange, 
because for the "advertisement" image on the top right-hand column of that same 
page, they're working fine. Is that another bug or what?

Comment 10

[Bill Law]

There are problems (already reported and I've got fixes for some of them) with 
certain, more convoluted HTML.  E.g., client side image maps don't work.  Also, 
images coded via <object> tags don't work.  Also, certain images (such as 
background images defined vis CSS) and specified via relative URLs don't work 
properly.

That said, I'm still reopening this bug because there's definitely something 
funky going on with the banner on www.news.com.  The *first* time I right click 
on the CNet circle, I get link options (but it doesn't seem to work).  But at 
some point this stops working (the links-related items disappear).  Also, "Open 
link in new window" does work successfully for at least some other image-links.

Somethings horked so I'll investigate more with today's build.

Comment 11

[Paul Chen]

nav triage team:

Funny things still happen on this page, but not a beta stopper. Marking nsbeta1-

Comment 12

[:deanis74]

OK, just to make sure everyone's on the same page, this bug as originally
reported is still an issue.  If you go to news.cnet.com and right-click on the
red CNet logo in the top-left corner, the context menu doesn't contain a "Save
Image As" menu item.

Adding a bit to the summary.

Comment 13

[sairuh (rarely reading bugmail)]

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

Comment 14

[sairuh (rarely reading bugmail)]

adjusting summary [since i dup'd bug 65106, which smells like this one ;) ].

Comment 15

[Stephan Niemz]

Another example from dup'ed bug 65106: go to http://www.yahoo.com/ and right-
click on the navigation bar at the top: whether View Image, Save Image and
Block Image appear depends on whether you clicked inside an <area> or not.
Of course other items appear instead, like "open link in new window" or "save
link as".

Comment 16

[Matthew T (active 1999-2002)]

Resummarizing for clarity, and changing URL to a more obvious example. Original 
URL was <http://news.cnet.com/news/0-1003-200-1592142.html?tag=
st.ne.1002.tgif?st.ne.fd.gif.f>.

Comment 17

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar.

Comment 18

[Jesse Ruderman]

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

Comment 19

[basic]

is bug 88216 related somewhat?

Comment 20

[timeless]

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

Comment 21

[:deanis74]

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

Comment 22

[Boris Zbarsky [:bzbarsky]]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Sebastian Biallas]

Attachment: proposed hack

With this hack, you have both image and link context menu item.

Advantages:
Works (hope so)
Better than no image context menu at all.

Disadvantages:
Probably slow on large pages (it searches for the image that corresponds to the
map)
May not work if two images share the same map (i never saw this, since it makes
not much sense)

Comments of all kind welcome.

Comment 25

[Sebastian Biallas]

Attachment: updated to new version of nsContextMenu.js

Comment 26

[Christopher Hoess (gone)]

FWIW, while it's undoubtedly rare, it's not unreasonable and in certain cases
even useful to associate a single imagemap (i.e., the hotspots and their link
targets) with more than one image.

Comment 27

[Sebastian Biallas]

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

Comment 28

[Boris Zbarsky [:bzbarsky]]

blake, any ideas?

Comment 29

[Dave]

I think that Bug 140172 and Bug 83047 are dupes of this bug.  Could someone
check into marking those as dupes of this bug, though, if that's the right thing
to do?

Comment 30

[Boris Zbarsky [:bzbarsky]]

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

Comment 31

[Boris Zbarsky [:bzbarsky]]

As a note, the image --> map relationship is many to one.  That is, multiple
images could all use the same imagemap....

Comment 32

[Boris Zbarsky [:bzbarsky]]

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

Comment 33

[Adam Hauner]

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

Comment 34

[R.K.Aa.]

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

Comment 35

[Daniel Wang]

not sure if 153747 is a duplicate of this bug.
the context menu of <img usemap> is same as the context menu of
<a>text</a> instead of <a><img></a> --> result save-image-as and
the like missing.

Comment 36

[Michael Lefevre]

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

Comment 37

[Mats Palmgren (inactive)]

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

Comment 38

[Matthias Versen [:Matti]]

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

Comment 39

[Andrei Boros]

Mozilla 1.0 RC3 buld 20020522306 on Win95.

URL: http://www.dn.se/

right-click on logo, top left. Context menu that appears is that of a normal
text link, while it is clearly and image.

Tested with Netscape 4.75, the correct context menu appears.

First assumed it was Javascript blocking context menu, but same result was
achieved with Javascript disabled.

Comment 40

[Daniel Wang]

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

Comment 41

[Boris Zbarsky [:bzbarsky]]

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

Comment 42

[Mats Palmgren (inactive)]

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

Comment 43

[saari (gone)]

->saari, topembed+, I'm dorking with this for embedding

Comment 44

[Boris Zbarsky [:bzbarsky]]

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

Comment 45

[saari (gone)]

nsIContext menu listener has flags that should be OR'd together to determine
what options are available. I think this works in an embedding case so I'd
topembed- just for mozilla.

Comment 46

[habere-et-dispertire]

Attachment: testcase

Simple control and test case.

"Context Menu | Save Image As..." is unavailable on usemap.

Comment 47

[chris hofmann]

removing topembed since this works for embeddors

Comment 48

[Steve Chapel]

Is this different from bug 60561?

Comment 49

[alanjstr]

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

Comment 50

[[e-mail]]

Is, or should there be, a property of a mouse event over an area that shows
which image the mouse is actually over?

Comment 51

[Boris Zbarsky [:bzbarsky]]

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

Comment 52

[Boris Zbarsky [:bzbarsky]]

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

Comment 53

[:deanis74]

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

Comment 54

[Florian Quèze [:florian]]

Attachment: patch

With this patch, the context menu is for a linked image when there is only one
object (<object> or <img> tag) using the map.

I also fixed this javascript strict warning in the file metadata.js:
Warning : assignment to undeclared variable imgType

Comment 55

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The context menu should be for both the image and the link. Any other way seems
broken, and will get bugs filed against it.

Comment 56

[moz]

> The context menu should be for both the image and the link. Any other way seems
> broken, and will get bugs filed against it.

That is much right, when seeing the context menu... some users expect to see
link options and the others expect to see image options 

Comment 57

[Boris Zbarsky [:bzbarsky]]

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

>Index: xpfe/communicator/resources/content/nsContextMenu.js
>+             } else if ( this.target.localName.toUpperCase() == "AREA") {

I know this is the style of the file, but it's pretty wrong (since you can have
random XML elements named "area").  I think you want something more like:

  } else if (this.target instanceof HTMLAreaElement) {

or perhaps a check for instanceof HTMLElement followed by the localname check.

>+                 while ( map && map.nodeType == map.ELEMENT_NODE && !(map.localName.toUpperCase() == "MAP") )

Similar here.

>+                 var mapuri = "#" + map.getAttribute("name");
...
>+                     if (list.item(i).getAttribute("usemap") == mapuri) {

We support "usemap" attributes that don't have a starting '#', last I
checked....  Also, in XHTML we use the "id" attribute of <map>, not the "name"
attribute.  See
<http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsImageMapUti
ls.cpp#51>.  So this check is wrong...

What if two images point to the same imagemap, but one of them has a bogus
"src", so it's replaced by alt text?  Would you still want to bail out of here
claiming we're not on an image?

>+                         if (list.item(i).getAttribute("usemap") == mapuri) {
>+                             if (this.onImage) {
>+                                 this.onImage = false;
>+                                 this.imageURL   = "";
>+                                 break;

(for <object>).  What if it's not an image object?

>+                                        list.item(i).type.substring( 0, 6 ) == "image/") {

What if it's an image object but has no type attribute set?

In all of these cases, I think you want to check whether the list item actually
has an image (via nsIImageLoadingContent).  If it doesn't, it's not an image
for our purposes, I think.

>Index: browser/base/content/browser.js

Same comments apply.

>@@ -4338,7 +4378,7 @@
>-        if ( type.substring( 0, 6 ) == "image/" && data) {
>+        if (type && type.substring( 0, 6 ) == "image/" && data) {

And this code, both before and after the change, is completely and utterly
wrong.	It looks like the fix for bug 245660 will clean this stuff up quite
nicely; I'd get that in before working on this patch more....

Comment 58

[Scott Field]

I'm seeing the opposite problem at http://americas-fair.com/  with Mozilla 1.8b2
build 2005053111, Mac OS X 10.3.8  The links don't work and the context menu
only shows the image related choices.  The links work ok in Firefox.

Comment 59

[Florian Quèze [:florian]]

Attachment: patch v2

Comment 60

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 252192 [details] [diff] [review]
patch v2

Please get r= from the module owner before asking for sr?

In any case, this patch doesn't actually fix the bug it's attached to (since that's a Suite bug and this is a Firefox-only patch).

Comment 61

[Florian Quèze [:florian]]

Comment on attachment 252192 [details] [diff] [review]
patch v2

(In reply to comment #60)
> In any case, this patch doesn't actually fix the bug it's attached to (since
> that's a Suite bug and this is a Firefox-only patch).
> 
I plan to do nearly the same patch for the suite once the firefox part will be reviewed.

Comment 62

[Asaf Romano (gone)]

Comment on attachment 252192 [details] [diff] [review]
patch v2

>Index: browser-context.inc
>===================================================================
>RCS file: /cvsroot/mozilla/browser/base/content/browser-context.inc,v
>retrieving revision 1.29
>diff -u -r1.29 browser-context.inc
>--- browser-context.inc	1 Dec 2006 12:33:29 -0000	1.29
>+++ browser-context.inc	21 Jan 2007 02:58:16 -0000
>@@ -92,7 +92,7 @@
>       <menuitem id="context-copyimage"
>                 label="&copyImageCmd.label;"
>                 accesskey="&copyImageCmd.accesskey;"
>-                oncommand="goDoCommand('cmd_copyImageLocation');"/>
>+                oncommand="gContextMenu.copyImageLocation();"/>
>       <menuseparator id="context-sep-copyimage"/>
>       <menuitem id="context-saveimage"
>                 label="&saveImageCmd.label;"
>Index: nsContextMenu.js
>===================================================================

>+  copyImageLocation: function() {
>+    var clipboard = Cc["@mozilla.org/widget/clipboardhelper;1"].
>+                    getService(Ci.nsIClipboardHelper);
>+    clipboard.copyString(this.imageURL);
>+  },

What's this purpose of this change?

Comment 63

[Florian Quèze [:florian]]

(In reply to comment #62)
> >-                oncommand="goDoCommand('cmd_copyImageLocation');"/>
> >+                oncommand="gContextMenu.copyImageLocation();"/>
 
> >+  copyImageLocation: function() {
> >+    var clipboard = Cc["@mozilla.org/widget/clipboardhelper;1"].
> >+                    getService(Ci.nsIClipboardHelper);
> >+    clipboard.copyString(this.imageURL);
> >+  },
> 
> What's this purpose of this change?
> 

I made this change because cmd_copyImageLocation didn't work when the image was actually an <area>.
See http://lxr.mozilla.org/seamonkey/source/layout/base/nsDocumentViewer.cpp#2516 and
http://lxr.mozilla.org/seamonkey/source/layout/base/nsDocumentViewer.cpp#3161

Comment 64

[Asaf Romano (gone)]

I see, shouldn't we add this functionality to nsDocumentViewer's implementation then?

Comment 65

[Asaf Romano (gone)]

Comment on attachment 252192 [details] [diff] [review]
patch v2

Cleaning review request for that reason. At the very least, making the "Copy Image" menuitem (in SeaMonkey) do the right thing would be kinda hard otherwise.

Comment 67

[biz]

This bug is still a problem in the latest release of firefox (2.0.0.5). My example: http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/.
It's an imagemap: Left-clicking on the right side of the picture scrolls to the next picture. If you right-click on the right side of a picture (or left side if it's not the first picture) in IE, you get the usual context menu for a picture. But in Firefox, you get the context menu for a link, so you can't save the picture. Very frustrating !

Comment 68

[Boris Zbarsky [:bzbarsky]]

> This bug is still a problem 

That's why this bug is still open, yes...

Comment 69

[Conquerz]

My gosh.... It's been EIGHT whole years and Mozilla haven't managed to fix this little bug. This is the only reason why I use Microsoft Internet Explorer.

Please fix this very annoying bug.

Comment 70

[Mike Grant]

I helped set up an online gallery using image maps and wondered why people kept saying they couldn't save images... seems 54% of the visitors are using Firefox nowadays according to the site's stats.

Comment 71

[Conquerz]

(In reply to comment #70)
> I helped set up an online gallery using image maps and wondered why people kept
> saying they couldn't save images... seems 54% of the visitors are using Firefox
> nowadays according to the site's stats.
> 

Mike, did you click on the example posted by [e-mail] couple of posts above? Here's the link:

http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/

Not all images have the "save image" option in the context menu. I often come across many images where the option to save the image is missing in FireFox, but it's there in Internet Explorer.

Comment 72

[Conquerz]

Oh great, Firefox 2 got updated officially to firefox 3 just now (27th Aug 2008), and this bug isn't fixed still. Looks like it never will be fixed.

Why is it that Internet Explorer correctly shows the "save picture as" when you hover your mouse over the right side of the picture in the <a href="http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/
">link</a> above, yet firefox doesn't "see" the image.

Comment 73

[John Harries]

Well, late 2010 and the bug is still here, in Firefox 3.6.12.

I'm in two minds about this bug. On the plus side, it makes it easy to block casual saving of images. But on the down side, EVERY OTHER browser allows right-click and save in such circumstances.

Also, I can't believe this issue is 10 years old! And no devs appear to have commented, so I guess they just don't care and this minor (but niggling) issue will never, ever be fixed.

Comment 74

[Shriram (irc: Mavericks)]

I (In reply to Conquerz from comment #72)
> Oh great, Firefox 2 got updated officially to firefox 3 just now (27th Aug
> 2008), and this bug isn't fixed still. Looks like it never will be fixed.
> 
> Why is it that Internet Explorer correctly shows the "save picture as" when
> you hover your mouse over the right side of the picture in the <a
> href="http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/
> Manhattan+by+Night+-from+DUMBO+in+Brooklyn/
> ">link</a> above, yet firefox doesn't "see" the image.

I checked http://pix.alaporte.net/pub/USA/New+York+NY/Cityscapes/Manhattan+by+Night+-from+DUMBO+in+Brooklyn/
on FF 15.0.1. 
Do you still see the issue ?

Comment 75

[Marcin Sochacki]

Yes, still broken.

http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_areamap

right-click on the Sun -- there's no "Save image as" option.

Comment 76

[Shriram (irc: Mavericks)]

Attachment: Patch to fix cmd_CopyImageLocation issue

cmd_CopyImageLocation issue as per Comment #64

WIP Patch to get FF part fixed and Seamonkey subsequently

Comment 77

[Shriram (irc: Mavericks)]

Attachment: Patch to fix cmd_CopyImageLocation issue

cmd_CopyImageLocation issue as per Comment #64

WIP Patch to get FF part fixed and Seamonkey subsequently

Comment 78

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 707643 [details] [diff] [review]
Patch to fix cmd_CopyImageLocation issue

I would assume this doesn't compile.

What part are you looking for feedback on?

Comment 79

[Shriram (irc: Mavericks)]

(In reply to Boris Zbarsky (:bz) from comment #78)
> Comment on attachment 707643 [details] [diff] [review]
> Patch to fix cmd_CopyImageLocation issue
> 
> I would assume this doesn't compile.
> 
> What part are you looking for feedback on?

I'll update the patch and may be a good idea to build on top of the previous patch by Florian.

Comment 80

[Boris Zbarsky [:bzbarsky]]

That doesn't quite answer my question...

Comment 81

[Shriram (irc: Mavericks)]

(In reply to Boris Zbarsky (:bz) from comment #80)
> That doesn't quite answer my question...

I was hoping to update my patch and ask for feedback then again.

So, for cmd_CopyImageLocation issue, I decided to write the detection code for <area> element and see if I can then pick the topmost image via nodesFromRect(as discussed before)
Then the content->GetHrefURI should've the right image loation.
I hope this's the right path so far, and what Florian meant in comment #63.

Comment 82

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 707643 [details] [diff] [review]
Patch to fix cmd_CopyImageLocation issue

Oh, I see.

That might work, but be careful to still get the right URI....

It might also work to do the "oh, it's an area, look for the image" processing in the JS part of this.

Comment 83

[Shriram (irc: Mavericks)]

I was going through nsContextMenu.js and a few files w.r.t this bug.
Kept coming back to nsContextMenu.js especially 
http://dxr.mozilla.org/mozilla-central/browser/base/content/nsContextMenu.js.html#l361 
Hence the documentviewer.cpp. will look at the js part.

Comment 84

[[e-mail]]

(In reply to Boris Zbarsky from comment #82)
> It might also work to do the "oh, it's an area, look for the image"
> processing in the JS part of this.

Which API would you suggest would be most suitable? (It might be possible to get mouse coordinates, but it's also possible to open the context menu by tabbing to the area, so...)

Comment 85

[Boris Zbarsky [:bzbarsky]]

Hmm, I forgot about that part.

How do we track our "real" tab position in the tabbing case?

Comment 86

[[e-mail]]

My understanding is that we just tab through tabbable frames.

Comment 87

[Neil Deakin]

Not sure what you're asking but tab navigation in image maps is handled by nsFocusManager::GetNextTabbableMapArea.

Comment 88

[Aruna]

Hey!! Can I work on this?

Comment 89

[Frank-Rainer Grahl (:frg)]

Aruna,

this is a very old SeaMonkey bug. Just verify that it is still valid and attach a patch. Ask me or IanN_bugzilla for review.